Kanban [Paperback]

David provides a comprehensive guide to implementing Kanban in a software development/maintenance environment.
Covering the mechanics, dynamics, principles and rationale behind why Kanban is a so promising framework for managing the work of a variety of teams and groups and being an evolutionary-based change management driver.

Kanban is the practical approach to implement Lean Software Development, and this book is the practical guide for how to start using Kanban, and how to adapt the system for advanced needs.

The book is clear and flowing, even though it covers some quite technical material. I would recommend it to Development managers, Project/Program managers, Agile Coaches/Consultants. It addresses concerns/needs of Novice as well as those already familiar with Kanban and looking for advanced answers.

Even if you don't intend to implement a kanban system, there are a lot of techniques and ideas that are easily applicable to any product development/maintenance environment, agile or not.

Review

I don't do technology development, most of the work that I do is on the business side of the organization, understanding requirements through business process and business architecture (as described in the pages of the book Rethink).

Starting as early as the foreword, there are great takeaways in every section of this book which is a very quick read. I will admit that I skimmed some of the software development segments because that's not what I do, but here's a breakout by some of the early chapters:

FOREWORD - the notion of the importance of batch size is vital when looking at organizational constraints. It's something Goldratt never addressed in the initial Theory of Constraints, but it's a great point. There's a lot more about that as the book moves along, but it's a great first point.

CHAPTER ONE - Context is vital when identifying organizational constraints. If someone goes into a meeting and points out that something is constraining the organization, even if they may be right, the other people in the room may have a different context and dismiss the newly identified constraint. Chapter one also goes into good depth about seeing that no two projects or teams are the same, and that there are specific, quantifiable risks in how you compare them.

CHAPTER TWO - Here is one of two chapters where Anderson does a great job of stepping outside of the work environment to explain that the notion of kanban, which literally means signal cards to indicate when it's OK to proceed with work, applies to lots of situations in the outside world, and his example of the cards they hand out to entrants to a park in Japan, and then collect when they leave, as a very simple and low cost way of managing the attendance capacity of the park. With such a clear example, the core idea of kanban, Anderson ensures that the reader understands one of the most basic ideas of the book.

CHAPTER THREE - This is where the book starts to get really quantitative about measuring and optimizing the throughput of work, and here's where Anderson gets into one of the other core ideas of the book which is to limit and manage the amount of work in progress (WIP). As he points out (graphically) there is a linear relationship between WIP and average lead time, which he explains very clearly. The other big point he makes in this chapter is that there is a non-linear relationship between defects and the quantity of WIP, which means the more WIP, the higher the defect rate.

CHAPTER 11 - After several chapters about continuous improvement, how you go about limiting WIP, and more software development related cycles (which broadly still apply to non-tech people as well in terms of managing efficiency), Anderson then gets into a subject that I think is vital, which is identifying the Class-of-Service definitions for objects of work, which include Expedite, Fixed Delivery Date, Standard Class, and Intangible (which he admits is probably not the best word for it), and in my experience it is so important to have those sorts of definitions attached to blocks of work, I am confident that I will use them as he defines them. While he does talk about process definition and how you need to make processes strict and policy based, I happen to think those belong more in the realm of business architecture because business capabilities as artifacts are so much more durable than processes (as defined in the classic Hammer & Champy model).

There's a lot more in this book, but it's so clear and so well written I think a lot of business people, as well as technology people can learn a lot from this book and start applying it to their work immediately. By Ric Merrifield "Eric S. Merrifield, Jr.