Kanban Book Review

I just finished reading Kanban and Scrum - making the most of both, by Henrik Kniberg and Mattias Skarin. You can download it for free. I was very impressed by this self-published book, enough so to place an order today on Lulu for a paperback version.

Despite my readings of blogs and listening to podcasts on Kanban, it still wasn't clear to me. Knibert and Skarin broke it down so clearly for me that I finally got it. They took a simple approach, used lots of drawings, as well as comparisons to Scrum that helped related it to something I did know.

Here are some of my favorite quotes from the book:

As teams evolved from individuals to self organizing units, the managers realized they were facing a new set of leadership challenges. They needed to deal more with people issues – handling complaints, defining shared goals, resolving conflicts, and negotiating agreements.
...
The WIP limits are there to stop problems from getting out of hand, so if things are flowing smoothly the WIP limits aren’t really used.
...
The only thing that Kanban prescribes is that the work flow should be visual, and that WIP should be limited.
...
What should the Kanban limits be?
When the Kanban limit for “your” column has been reached and you don’t have anything to do, start looking for a bottleneck downstream (i.e. items piling up to the right on the board) and help fix the bottleneck. If there is no bottleneck that is an indication that the Kanban limit might be too low, since the reason for having the limit was to reduce the risk of feeding bottlenecks downstream.
...
If you notice that many items sit still for a long time without being worked on, that is an indication that the Kanban limit might be too high.
•    Too low kanban limit => idle people => bad productivity
•    Too high kanban limit => idle tasks => bad lead time

...value stream map. It’s basically a visualization of the value chain and provides insight into work states, flow and time through the system (cycle time).

Over time, managers learned that if they kept number of concurrent projects low, they didn’t keep stakeholders waiting.
The need to project delivery date was no longer a big issue. These lead managers to stop asking for up front estimates. They only did if they feared they would keep people waiting.

And I particularly loved this approach with management, and of course their results overall:

But keeping traction on complex, infrastructure type issues was a harder ordeal. To deal with that we introduced the ability for teams to assign up to 2 “team impediments” to their managers.
The rules where:
1. Manager can work on two slots at any single point of time.
2.    If both are full, you can add a new one as long as you remove the less important one.
3. Team decides when issue is solved.

Three months after introducing Kanban, the system administration team was awarded “best performing team” in the IT department by the management. At the same time, the system administration team was also voted as one of top three “positive experiences” in the company retrospective. The company retrospective is a company-wide event that happens every 6 weeks, and this was the first time that a team turned up on the top 3 list! And just 3 months earlier these teams had been bottlenecks that most people were complaining about.

For those trying to learn about Kanban, or those responsible for leading, coaching and/or training Scrum in your company or for clients, I highly recommended this book.

Technorati Tags: agile, kanban, lean, scrum