Lean PPM – step 12: Documentation consumer type 2: project leads, business analysts, (requirements and software) engineers, or likewise folks

Prolbares (= project leads, business analyst and requirements engineers) express a lot more needs in documentation. Prolbares are around on all abstraction levels of requirements (see the requirements abstraction model RAM by Tony Gorschek and Claas Wohlin). Prolbares work from business goals, high level business processes down to tiny technical details. Prolbares are involved in the full lifecycle of designing and implementing desired changes (see “The life cycle of an initiative”). In the design process of a change they are responsible to elicitate, design, communicate, consolidate and confirm requirements of a change. In this context “change” is anything from a small continuous improvement in an existing system to a discontinuous innovation in form of a new product or service.

In respect if documentation, Prolbares are like chameleons. Some like to write novels, some hate writing any documentation, some like modeling, some prefer to paint pictures; some are more user experience oriented, some rather are technicians; some feel comfortable on the abstract levels of requirements like business goals, processes and features, some love tiny details…

Naturally the requirements of Prolbares for documentation are magnifold:

• In the initial part of the lifecycle of a change they have an interest about the current situation. Source code and acceptance tests are a good source of the current state of a piece of software – but unluckily, as mentioned in my last blog – this is often only part of the truth. Manual and organizational procedures do not have a source code. Documentation could be treated as the source code of a manual and organizational procedure.
• Prolbares consume and create many artifacts and share these with her team(s) like meeting notes, requirements specifications, prototypes, decisions, technical description, whatever is needed in the refinement of intiatives, epics and user stories.  Most of this is waste when the change is done. Most of it, but not all. Some pieces out of this huge amount of information is valuable for the first step – to remind on the current situation any time in the future when the next change is in the road.
• Because of the chameleon alike nature, finding anything that suits all Prolbares is like finding the holy grail. So we had to find options that satisfy the majority of the Prolbares.

Prolbares are hard to place within an organization. Reason is that Prolbares typically are not full time members in any team. If integrated into the IT organization (i.e. Scrum teams) they spent 50% of their time with stakeholders and business. If integrated into business, they spent 50% of their time with IT, and – if not – they loose contact to IT, what results in defects in the quality of requirements (conversation, confirmation, feedback loops). At digitec Galaxus business analysts are our Product Owners in the Scrum teams. 

If Prolbares act positive in an organization, they care for the whole (optimizing the system and not preferring a specific department). They act as mediator, moderator, translator between business and IT to balance needs and wishes. They support ideas to become visible; mature ideas into change projects and finally towards real implemented (continuous or discontinuous) innovations together with all involved departments, subject matter experts, external partners, management and whoever has stakes in the change.

This is the reason Prolbares typically have an interest on a higher amount of documentation than all other involved persons and job profiles in an organization. A good Prolbare want to understand the problem under discussion herself. So the write a part of the documentation for themselves. Then they use documented requirements to solve different views and conflicts between stakeholders in the design phase of a change project. Additional they try to create a documentation that best suites all stakeholder in documentation (from executive managers to engineers and technical experts). 

Unluckily often the documentation policies, structures and tools in an organization are not defined in a way to support Prolbares to ease their job. The results we encounter in many organizations. To many documentation; documentation that does not satisfy the needs of consumers; documentation that does not allow to search and find the requested piece of information to successfully work on a piece of work.

In my personal perception to identify an appropriate structure and tool support for this relevant part of documentation is the most critical point. In fact this is the part to support the activities of business analysis, requirements engineering and design in respect of the creation of required documentation. 

Lean PPM step 7: The relevance of slack time

Then there is slack time. Engineering explicitly owns 20% of their capacity for themselves. I am personally convinced that every person, every department and every company works on a sustainable path only if slack time is available. A slack time mechanism is the heart for creativity, innovation and continuous improvement. Like a TCP/IP bus system is working only if its capacity consumption is below a certain level with a performance break down if this capacity is exceeded, individuals and teams show a similar behavior. Above a certain level of work assignment – no matter if this assignment is done by the organization of by the individual herself – the productivity of the individual drops. The differences between a TCP/IP bus and a person are that

• The TCP/IP bus shows this behavior at once. A person shows this behavior with a delay whereas the delay is individual. There are some persons on the world that do not show this behavior, but these are really rare. Unluckily these individuals often act as template for the average.
• For most type of work – especially skill work – it is hard to measure productivity. So you never know whether productivity really drops. One reason is that it is hard to define productivity, even when managers believe there is measure based on hard facts to calculate productivity. That’s the reason hours working time often are used as equivalent for productivity. Luckily new management models follow stretched goal definitions and team goals instead individual goals to overcome this old management school disasters.

