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.