(Note, this post is about slack the concept not Slack the collaboration platform. Though Slack the platform is great as well. We use it at AgileSparks and love it, although it eats up some of our slack time…)
Actually, the title is wrong. I think slack is highly important during any change initiative where you expect continuous improvement of the process and practices. The importance of slack is not new. Not in manufacturing, and not in the Software Engineering world. One of my favorite books is Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency by Tom Demarco. Actually anything by Tom is a gem worth reading if you’re serious about managing Product Development organizations… But today I had an epiphany. One of the biggest challenges we face as consultants trying to challenge organizations to be more effective/agile/lean, is that the people simply don’t have enough slack. They don’t have enough time to meet with us. They don’t have enough time to meet and retrospect. They don’t have enough time to experiment. Experimentation takes time – you need to think about what to try, if you take a risk, there is a chance you will fail and lose time. Its very frustrating as a consultant/coach. You have so much to give, you see so many opportunities for improvement, you know that if the team will just sit in a room for an hour they will come up with ideas that can help. You know that if that Developer from the team has some slack time on his hands, he will think of a way to make that build run faster. That test automation suite easier to update.
To effectively use slack I think you need to do two main things:
- Account for slack in your resource planning.
- Have effective mechanisms to use the slack for the best possible purposes.
Accounting for slack in the plans This is quite straight-forward as soon as you convinced your stakeholders it is a worthwhile investment. Pointing them towards Google (20% time…), Atlassian (20% time and FedEx Day) and other companies using slack as a core part of their system, might help you. Technically, just reduce the resource capacity % in whatever method you are using to manage your projects/commitments. Another great way is to use the slack that is inherent to the plan/development process. What do I mean? For example – in a Kanban/TOC/Flow system the bottleneck doesn’t have any inherent slack. But upstream and downstream from it, if you work in Pull mode, you will find slack. This is because they can process faster than the bottleneck, so obviously there will be times they cannot process because they are bound by a WIP Limit (Or TOC Rope). In Iteration-based Agile this slack takes the form of some free time on the last few days of the iteration if you’re not the tester. In both these scenarios when you have slack, you can either throw it at the bottleneck’s current work, or use it in other ways.