Bill: Welcome to my interview with David Anderson. David is the Chairman at Lean Kanban Inc. I first became aware of David and his pioneering work in Kanban when I attended his session at a conference. With that introduction, I’m excited to have the opportunity to talk with David today. David, I’ll get right to the question if I may: what is your best improvement strategy or tactic that has worked really well for you or your clients?
David: I developed the use of virtual Kanban systems for controlling the work that people have in progress. That has evolved into something that gets referred to as the Kanban Method for catalyzing incremental improvements. You find the number one problem, fix it, then the number two problem gets promoted. This evolutionary incremental approach to improvements is my number one process improvement strategy. The number one problem I’ve seen with clients and in places I’ve worked is that people resist change. So finding an incremental, evolutionary approach to change has been the one best thing that I have in my tool box. And currently my favorite way to create such change is through the use of virtual Kanban systems.
Bill: David, because I have a manufacturing background and I’ve worked with clients who used Kanban in manufacturing operations, I never imagined it would get applied to this environment. What were the challenges? How did you get to point of using Kanban? Were you familiar with it from manufacturing?
David: I wasn’t particularly familiar. There were a number of other things that led up to having this ability. The key insight was recognizing that we could track the flow of knowledge work activities, like software development, by identifying different states of completion of the work. These could be tracked in something called cumulative flow diagrams, which are a way of visualizing the quantity of stock or inventory that’s in a factory at different stages of manufacture. That technique wasn’t necessarily, at that point, using the idea of a virtual Kanban system. With a Kanban system, there is a fixed limit to the work-in-progress, which is controlled by the number of Kanban cards in circulation. However, tracking flow and mapping it using cumulative flow diagrams was the enabler and the recognition that if we could visualize and manage the quantity of work-in-progress, then it was just a small step to actually limiting it (with a Kanban system.)
The key insight is that in knowledge work problems, the Kanban are not physical; it’s just a virtual concept where you agree to limit the work-in-progress to some quantity of something. That sounds very ethereal because it’s hard to pin down what these things are because they’re not physical. So for example, the requirements for a software system; each individual requirement would be treated as a unit of inventory or a piece of work-in-progress that’s limited by Kanban. There were a number of key insights that made this possible: the idea that you can identify individual items of knowledge work in some way and map them as if they’re inventory in a manufacturing system; then track the state of completion and map that flow; and then restrict it at different stages of completion using a virtual Kanban mechanism. All those things came together, but that in itself doesn’t sound very interesting; it doesn’t sound like it would be worth anything. Why would you want to do it? The results are really very counterintuitive.
Bill: A question that’s occurring to me based on what you just said is that this sounds very similar to Lean and Agile types of methods. How would you contrast Kanban with Lean and Agile methods? Does it belong in that camp or is it something different?
David: I see it as something different!This is because I came to discover this technique as I perceived that people, companies, and organizations were resisting the adoption of Agile software development methods. The idea that you try and persuade people to switch to some defined method that’s written in a textbook, and make that switch all at once, was prevalent particularly in the earlier part of the last decade. This approach is what people were resisting.
Agile methods were really sold as an all or nothing bet. They were marketed as fragile ecosystems where you had to, for example, do all 12 practices in Extreme Programming or it wasn’t guaranteed to work. So adopting all 12 of those practices all at once was very challenging, and there was really no guidance on how to incrementally adopt the practices in Extreme Programming in those early days. To be honest, even today, there are very few Agile coaches and consultants who are capable of correctly assessing a context and advising a client on incremental adoption.
The critical difference is that Kanban is not a method, like an Agile software development method, or a project management method. It’s a way of provoking and catalyzing changes in an organization. What those changes might be is contextual, situational and will be unique for each different organization that tries it. Some people have used the term meta-method. I’m not particularly comfortable with it because I prefer plain language, but the idea that Kanban is a meta-method for incremental evolutionary change, maybe that’s accurate! In comparison, a typical Agile software development method is a way of doing software and you have to switch from what you’re currently doing to adopt it, and that’s clearly a whole different thing altogether.
Bill: I’d like to ask about the provoking and catalyzing change part of Kanban, David. What is it about Kanban that makes that happen?
David: It’s primarily the virtualization of the invisible knowledge work combined with the work-in-progress limit that exists at any one stage in the development of a piece of that knowledge work. The reality is that there is a lot of variability in the work that we do. Every requirement is unique and different, involves different technical complexities and different risks, and perhaps involves different people. There are lots of dynamics going on in the workplace. The result is that the flow of work ebbs and flows. When there’s no limit to the quantity of work people are doing, if they have some sort of impediment or some slack, they just go and start something else, and gradually, the quantity of work in progress grows and grows and a lot of it gets stale.
David: It’s primarily the virtualization of the invisible knowledge work combined with the work-in-progress limit that exists at any one stage in the development of a piece of that knowledge work. The reality is that there is a lot of variability in the work that we do. Every requirement is unique and different, involves different technical complexities and different risks, and perhaps involves different people. There are lots of dynamics going on in the workplace. The result is that the flow of work ebbs and flows. When there’s no limit to the quantity of work people are doing, if they have some sort of impediment or some slack, they just go and start something else, and gradually, the quantity of work in progress grows and grows and a lot of it gets stale.
Another critical insight that I didn’t mention earlier is the idea that knowledge work is perishable. The faster you can turn an idea into something that works and is complete, generally, the better quality it is, and the more demand or need for it there is with the market or the customers or the users of the system. Unlimited growth in work-in-progress is bad, and what a Kanban system does is it prevents people from starting things when they experience variability from impediments, or simply the natural ebb and flow of things, causes them to be idle.
Because people can’t start something new, it seems to have the effect of provoking the inquisitive nature of knowledge workers and particularly software developers. They will start asking questions about, “why it is I am idle, other than the fact that the Kanban system is preventing me from starting something else? What is it that caused us to reach the limit and for me to be unable to start something new?” So that makes them inquisitive and they go ask or start studying the dynamics of the work that they’re involved in. This tendency reveal things which have always been there if they’d troubled to go and look. The effect is that they start discussing it with their colleagues, and improvements get suggested and introduced. The work-in-progress limit is what causes the conversations to happen. It causes this inquisitiveness, and in turn, it causes conversations, and those conversations turn into process changes.
Bill: David, I’ve learned a lot of unexpected and valuable things about Kanban in the past few minutes, and I’m sure many readers will have the same reaction. Where should people go to find out more about Kanban?
David: There are a number of good resources. Reading my book, Kanban: Successful Evolutionary Change for Your Technology Business, is probably the best and most definitive. If someone was interested in learning about Kanban, Lean Kanban University, or more books at Lean Kanban University Press.
Copyright Notice
© Bill Fox and FORWARD THINKING WORKPLACES, 2019. All Rights Reserved. Unauthorized use and/or duplication of this material without express and written permission from this site’s author and/or owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Bill Fox and FORWARD THINKING WORKPLACES with appropriate and specific direction to the original content.