If they were to carve a new Mt. Rushmore into the mountains surrounding Silicon Valley, then alongside Dijkstra, Kernighan, The Three Amigos and The Gang of Four they would need to make room for David J. Anderson, father of Kanban in the software development industry. The Lean Kanban North America Conference took place in downtown Chicago last week, and InfoQ interviewed Anderson whose firm David J. Anderson and Associates chairs the event.
InfoQ: I recently ran into a colleague who in the past led a Scrum software development project. He surprised me by saying that he was now using Kanban. I asked him what process changes he implemented, and he said he actually didn't see much difference between Scrum and Kanban at all! It was clear he didn't get it. That episode was reminiscent of the early days of Agile, when everyone claimed they were Agile, until you drilled in. I think that is symptomatic. There seems to be a dearth of material relating to Kanban. Your book is the bible, and that's some 300 pages. If I needed to describe Scrum in a few sentences, I could tell you it has time bound iterations, planning "sprint" meetings at the beginning, a retrospective at the end, measured velocity, and daily scrums to review status and obstacles. I was wondering if you could, in a similar way, teach us Kanban while standing on one leg so to speak?
David: We are aware that there's a gap there. We had in the past tried to produce an eight-page quick start guide, and that worked in its day but it needs to be revisited.
There are some thin publications but those are getting old, say 2008, and our understanding wasn't as good back then, nor was our ability to articulate that. So there is definitely a need to produce something that people could read in an hour.
Lean Kanban University intends to publish what will be called "The Official Guide to Kanban".
InfoQ: When do you think that "Official Guide" will be ready?
David: Well it should have happened already. The target will be this year. I've also started to work on a second edition of the Kanban book, which we hope to have ready by early fall. We've learned a lot in the few years since it was published. We've learned a lot from teaching it, we've learned a lot from consulting and from listening to other consultants in the market. Once that is done, we will extract the "Official Guide" from the second edition.
InfoQ: If I want to set up a Kanban project today, can you tell me how to do so; how do I start, how do I analyze what I am doing, how do I sell it to management?
David: there is guidance on that available, for example my talk at last year's Lean conference in Boston.
We start by teaching people to ask "What are the customer and external stakeholder dissatisfactions, what are the internal team dissatisfactions, in other words, what problems are you trying to solve, why are people unhappy?" In that way we gather an understanding of what might be causing it.
Then we ask them to identify who are sources of work. In an agile world we'll often hear things like "the source is the product owner". The source is not the product owner! The product owner is the middleman. So it is very important to get them to work their way back to discover where the source of the demand is coming from. That might be a sales or marketing department, a planning or regulatory authority, or perhaps a particular customer or market segment. So we help them understand where the demand is coming from.
We also ask them to discover the target destinations. So for example a mobile application company might have an iPhone version, an Android version, a legacy Symbian version. I imagine the Symbian version only receives minimal regulatory changes, or you would have a legacy set of banking customers with Symbian phones who wouldn't be able to use your application any more. The iPhone version, in contrast, gets all of the latest features. So we are helping them identify risks and understand what represents a satisfactory level of service. That is a demand analysis exercise. So again, we start with understanding the voice of the customer and the employee, and then we move to the demand analysis.
The next thing to do is a capability analysis, which is to look at existing tracking systems and extract historical data about lead times and delivery rates, so that we can understand what are you currently capable of. Now, there are situations where people have no historical data whatsoever, but it is becoming increasingly rare. They usually have a tracking system such as JIRA. that can help us to understand the existing capability, then we can start to match the customer demand (from the demand analysis) against the existing capability to see where the gaps are. And it is from all of this input that we start to design the Kanban system.
InfoQ: Is it realistic for the lay project manager to implement this?
David: It’s possible but in general we recommend that people get training to do it properly. People that just go put a board on the wall and stick some sticky notes on it might be visualizing the work and the workflow, but they are not designing a Kanban system with the intent of improving customer service. Kanban is a service-oriented approach and it's a mechanism for improving service delivery. And therefore you need to understand what service you are providing and what's the demand for that service, and what's your current capability to supply against that demand.
InfoQ: Isn't that a barrier to entry? People want to understand something before they will commit to a large investment.
David: Let's make it clear there isn't a silver bullet. If people want to realize the results that have been seen in organizations like the BBC where individual departments improved productivity by 700% and 800%, and one particular department made web pages for their BBC Worldwide commercial website, improved revenue generation from ad impressions by US $1M per year through earlier delivery. So they improved their delivery rate by 700%, which reduced delivery time creating earlier deliveries, which generated an additional $1M per year in ad impressions. These are the kinds of benefits people get when they do Kanban properly.
InfoQ: But from the perspective of a project manager, these sound like marketing legends. How can I assess whether I can expect similar results in my environment?
David: I don't see this as legend. People post case studies about Kanban that say we got 400% productivity improvement and I look at that and say, "Yeah that's about normal". You can go around this conference and find 100 people that can tell you a story like that.
InfoQ: That's compelling, but the problem with that is that we are not hearing about the projects that might not have succeeded and just silently scrapped it.
David: We've had companies that read the book, had no assistance at all, and produced those kinds of results. Now that might sound scary from a commercial perspective. People are not going to buy training if they can get those results just by reading the book. But here in North America, there is a tremendous amount of shallow Kanban, and people can benefit greatly from upgrading to a “deep” Kanban system.
There is a lot of momentum for Kanban in the market, you hear about it a lot, people tell you they have boards on the wall, they're monitoring the flow on the board, and so on, but it's shallow, it's stuff they picked up from the internet. The Agile community's understanding of Kanban, particularly in North America is abysmally poor. They haven't been paying attention to the depth of it, the system thinking approach, the service oriented approach. They don't even necessarily recognize that a work in progress limited pull system is essential. And they don't look carefully at the core dynamics of the Kanban system design.
InfoQ: But isn't that important for overcoming the barriers to entry, get your foot in the door, then grow? After all a large financial company for example, might have a whole hierarchy of management layers, so a development team might get the idea that they want to do Kanban. They have to sell it to their management, who has to sell it to the managing director, who says "you know you sold me last year on Scrum, and now you're trying to sell me on Kanban, what happened to the benefits we were supposed to realize from Scrum?"
David: There is an important and I think widely misunderstood point, and again it is an Agile community problem in North America.
A number of actually well known Agile people have described Kanban as a team level process. It was never just a team level process. The first Kanban system was a multi-department workflow process. The second and subsequent ones, all done in 2006 and 2007, were multi department workflow implementations. It has never been a team level process; it is an organization level workflow level process. The Kanban method is change that is designed to be led from the middle. And this makes it different in the market. There are lots of lean consultants, and not to pick on lean but lean is typical, and they will tell you it is always successful as long as the chief executive buys into it. So that is top down change. And then a lot of the Agile change, because it is team oriented or developer oriented, has tended to be grass roots change led from the bottom. The Kanban method is designed to be change led from the middle. And it is intended to be workflow, service-oriented, and span multiple departments and multiple stages in the lifecycle of some piece of work. It involves the collaboration of multiple teams. And in order to do all that you need to be a middle manager, because you have that political authority to join the different bits together. If you're a developer, that is way above your pay-grade.
Primarily Kanban is about getting rid of all the junk that makes my life miserable, all of the interruptions I get, and it is helping managers to focus on blocking issues so I can get them unblocked faster and get on with my work. But most of all it is just helping me focus on just a few things at a time and not the 20 things people were demanding of me.
Another big employee dissatisfaction that comes up again and again is we get constantly dragged in different directions because priorities are always changing. And Kanban really helps focus people on what we call in the community the "Spice Girls question". When you are doing the queue replenishment for a Kanban system, you might say which two things do you want next. Management consultant Stephen Bungay would say you have to "tell me what you want, what you really really want" and once you committed on that you shouldn't change your mind. Therefore once something is flowing across the Kanban board we don't ever want it to be discarded. And developers and analysts find this helpful. They are only working on stuff that people want and the quantity is under control, so they can focus, deliver, and start on the next thing. The bottom up implementations tend to see some improvement and then flatten out unless they can continue to widen the implementation up and down the value stream. And if there isn't someone with sufficient political influence, that often doesn't happen. We do talk about viral spread and we do occasionally see these spontaneous expansions of the Kanban system without someone leading it.
But honestly to get Kanban implemented properly it requires middle management engagement, like at the director level, or in a small company it requires senior management. But the ground up implementations are providing a psychological and sociological benefit for the staff. It's letting them do a good quality job and relieving a lot of stress, but that is not going to drive the economic engine. In my book I talk about the benefits of "slack". You can't sell Kanban as a product or service if you talk about the benefits of slack. That doesn't communicate to the senior executive about why he should be paying for it.
InfoQ: Is there a decision tree that we can use to decide if Kanban is going to produce the kinds of efficiencies you described?
David: Yes, we teach this in some of the advanced classes. It's actually easier to describe when you wouldn't use it.
You wouldn't use Kanban if senior management consists of impatient revolutionaries that are in a hurry to see dramatic results. But if you are in a bureaucratic organization in a culturally conservative country, that would be a better fit. Another poor fit would be a case of extreme chaos, or early stage research. The Kanban applies well in the development space but not in the research space. You need to be able to describe a value stream and identify what is the service our customer is asking for. If you can't describe those then you can't build a Kanban system for it.
Also from a technology company perspective, you need to have configuration management capabilities, version control, the ability to release some work while other work is in development. That requires a higher level of configuration management capability than what is required for typical Agile methods. If you start an iteration, work for a few weeks, then deploy, you are essentially closing out any branches or labels of code. But in a Kanban system you might have multiple branches in process. Not every organization has those technical capabilities.
InfoQ: I would like to understand the implementation a little better. Let’s say you are managing the development process. In your project you generally model first, and then create tests, then implement, pass tests, do code reviews, etc. Should you be looking at each of those as the columns on your Kanban board?
David: I would say probably. But you also want to include the upstream and downstream processes. Look at the current span of your political control; then once you have built more political capital, you can get the upstream and downstream later.
InfoQ: That's exactly the kind of approach I think we need. The team lead needs to make the decision, implement it, and then if it works sell it up. So if I can start in a small kind of way and make a difference, then that will spread.
David: In any process there is a need to build social capital, and you do that using methods from sociology for building trust, for example by providing greater transparency. People trust something when they understand how it works, when they can ask "that work I gave you two weeks ago, where is it now?" Trust is also developed incrementally, and, for neuropsychological reasons, small promises that are delivered frequently build trust faster than large commitments delivered infrequently. So delivering according to your targets build trust. That's how you generate momentum in a bottom up approach.
Sometimes after two days of advanced classes, someone will come to us and say, "We have been learning about change and psychology and sociology, when are you going to start teaching us Kanban?" And actually a lot of Kanban is just that. At some core level Kanban systems consist only of some work in progress limiting pull system with a signaling mechanism. There is a little more to it, in terms of understanding demand and how to choose the limits. How do you turn that into something that revolutionizes the performance of knowledge workers in organizations? It is a lot of psychology and sociology.
InfoQ: Well, thank you for the background, David! Kanban certainly seems to be taking the world by storm. I wish you the best of luck on your journey.
About the Interviewee
David J. Anderson has 30 years experience in the high technology industry, and has led software teams delivering superior productivity and quality using innovative agile methods at large companies such as Sprint, Motorola, and Microsoft. David is the author of three books, Agile Management for Software Engineering – Applying the Theory of Constraints for Business Results; Kanban – Successful Evolutionary Change for your Technology Business; and Lessons in Agile Management: On the Road to Kanban.