This one continues the series of delayed posts about the sessions that I led or contributed to at the Agile Coach Camp Montreal that took place several months ago. (Earlier in this series: the Marshall Model and the Lean Startup). I’m writing this down to rethink and remember what we talked about.
The picture to be explained was the one on the cover of David J. Anderson’s Kanban book (to the right). The session was an invitation to all Kanban enthusiasts to compare their notes from reading this book and their experiences applying Kanban. People unfamiliar with Kanban had a chance to explore it.
The first set of questions we got out of the way was: who is stuck, who is too busy, who is idle, why, and what is their role on the team. The book had been in print for more than a year, so everyone knew the answers. If you want to know, read the book and/or talk to someone in your local agile community, they’ll explain.
How to Kill Kaizen
More interesting were the questions about trying to improve the situation. One option we didn’t consider was to simply increase work-in-progress limits. That way we can give someone who is busy with three tasks a fourth task. And someone who has started more tasks that can fit on the board can start even more. This option means doing things the same way that got the team in this difficult situation and avoiding the conversation about improving the process. It ensures that the team will not benefit from kaizen, the culture of continuous improvement.
Limit WIP Upstream
The first option suggested by the group was to reduce WIP upstream. Indeed, if we reduced it from 20 to 10, this would underutilize the analyst, but would shorten his feedback cycle from 23 cards to 13, probably improving quality of whatever he is doing. The team’s throughput may about the same, but the quality will likely go up. Interesting that such result may be achieved by working less.
Hire More Developers
This option is often considered and taken by managers of real-world teams. It obviously elevates the bottleneck, doubling its capacity. But it does nothing to address the flow problems affecting the team. The prolific analyst can still overwhelm the developers and, as the total WIP goes up, the feedback cycle will lengthen, putting quality at risk.
Five Focusing Steps
The Five Focusing Steps method, introduced by Eli Goldratt in The Goal states that before elevating the bottleneck, we should exploit it. The exploitation action is often away from the bottleneck, so that makes it very clear that hiring another developer right away is not the solution.
One source of inspiration for such exploitation solutions is the Goal episode when Jonah (the wise consultant) visits Alex’s plant. Shortly before leaving he asks: “One more thing. Show me where you do quality inspection on bottleneck parts.” Interesting that Jonah asks where, not how. All he cares about is if the quality control is ahead of or behind the bottleneck.
What follows from here is not about the team on the book cover – we don’t know enough about them to say this will solve their problem – but it’s a real solution for real-world teams as long as it fits their context. (Everybody who attended nodded their heads here.)
Let’s move the idle tester over to collaborate with the analyst and, assuming the tester has some automation skills, get specification by example going. Automated acceptance tests make the developer more effective and reduce the amount of defects that escape into the testing phases. The tester presumably will still have some time left for exploratory testing.
Together, the attendees redrew the book cover picture on a flipchart to look like this:
We’re not stuck, I’ve got slack, I’m kinda busy.