I caught a great interview this week with J. B. Rainsberger. In this interview he gave toÂ Marko Keba ofÂ agile.hr, J.B. talked about managing slack. Naturally this got me thinking about what I do within my team to create this slack. If you want to listen to the interview that inspired this post then it may still be available here andÂ its well worth a listen.
Why slack off?
In the interview J.B Rainsberger spoke about how creating slack and performing tasks that are not directly attributable to features with business value can help reduce volatility in the cost of adding features of time. By working at full capacity continually your teams will not have time to improve or maintain their productivity. The code design if not maintained and nurtured over time will exponentially decrease causing features that seem relatively simple in complexity to become bloated and far more difficult to implement than expected. This will clearly effect both developer productivity and your teams ability to react to the market, delivering business value into production quickly.
What slack should consist of?
J.B Â doesn’t go into details around what practices or tasks should be performed within the slack as these will be specific to your environment and business but he does mention techniques such as Value Stream Mapping to identify where the problems are, where the bottle necks occur and where the extra work is hiding.
How we negotiate managing slack
The tasks that you perform and how much time you spend doing this as developers should always be negotiated. You will need to justify your investment in these tasks and learn how to sell these ideas to your Product Owners. Hopefully your Product Owners will already have an awareness of the pay-off that this can give but just in case, you will need to be prepared. This may be a challenge as the immediate paybacks may be difficult to see.
My approach to this was to negotiate a percentage of time each sprint, creating slack to perform these tasks. By doing a small amount every sprint you reduce the impact on your teams velocity as the velocity will naturally balance to the incremental effect. This also brings about a metronomic habit to continually take care of your code base, call it gardening if you will. The iteration based pruning is far better than a big bang approach wiping your team out for an entire Sprint as the big bang approach is not sustainable and the important part of providing slack is that it is a continuous process. Additional benefits come naturally with all processes that we do in small batches.
What activities are we doing when we are slacking off
As the team go through their daily work they should be automatically recognising work items that would be considered technical debt. These items often build up as a result of not having any slack, going too quickly or a concious decision to take short-cuts in order to deliver on schedule. (Reduction in quality over time or scope) These items are prime examples to improve given some slack. Your team may already have a backlog of these items.
In the same way we refine the backlog our team refines the event log messages. The event logs are one of our views on the health of the system so it is important that we can judge this at a glance. Removing false positives and re-prioritising warnings to errors and vice versa are all things that can be done to improve the system both for developers and for our operations team. (DevOps). Refining these items highlights work that needs to be done. This work is not always seen as being directly attributable to business value and is therefore a great item for slack.
Tests should always be considered production code and in the same way you will build up technical debt in your test code f you don’t continually take care of it. During time set aside for slack testing is a great spot to tackle. Improving the readability, reliability, coverage or general design are all must dos when slacking off.
The more often you give yourselves time improve the easier it will be and the less likely you are to fall into the trap of bloated estimates and never ending stories.