I’m really glad that David Anderson finally published a book on Kanban, not least because Kanban is a very hot topic at the moment and there is a lot of confusion around that method in the industry. I recently met a team that, under the excuse of moving to Kanban, decided to disperse with whatever little discipline Scrum introduced in their work and moved back to complete chaos. This book is finally an authoritative resource that shows that there is a lot more to implementing Kanban than buying a cork board and as such will be very welcome in the community and sure to be a must read for all managers and teams interested in improving their software production processes.
In the book, Anderson demonstrates how to implement Kanban in practice with two real world case studies in the software maintenance domain. I found the case studies especially interesting as they show real experience and they are presented in enough detail to retrace the steps and decisions made, the reasons behind the decisions and their impact and outcome.
This book helped me fill in a lot of gaps in understanding of the Kanban method, especially around introducing service levels for delivery and the power of using average lead time instead of expensive estimation games. The “recipe for success” to introducing Kanban by focusing on improving quality is a fantastic idea. I found this approach generally very powerful to introduce change and reduce resistance - in any place you can find people that will object to introducing Kanban, Scrum, XP or any other change - but very few people are going to object to an initiative to improve software quality. Several teams I interviewed for my new book used this approach while implementing agile acceptance testing.
It’s a real shame that building software from scratch got just a single, very theoretical chapter. Instead of case studies, Anderson presents general ideas here. For example, he presents three strategies for managing shared resources (eg a database), including one that seems to suggest using component teams. There is no context, comparison between the three approaches or advice when to apply which model. I would have loved to read more about applying Kanban for such projects. This way, the book cemented my feeling that Kanban works best on maintenance of relatively mature products.
In any case, this is a great book and well worth the read.