On the other hand to much slack time has a negative impact, even worse if there is no self-motivation how to invest slack time in a positive way. This is called the student syndrome. It is the responsibility of the management to identify the right amount and type of slack time – even for every single department in a different way – and to build up a self-motivation mind set so that slack time is invested into anything the organization benefits from.

For our engineering we are simple and straight. To prevent that initiatives and fastlane result in a 100% capacity consumption we simply defined an average 20% of the overall capacity as slack time. There is only one constraint: show stopper bugs are fixed eating up slack time. This creates as well a mind set to avoid show stopper bugs.

To discuss the statement “the right amount and type of slack time” a bit more: there are many different ways to implement slack time. Through the software community crawls the Google mechanism of the free fifth day. I personally never worked for Google, so I cannot say if this is a myth or reality – but this would be a way to implement slack time. In my previous company, Zühlke Engineering, slack time was implemented as 20 days education time every year for every single person with clear rules how to invest this time. Keen managers just care for slack time in their teams and care for a self-motivated mind set. You see, there are many different ways to implement slack time. The important fact is to implement it. Classical managers treat slack time as a thread, as unproductive. There is a general believe in classical management that pushing work into a team or onto an individual will increase productivity. I personally made better experiences with means like communicating a convincing vision, identifying mid-term stretch goals, establishing clear, understood and supported rules and constraints and the creation of a transparent and motivating culture. For sure that is the harder path to go for a manager.

But back to our engineering team and the implementation of slack time there. The reason we decided to implement slack time as 20% of engineering capacity is: engineering, estimating all work as user stories using story points, is very transparent. Engineering estimates even slack time as user stories, so it is transparent to everybody how engineering invests slack time. Other departments are just not that transparent and do not offer this easy mechanism. So this type of implementation is easy and a clear and visible protection for engineering against overload.

As we manage all user stories in Atlassian Jira, it is very easy to visualize the capacity consumption of engineering in a statistic. User stories carry attributes to produce different types of interesting statistics. Following is an example for the statistics over a set of sprints.

Engineering Capacitiy Consumption

There are two interesting questions related to slack time: 1. How does engineering invest slack time and 2. What about 3^rd level support activities and bug fixing for bugs that are not show stopper bugs.

The first question is easy to answer. The sprint backlogs make transparent how slack time is invested. The stories are marked as “engineering” stories. Most of these stories is invest into refactoring and improvements of the system. Some are research stories to experiment with new technology, for example to speed up product search or user interface experience. There are some fun stuff stories as well – but that is where the motivation comes from. This is what I mean with self-motivated. As our strategy is visible and communicated down to every engineer, the Scrum teams identify self-motivated what improves our system and care for.

For the second question, how we manage 3^rd level support and bugs of medium or low priority (class 2 and 3 bugs), we found a very straight answer as well. Nevertheless the way to this answer required quite a lot of discussion and communication because it sounds strange in the first impression.

We decided to move everything (class 2 and 3 bugs, 3^rd level support issues, whatever) as issues back into the department board. It is the responsibility of a department to decide what the next most important thing to do shall be. The mechanism is clear: either it will be a fastlane issue or an initiative for a larger change. If there are many class 2 or 3 bugs that fill the fastlane, this is a learning as well. In fact it does not matter if the bug is because of a false specification or a false implementation. The distinction between “wrong spec” or “wrong implementation” fosters only a finger pointing culture between departments and engineering. That was a long discussed topic: is it really required to know who is responsible for a bug.

We rather decided to treat many small bugs as a sign that the collaboration between department and engineering needs to be improved. Our Scrum implementation addresses this in reviews and retrospectives – and additional in form of review sessions related to the closure of initiatives. It felt strange to many of us just to give back bugs into the departments. Now we can say that this heavily discussed way to deal with class 2 and 3 bugs and 3^rd level support is accepted and treated as simple and successful. Simple solutions are always welcome at Digitec Galaxus. 

Lean PPM step 6: more details on the demand

My last blog discussed the demand capacity game on a coarse grained level based on initiatives in our Kanban board. Initiatives with clear business goals are decomposed ongoing by the teams into epics and backlog items and implemented by the teams.

Pure organizational epics (without software development) are implemented by the functional departments, software is developed by the Scrum teams and all these activities within an initiative are coordinated by a person in the role of a project lead.

That reminds me to write an additional blog about the difference between a business analyst role and a project lead role – and the difference of the position of a business analyst and the position of a project lead; and for sure why we still use the role project lead. These differences and options of misunderstanding lead to many discussion at Digitec Galaxus – and in other companies as well. One reason for this is that an agile company does not know the position of a project lead. We established this position for some reason – but let’s wait until I write this blog.

