At 7digital, the team I am part of uses a Kanban system. All I knew was that it was some dialect or deviant of agile. With such a minimal level of understanding, it seemed best to read a book.
This book was suggested to me by the team lead. So I snapped up a copy (at the company's expense) and had a goold old read.
It turned out to be an enjoyable read and definitely helped me to understand why the team here chose to use it......
What is Kanban?
In some companies, work might be pushed onto a team that is already occupied by other work. With more work coming in than going out, it is a recipe for worker overload. One feature of kanban is that it avoids this problem by being pull-based - work is only taken on when there is capacity for it.
According to this book, kanban was in successful use at a Toyota manufacturing plant in Japan. But the author of this book shows how it is used to improve software development processes.
Case Study, Theory and Implementation
A branch of Microsoft working remotely in India is the basis for a case study at the start of the book. The author talks about them being awfully inefficient and being renowned for poor service in many ways.
In a nutshell, the author advises the team's new lead to adopt kanban in a succession of small steps. And as you can guess, the team becomes a raging success and kanban is hailed.
Section two of the book focuses on the theory of kanban. It introduces concepts like WIP (work in progress) limits, Kaizen (well being and happines or something like that), and the social cultures that kanban will encourage.
According to the theory, kanban will increase throughput, efficiency, and lead time predicatability.
Section three of the book then moves onto how you can implement kanban in your team. There is a focus on setting up a card wall, how to deal with bottlenecks, and how to keep staff from becoming idle by introducing buffers.
Throughout the book the focus is about finding out what works for you. Taking the philosophy of kanban and slowly adding these ideas to your environment in small steps. After doing so you are encourage to monitor and adjust to find optimal working conditions. I see this as a good thing - it's not a rigid model that is enforced upon you.
It did, though, seem like the author had great success with kanban, and was very keen to push the benefits of it. He could be totally correct, but I felt on occassion that maybe he was being a bit of kanban fanboy (nowhere near the level of a REST fanboy).
I enjoyed reading it and thought it was well-presented with an excellent balance between the theory of kanban, practical examples and how you can implement it yourself.
If you have a development team of over-worked, over-stressed, and under-motivated people, then learning about kanban might be one of the best things you can do. If that does sound like you, then I think you would benefit from reading this book.
I'm sure other people would enjoy reading and get benefit from it too.