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.