But back to the demand capacity game. So far it looks like the Scrum teams work only on stories that result in decomposition of initiatives into epics and stories. We at Digitec Galaxus discovered at once that this does not work – at least for us. There is additional demand coming into the Scrum teams. One type of demand is fixing show stopper bugs at once. Another type of demand are small enhancements in any of our software systems requested by functional departments that would increase productivity fast with small effort. An example is the change of a default value in a dropdown, so our users save two clicks several hundreds of time a day. Using initiatives for this type of demand would be the hell of bureaucracy.

So demand flowing into engineering has additional input queues beside the queues represented by the initiative Kanban board. We discussed this and experimented a bit with a very simple solution addressing the input queues for work into engineering. The decision may sound scary for classical management, but luckily our management agreed to experiment. With some small correction the solution works good and found high overall acceptance in the functional departments, in engineering and by the executive management.

The solution is as simple as this: From 100% capacity of the engineering team, 60% are invested into initiatives, 20% are invested into fastlane items coming from functional departments and (!) 20% of the capacity is slack time.

Some explanations to these input queues:

• The demand coming from initiatives is explained in my previous blog Lean PPM step 5: The demand – capacity game at Digitec /Galaxus. So read this blog to understand the mechanism.
• Fastlane is an interesting mechanism to open functional departments a very lightweight, well defined but clearly throttled queue into engineering. All departments have the right to move items in this one queue. I will discuss the constraints on this queue in the following.
• The most interesting mechanism: Slack time. Engineering decides completely autonomous about slack time consumption – with the one and only restriction: Show stopper bugs have to be fixed in slack time. This is a very keen mechanism to minimize the number of show stopper bugs. Show stopper bugs reduce the free slack time of engineering.

Let’s dive a little bit deeper into the fastlane and the slack time mechanism. First I present the fastlane queue.

I mentioned the fastlane mechanism already in my blog “The life cycle of an initiative – step 4”. Every functional department in our company owns a Kanban board to manage and work on their ideas. Everything that can be done within the department itself moves on this board from status “new” over “in progress” to “done”. The large things turn into initiatives and move to the status “idea approval required” to receive an OK or a declined from the innovation board. And there is a status we called “for engineering”. This lane represents the fastlane. In case the department encounters that an idea requires engineering to implement a small change, this item is moved into the “for engineering” fastlane. The fastlane for sure is prioritized as well. The most important small changes are on top.

As every department owns its own fastlane, you can clearly see a new problem: All fastlane issues from all departments compete for the 20% fastlane capacity of engineering. The question is: which issue to take from which department?! As we have seven departments, at every time seven issues are of top priority. We solved this problem as many problems should be solved: by a. a positive communication and b. by a clear assignment for a decision in case the positive communication does not end in a solution within a limited period of time. The communication partners are the subject matter experts of the departments (there is a subject matter expert in every department) together with the business analysts. The decision is assigned to the business analysts. In case the business analysts are not able to find an agreement (what did not happen so far) the head of business analysis takes the final decision.

In average we encounter that our Scrum teams are able to implement about eight to ten fastlane issues per sprint. So actually nobody has a real reason to be unhappy. On the other hand the positive communication between subject matter experts and business analysts creates a transparency about the needs of the departments. This results in a mutual understanding of the needs of departments. And yes, once – what a positive surprise – a department said “well we see, our need is not that important. It is obvious if we implement the need of the accounting first. That will end in a larger benefit for all of us”.

Interesting is for sure the discussion about slack time. Read my next blog for dis discussion.

About energizing people and empowering the team

Maybe you once read the book Management 3.0 by Jurgen Appelo. If not – read it. Especially the chapters of how to energize people and build up motivated teams gave me insights and ideas that helped me in my current situation.  Let’s see and example.

After about two months of working we introduced additional ceremonies to organize our team work based on our daily work that was (intentionally from my side) somewhat ad-hoc organized so far. In this period we all learned what communication we needed within the team and in collaboration with all the other teams we interact at Digitec Galaxus.

My team members were not that happy that I as the boss did not define ceremonies right from the beginning. Becki once gave me the feedback “your listening. That’s good, I like that. But sometime I would like you to decide and define”. That was my experiment in building up the team. My idea and hope was that a certain state of unhappiness fosters the need for change and motivates every team member to think and reflect about improvements. The hard thing is to get the feeling for the right point in time for a change so that creativity for change does not turn into frustration.

