Sure! So I don't know how well you can capture this picture here on the cover but for me this picture really summarizes the essence of what we are doing with Kanban and this cartoon was drown by one of my former staff, really talented guy called Pujan Roka. He's actually written a couple of management books himself but he's very talented comic strip artist. And he was on my team about ten years ago when I was a manager with Sprint PCS. In this picture you will see that we have a team of software developers, or testers, analysts, cross-functional team, and they're doing the morning standup meeting in front of a board that shows the workflow. And the tickets on this board are representing different pieces of work maybe user stories, features requirements something like that.
And the conversation here is the first guy on the team reports: "I'm stuck!" and the next girl says: "I'm too busy."The guy strangely wearing a tie here says: "I'm idle." And, finally, the leader of the standup meeting - the Scrum master or team leader-- says: "You know what? Let's do something about it. And this is the essence of what we're doing with Kanban. We're visualizing problems with the work of the team and the workflow and stimulating the team to think about that to have perhaps difficult conversations they wouldn't necessarily have or want to have and to start making changes to the process and to fix these problems. If you study this picture really carefully the tickets on this board and the design of the board are very carefully chosen. And the picture works very many levels of depth.
A skilled Kanban coach can look at this picture and tell you which of these people does which job. And they can tell you what the dysfunction on the team is and what changes need to be implemented. And someone who reads the whole book and becomes skilled in the art of doing this can diagnose a tremendous amount of information from this picture. So I commissioned Pujan to draw this. There's a lot of thought that went into the detail. And this tells you a tremendous amount about what the book is about. And as people read it and learn that, they'll see this picture in several levels of depth. So, for me, Kanban has been an approach to change and I document this at the beginning of the book.
I talk about my work as a manager at Sprint. And then a little later on at Motorola where I was leading software development teams and trying to do Agile development. And it was working quite well on my team. Well enough that usually management more senior than me would say: "You know, could you just help these other teams to do what your team's doing? So we would try it on. And what we met was tremendous amounts of resistance and it wouldn't institutionalize very well. After perhaps a year those other teams would give up in doing it. And after two "go's around" of this, by about 2004 I was sitting down thinking there really has to be a better way to make software development more agile (agile with a small "a").
There must be a better way of producing better business results, better economic outcomes, better team performance with less resistance. And going through the process of writing my first book and studying a lot of other materials constraints- Theory of Constraints and Edwards Deming, and Lean. And the conclusion I'd come to was that there was an approach to introducing change in an evolutionary, incremental way. And, primarily, my inspiration for that was Eliyahu Goldratt and what he calls the Process of Ongoing Improvement or the POOGI.
And that's achieved by using his flavor of a work in progress limited pull system that he calls "Drum-Buffer-Rope." Without getting into the weirdness of that metaphor, "Drum-Buffer-Rope" in manufacturing is a way of limiting the quantity of work in progress in a factory. Using that to highlight where there's a bottle neck or some capacity constrained resource and then following a theory to fix that capacity constrained resource. The word he uses is elevate it to get more throughput through the system. Once you have done that you find the next one, and the next one, and the next one.
It's an iterative process in finding a bottleneck and doing something about it, and finding the next one and doing something about it. So I was inspired by that and I thought that it would be interesting to give that a try. Then I had some good fortune in October 2004 when a manager at Microsoft approached me and said that he has just taken or volunteered to take control over team that had the worst record for customer satisfaction in Microsoft's IT division. They were considered the worst performing team.
He wanted to fix that and he thought that I might be able to help him. So, we tried this approach. And we weren't very long into it when I was having a conversation with Donald Reinertsen and he was taking about tradeoffs between the Drum-Buffer-Rope approach and the Kanban approach. It turns out that there is actually a whole family of work in progress limited pull systems. You can research this in the literature they have names like "CONWIP" and then there is Drum-Buffer-Rope Drum-Buffer-Rope and there's Kanban.
Then there are hybrids of some of these things and some things they have slightly more exotic names. I've seen a hybrid of CONWIP and Drum-Buffer-Rope referred to as CapWIP, for example. Don was arguing with me that Kanban was a better approach than Drum-Buffer-Rope for some very esoteric reasons that I don't even get into in the book because it doesn't really matter unless you are an industrial engineer and you really want to know the theory. So that was fine. But I went back and took a look on what we were implementing with this team at Microsoft and I thought OK if I put a Kanban hat on here and think about this problem as Kanban rather than Drum-Buffer-Rope I would be different.
And I thought that through and designed what the implementation would look like and it turned out to be identical to the Drum-Buffer-Rope. So two different ways of thinking about it produced an identical design for that team. So I thought, OK that's fine. If we thought that with the Kanban hat nothing would be different. And over a period of months that team trebled its output, trebled its throughput and they reduced the cycle time by 90 percent and they improved the predictability by 98 percent -- from 0 percent on-time delivery to 98 percent on-time delivery. And it was very successful.
I thought ok let's try it somewhere else, recognizing that we could do these incremental changes. So the idea with Kanban it's not a project management methodology and it's not a software development lifecycle method. So you can't compare Kanban with extreme programming. You can't compare it with Scrum, you can't compare with feature driven development, or Rational Unified Process. What we're doing with Kanban is change management.
You do Kanban to something that's already there. So you come along, you find a team that's building software already and whether they are using some defined or recognizable process or just a way of getting the work done -- some undefinable method. You start with that and you figure out how to visualize the work because it turns out knowledge work's invisible. You can't walk around the cubicle farm and find a big pile of stuff somewhere. An industrial engineer looking for a bottleneck walks around the factory and looks for a big pile of inventory.
And then starts the trace where it's coming from and what's happening to it and identifies it as the bottleneck. You can't do that in a software development team. Let's backup, the theory is that the bottleneck will be the part of the workflow where everybody's fully loaded. At the other parts of the workflow there will be idle time because by definition they are not the bottleneck. So imagine you walk into a floor of a building full of software developers and they are all sitting in their cubicles and you walk around and say: "So, are you fully loaded? Are you busy? How much work do you have?"
The idea would be that perhaps you'll find two or three who are just swamped with work and everyone else has idle time. And you'd say: "Aha! here is the bottle-neck! No, that doesn't work. Because when you go around and ask everyone if they're busy they're all busy. Everybody is completely loaded, they're swamped; they've got 800 unread emails in their inbox. So you need a way of visualizing the work. And then once you can do that then you can limit that working progress. It turns out that while I've called the book Kanban and it gets referred to as the Kanban method, it doesn't matter which flavor of what limited pull system you use.
Could be CONWIP, it could be Kanban, it could be Drum-Buffer-Rope, it could be some other variant it will have the same effect. As soon as you visualize the work and you limit the work in progress, you'll start to stimulate changes. You'll start to see the scene that's in the picture on the cover of the book. And those changes will be the changes that the team owns. It's their process and they're making the modifications and it's not coming out of some book. It's not some coach or a manager or someone from outside that's imposing it on them.
The result is that there's no resistance because it's their changes and they understand why they want to do it. So that works better from my change perspective. The problem is it takes time. So if you're in a hurry and you're a manager that needs to achieve results very quickly you might want to be brutal and introduce some revolutionary change. On the other hand if you believe in sustainability and you want to change the culture in your organization and you want to achieve this lean outcome of what's called a Kaizen Culture --culture where the workforce is fully empowered to own their process and be responsible for the performance of the team, then you want to empower this workforce to make their own changes.
When they start doing that and they do it regularly, that's described as a Kaizen culture, a continuously improving organization. And I genuinely believe that that'sworth investing in. If you're a full-time employee -- a manager of a big company where anyone project doesn't represent the end - you don't hire all the people, build a piece of software and then fire them all. That's really not how it works. The company continues to run for years and years therefore it's worth investing in this culture and all that change. So that was a very long answer for a very simple idea.
OK. So I think that's a good question and we're seeing that perhaps more. You know as the book's out now, maybe people will start reading it and that will help clarify some things. When I first started talking about this, the first presentations were in 2005.Kanban as it's described in the book --, I first really described that publicly in 2007, in May 2007. And the way the mind works is it already knows stuff.
So people in our community already understood the concept of extreme programming, in Scrum and other Agile methods and they see something new being presented in the community and they are trying to map whatthey're seeing against what they already know. It's just the nature of how our minds work. So it was natural that people were trying to map it and it looked at practices. They'd see me give a presentation and actually tremendous depth in some of those presentations.
The presentation in May 2007 had most of the material that I presented here yesterday at the Lean software and systems conference. But I repackaged that material to make a specific point. But actually that point was in the original presentation. But people weren't seeing that. It was too much information; it was just densely packed casestudy. And what people were seeing were things like: "Wow, so David's team is not using iterations. And they are not doing sprint planning. And the standup meetings are bigger but they are shorter somehow."
You know, there was a those are numbers of aspects like that that people were recognizing. And I think it was just a natural conclusion they thought: Ah, here is a new Agile method that's got less waste, less overhead and it decouples a few things that for some applications, some context, may be more appropriate. And we did see some I think inappropriate adoption of Kanban -- teams that were not very good at doing analysis or not good at rating users stories, for example, would "we can't rate user stories to fit them into atwo-week iteration. So we'll just do Kanban because then we can have any length of iteration we like".
Well there's a positive and the negative or a glass half full and the glass half empty the way of looking at that. You could see that it's a way of putting some process rigor around that team without forcing them to improve a capability and change their behavior in the way they write requirements. The other way of looking at it is well that's an anti-pattern, they should have been figuring out how to write the requirements better, and they should have been forced into doing that. So I think there was a number of teams adopting Kanban for the wrong reasons. It's like "you know we're lousy at planning let's stop doing it. Oh so we're not doing planning anymore but that's all right because it's Kanban.
There was a lack of information at that time and I feel that those problems are going to go away as more information becomes available. Now we have three books on the topic, my new book and there are a couple of smaller books that came out earlier. There's Mattias Skarin and Henrik Kniberg' sbook that compares Scrum and Kanban. And then there's Corey Ladis' book called Scrumban, which is about applying initially CONWIP systems on top of Scrum and then observing how that evolves over a period of time.
I think actually what I said was that I believe the keystone was the operations review. And it's interesting that it's chapter 14 in the Kanban book and operations review is also chapter 14 in my Agile management book. It's interesting how it takes you 13 chapters of information to get to the point when you can say "let's do a review." So, operations review is an organization-level, objective data driven retrospective. And typically you would do it on a regular cadence.
I like monthly, because monthly gives you enough time to gather enough information to be useful, but it's not too long so people still remember things. If you're doing an operations review on the second Friday of the following month, the maximum time they need to remember is 6 weeks. I see some people do operations reviews quarterly. That's no good. It's too big of a time frame, nobody remembers detail. On the other hand shorter times you probably don't have enough information.
I personally like monthly. So there're really two levels of stimulating the Kaizen events, but the operations review is the thing that really sets the expectation for the organization. The leadership has said "we're going to come together and have a big meeting where individual teams will report metrics on how they're doing --defect rates, velocity and lead times and so on. And we are going to analyze that data and look whether the performance is stable or decreasing or improving and whether we implemented an improvement and whether the data is showing that it had a positive effect." And I know from my last real management job after I left that company they stopped doing operations review.
It took them a while, first of all they went from monthly to quarterly and then they said "you know, these quarterly reviews aren't all that useful. So let's stop doing them." And once they stopped doing the operations review the Kaizen culture evaporated from the organization. The other level of Kaizen events stimulation is like the one in the picture of the front of the book at the standup meeting. And what we've seen with a lot of Kanban teams is they stop doing iteration level or release level retrospectives. They drop a practice which is very common in Agile software development. So some people have looked at Kanban and said "Wow, this is a bit scary. All these Agile practices are going away. The sprint planning, the standup meetings are different and there are no iterations, and there's no retrospective. And that has been discomforting for some people in our community. But I believe that they're getting over it.
An interesting observation I've been talking with people like Henrik Kniberg trying to figure out where there are some fundamental principle differences between Scrum and Kanban. And with Kanban we're using the visualization and the working progress limit and the quantitative measurement to stimulate the Kaizen and that tends to happen in the standup meetings or immediately after. People talk about the after meetings -- little huddles of people talking about process improvement or at the operations review.
With Scrum it seems that the key to driving improvement is the commitment concept. You make a sprint commitment and then you make a daily commitment to your immediate colleagues when you are at the standup meeting. And the following day is what you get done yesterday implication that you meet your commitment and if not, why not? And what did we get done this sprint and did we meet our commitment and if not why not? So, the commitment is used to drive the improvement and with Kanban it's the WiP limit and difficult conversations that that provokes when there's a bottleneck or some set of impediments that are preventing flow because you are not allowed to start other things if you've already filled up the system to the limit that's been agreed.
5. David you are the vice-president to the Lean Software and Systems Consortium.
That's correct. Yeah.
6. Could you tell us about what that organization is and the purpose of it?
So, it's a relatively newly formed not-for-profit. Where a number of people mainly from the Agile community but not exclusively, have come together and said "we'd like to improve the level of professionalism in our industry and we'd like to improve the economic outcomes that we deliver for customers. We'd like the industry to show that it can perform better and it can deliver on customer expectations." We see that in a number of ways that there is a lack of good governance in software development and IT and there is a lack of predictable results and there's often a lack of business agility.
The Agile community gets terribly focused on "big A" Agile for the sake of it, and hasn't really been paying attention to "is this really making a difference to the performance of businesses." With smaller businesses it's perhaps easier to link, to join the dots. But with bigger companies, companies I meet in my consulting practice, the senior leadership say: "You know, we've been doing this Agile thing for 2,3,4,5 years but it's not making a blind bit of difference to the bottom line of the company." So, the Lean Software and Systems Consortium cares about these things, we care about the economic outcomes, we care about risk management, we care about the professionalism of our industry and we want to do something about that. And we believe that the ideas in Lean, will contribute to these -- to the risk management, to the economic outcomes, the professionalism. And we are using that as a vehicle -- the Lean concepts.
And we are going to create an opportunity for community to come together. And the first way we do that is with the conference; the conference we're at here, the Lean Software and System Conference. And right now we are committed to doing two of each this year, one in the U.S. and one in Europe. The European one will be last?2010 in Helsinki, in October. And the next year, about this time of year, probably early May will be in Los Angeles in the U.S. And anyone interested in that conference should pay attention to our website leanssc.org. We should make the formal announcement in early June once we have the venue under contract.
7. David I want to thank you for sitting down with us and talking to us!
Thank you for having me and thanks for the opportunity to talk to you and be on InfoQ!