Most practitioners think Kanban is all about finding and fixing bottlenecks. That’s not true.
The above sentence may seem strange given that I am writing a foreword to a book that is about - amongst other things - applying the Theory of Constraints (TOC) to flow. But bear with me and I think we will get this all sorted out.
To understand the misconception around Kanban and TOC, we must go back to Kanban’s very beginnings (at least for knowledge-work, anyway). My intention is not to waste your time rehashing the origins of Kanban - others have done that better than me (specifically, I refer you to Darren Davis and his excellent video and blog, “The Secret History of Kanban and Why It Matters”). What is important to emphasize, however, is that from its very beginning, Kanban has always been about an attempt to achieve flow.
“But,” you may ask, “isn’t removing bottlenecks what achieving flow is all about?” In a word, no. The problem is that every time someone in the Kanban community hears the word “bottleneck”, they want to rush in and immediately apply TOC. This misapplication of TOC is why Steve and Daniel’s book is so important. By reading this book, what you will learn (amongst many other things) is that the application of TOC to a bottleneck that is not the true system constraint will usually only serve to make things worse. This is why the management of flow is so tricky. What looks like genuine, constrained flow (i.e., “bottleneck”) may in fact only be a transient condition caused by some other process variability. Applying TOC in this case would be much like using a shotgun as a fly swatter.
Unfortunately, this misunderstanding has permeated and persisted within the Kanban community since its very beginning. This book fixes all of that.
Please do not mistake me: Steve and Daniel’s work is not just a recipe for how to apply TOC to achieve flow. Rather (and this is what I love about what they have done here), it is a thought-provoking discussion on how to deeply examine your process to identify the opportunities for improvement that will provide the most bang for the buck. Visualization, though important, is not enough. Limiting WIP, though important, is not enough. Only a deep understanding of the principles of flow and the factors that affect flow will yield true, overall process improvement. And, by the way, if you were assuming that this stuff only applies to work being done at the lowest team level, then think again. Improvement must be sought at all levels of the organization (team, project, portfolio, etc.) and across all dimensions of flow (work, knowledge, value, etc.)
There are dangers lurking out there that we must be mindful of: flow is unintuitive; much of what is talked about in the Lean-Agile circles concerning flow is simply wrong. These reasons are why this book is such a critical addition to the Kanban literature.
I do not pretend to understand all of what Steve and Daniel talk about, but I am sure glad that they have invited me along for the ride. You should be too.