By the way, I really like experiments. Experiments are the perfect instrument to develop a complex system – and every system is complex as soon as more than one person is part of the system. Experiments are small changes, tiny measures that are implemented fast. For a certain topic like the improvement of the portfolio process it is good to have a backlog of potential experiments. Then you apply an experiment. As it is small it is implemented fast. You get feedback very fast. Fallback is often possible in case the experiment fails as the change is small and the impact limited. Experiment by experiment you learn about the system and the number of successful experiments increases. Changes are small for all individuals involved and included in these changes. Ideal all individuals in the organization get used to that the system changes continuously. As most experiments succeed, all involved persons perceive change as something that delivers value. 

Well, back to my first experiment in my team. In the meeting itself – we explicitly took team ceremonies as the topic of our BD team meeting retro – the team expected some statements from the boss. Not too bad. I took the chance. But I did not present a solution. Instead I tried to summarize what problems in communication we obviously face and what goals are expected by the organization when introducing our ceremony culture. Additional I presented some alternatives and good practices out of my work experience that succeeded in other companies in similar context. I added some statements about further reading. Then I pleased my team to present their ideas how to organize our team culture.

Luckily my team took as well the chance. Especially Becki and Andi, the long term Digitec Galaxus employees, started to present their view based on their insights and experiences inside our company culture. For sure sharing my experience and ideas biased and influenced. I recognized this carefully. But this is positive. The influence is mutual. We as a team work on a common goal: to identify and agree upon an effective and efficient ceremony culture that satisfies the needs of our organization.

The result was ok, practicable, a good start. It was not the perfect solution. We all knew this. We agreed to start and to improve as soon as we learn more. Meanwhile we changed our team ceremonies by applying about five additional experiments. These improvements often are agreed upon at the end of a meeting. One team member raises its hand and starts: “By the way, I believe we could improve our meeting culture as following…”. Small experiments are agreed upon fast and implemented at once. If we are not able to agree we move the discussion to one of our BD team meetings.

Now, three months after my start I can say that this way of involving the team in all decisions is an essential step of team development. My personal experience and competence out of my professional life is welcome as part of the team and not perceived as “the expert overrules us”. We learned as well – following the delegation model presented in Jurgen Appelo’s book Management 3.0 – what decision are team decision on eye level and what decision are solely on my side as the head of, but still influenced on the important input and shared knowledge of my team.

Now, three months after my start I ran through the yearly performance process with each of my team members. I recognized and honored the open feedback that I got about what is good and what is not so good. But what I value most is that all of my team members agreed that it is fun to work in our team; that they are happy with their job and fully motivated to engage for  Digitec Galaxus. That again motivates me. We are working on a common goal.

Building up a team from scratch – the first steps

You enter the room. Five persons are curious looking at you. Two of them long term Digitec Galaxus employees assigned to the new built department called Business Development. Two of them new hires, one an experienced project manager, one a graduate from university. The fifth a trainee that will work for a trainee time of 6 months in my department. I am myself a new hire with only small knowledge about Digitec Galaxus history and culture.

I had been announced as expert in agile, lean, portfolio management. I had been announced as the one who will help to identify and establish the right way to work and define the portfolio and development processes; as the person that will improve the existing home grown agile way of working into something that enables the next step of growth, while preserving the flexible startup spirit of Digitec Galaxus.  I could feel the one and only one question in this room: “who are you and what will it be like to work with you as my new boss?”

Well it was not that easy this first meeting. In a first round we exchanged our expectations and experiences. Becki was asking for leadership and support as she was missing this for quite a while. Andi and Marcel wanted to develop themselves and act in interesting jobs. Martin, the experienced project manager demanded to take responsibility, Cornelia coming from university wanted to learn and start her carrier. We discussed values and identified our common ground. The common ground was trust – which we need to create – an interesting job with the chance to learn and build up competences, no micro management, open communication and self-organization, mutual respect. We discussed that self-organization and self-discipline are the two sides of the same coin. This common ground was a good place to start from. I marked my first task of my first backlog story – to find a good start as head of my new team – with done.

I knew that the hard part follows. To develop the common ground into a living entity, a team that represents, lives and develops the values that we identified as important.

What we did is to write down our team values on cards, one card per value. Becki proposed to select a random card for the value of the day every working day. Now the value of the day is visible in our team space on a wall and still is changes every day. Oh yes, meanwhile we added new cards. Some are fun like “homemade cookies” or “sleep ‘till noon” – even members from other team started to add cards, which is fun.

Our Team Value of the Day for today: a creative environment 

Meanwhile we introduced Kudo Cards (read the management workout from Jurgen Appelo). As most of us love coffee and the others at least drinks tea we started a regular but still spontaneous morning coffee where we share our weekend or discuss the most important issues in our team. We defined a team ceremony, our monthly BD team meeting for our team retrospectives and to define measures to develop ourselves. We found and agreed about some means and informal ceremonies that support us to build up trust and share experiences. I treat all of this as an important steps to form a motivated team. Let's see how everything develops...