I have finished to read the book Kanban from David J. Anderson and I want to share some thought and comment about it. At my current project (non agile organization) we are approaching the Kanban methodology after some years of Scrum.
First of all… If you don’t know what Kanban is, next paragraph is for you :).
What is Kanban? Well, I could try to give my own definition, but would be wasted time, so here a comprehensive and complete definition found on Wikipedia: “The name ‘Kanban’ originates from Japanese, and translates roughly as “signboard”. Kanban traces back to the early days of the Toyota production system. Taiichi Onho developed 1940/1950 kanbans to control production between processes and to implement Just In Time (JIT) manufacturing at Toyota manufacturing plants in Japan. The Kanban method as formulated by David J. Anderson is an approach to incremental, evolutionary process and systems change for organizations. It uses a work-in-progress limited pull system as the core mechanism to expose system operation (or process) problems and stimulate collaboration to continuously improve the system. One example of such a pull system, is a kanban system, and it is after this popular form of a work-in-progress, limited pull system that the method is named.”
If you want to know more about Kanban, you should indeed start from the latter and read the book of David J. Anderson – easy to understand – although from the total 250 pages, most of the concepts could have been explained within half.
The whole definition seems complicated, but in practice is quite simple. There is a lot to learn on the relations around the team (customers, external teams) which is more complicated to manage (depending on the nature of the organization you are working for), but the principles to be applied within the team are quite straightforward:
- limitation WIP (work in progress)
- continuous delivery
- continuous improvement
Despite the fact that this book is considered the main reference for the Kanban experts and followers I have found it too verbose. It is full of examples coming from personal experience of the author or people close to him. I do not think that experiences explained in books are as effective as in a speech or a course: while talking face to face, you can easily choose the right piece of your experience that better fit the topic you are covering, or the answer you are answering. Examples on a book should be referring on something else, for example on chapter 17, when is referring to the bottleneck created by a bridge/ferry on the 3 lines highway.
I’ve also found some free sarcastic comments about the “Scrum’s advocates” that were unnecessary.
In the next article we will see some truth and myth around Scrum and Kanban.