Scrum is a great adapting tool. But does it adapt fast enough?
We discover we are running late and here we dealt with the problem by descoping. But did we act too late? And what caused it? Let’s plot our feature development phases on a timeline:
Obviously testing is a bottleneck. Maybe we lack test resources, or automation. But this is what causes our burndown to flatten and a buildup of unfinished work. Unfortunately for us, it remains hidden.
Now let’s see how a Kanban board could give this situation away. We make phases horizontal slices (and projects team is working on vertical lanes).
Can you spot the problem?
Yes. The queues gives away the bottleneck.
Queues are excellent problem indicators. The beauty with Kanban is that problems can be seen at an early stage and by the glance of an eye. So it helps visualize problems early and for everyone – including the occational manager. 🙂
7 responses on “Why Kanban can tell you more than Scrum”
I certainly agree about the enormous value of visualizing bottlenecks early.
I don’t understand your comparison with Scrum though. Why would a Scrumboard not tell you the same thing?
I find scrum boards generally harder to oversee, especially placement of bottlenecks and distribution of work.
My goal is, make it possible for anyone (even outside team) by the glance of an eye to get immediate understanding of bottleneck placement and how work is distributed. This is similar to how a Toyota manager can walk through the production and immediately spot problems by just looking at accumulation of queues.
A Scrum team could of course get similar benefits by applying more status fields at their boards 🙂
Doesn’t a queue imply handover?
Yes, but in some cases there is not an option.
>Yes, but in some case there is not an option
True, but there is an option in your examples above. For example, the dependencies between the Design, Code and Test activities are complex and never (in my experience) a linear flow, as implied by your kanban.
I would argue that these three activities can (and possibly should) all be represented under a single activity … perhaps as “Work In Progress.”
Wouldn’t that just hide the problem?
Thank you for the post. I like how you laid this out.
Many of the teams I coach on Scrum use task boards that look like a Kanban board (Story->Task->In Progress->To Verify->Done) and also put up burndown charts and impediment logs with visual indicators. Just had one ScrumMaster today put their big roadblock right on the burndown chart so that management could see it right away.