Kanban for Skeptics

At the beginning of his book Kanban for Skeptics, Nick Oostvogels says “By listing the 5 most common arguments against Kanban and my response to them, I hope to help people in their Kanban journey and build great organizations that create amazing products.”

I will say that this goal is fairly well achieved… and there is even an additional argument against Kanban answered at the end of the book. In a rather short (70 pages) book, Nick Oostvogels takes the time to discuss five arguments for not using Kanban as a software development project management approach, after a short introduction to the Kanban principles. These arguments are:
* We lose our ability to plan
* It will take longer
* Things will get stuck, we can’t keep WIP limits
* Stakeholders don’t care about feeding the flow
* We will lose team cohesion

The book is easy to read and you can see that the discussion is based on his experience, the book has indeed a perfume of “Kanban from the trenches”. The Kanban journey is not an easy one and Nick Oostvogels never underestimates the challenges of adopting Kanban principles, specifically in a software development context. In the conclusion, he says, “But beware that the difference between theory and practice is significant. Kanban will not suit every organization or team.”

I will recommend the book Kanban for Skeptics to every Agile practitioner, project manager or software developer that wants to expand his knowledge of Kanban to see if it can be applied in a software development context.

Reference: “Kanban for skeptics – Clear answers to Kanban in software development”, Nick Oostvogels, https://leanpub.com/kanbanforskeptics

Quotes

The type of questions Kanban raises, seem to be hard to answer without lapsing into an hour-long discussion. I guess this is normal because Kanban is much less prescriptive than Scrum, for instance. In order to provide reassurance, as a coach, you need to trace the questions all the way back to the principles of Kanban, which are grounded in Lean thinking.

A critical success factor for Kanban which many tend to forget is reducing variation. Implementing a pull system will lead to a continuous flow. And this means that it needs to provide value in a regular cadence.

There is no exact science on determining WIP limits. As soon as they are chosen, bottlenecks will appear. This doesn’t have to be a disaster. When the organization embraces the idea of a pull system, they will understand that WIP limits help to improve end to end efficiency. The first signs of a bottleneck appearing will drive continuous improvement.

Many IT-professionals are still in denial, thinking they can design an entire new application without programming a single thing. Reality has proven that the gap between a useful application and its initial design doesn’t shrink linearly when investing more in the upfront study. Instead, it’s much more interesting to minimize the initial investment and use a feedback model that allows you to test ideas fast. This way, a team can validate all the initial hypotheses and learn what really matters to their customers.