David J. Anderson, pioneer in the application of Kanban for software development, recently came to Brazil. A group of InfoQ Brasil editors interviewed David about Lean, Agile and Kanban. See below the main highlights of the interview.
InfoQ Brasil: How would you relate the Lean and Agile philosophies?
David: There's obviously a lot of similarity. One of the differences lies in the fact that Lean has a philosophy of pursuing perfection and yet Agile has this underlying idea that you make progress with imperfect information and you course-correct later as you learn more. A lot of Lean thinkers would struggle with that; they would struggle with the idea that you should move forward with incomplete information. They would think of the rework as waste. Agile isn’t about the pursuit of perfection. So that's one key difference.
Another difference that I believe exists between Lean and Agile is how people are considered in the two philosophies. In Lean there is a system thinking view. The idea is that people's performance is largely influenced by the system they are part of, and the way you respect people is to design a system that allows them to work effectively. Agile has more of a humanist approach to people and respects them as individuals. The philosophy is an anarchist/libertarian view that people should be left alone to do the right thing and that best results come from self-organization. With respect to people Lean and Agile are very different.
And within the Agile community, particularly in the U.S., there is a lot of political influence; some people are very humanist, or they are very libertarian, or quite anarchist in their philosophy. The idea that everyone should be allowed to do whatever they want because people are inherently good (and therefore we can just trust them) is strong in the Agile community. Personally, I think it is wishful thinking.
Historically, there has been some pure communist influence on the Agile community. This manifests itself with ideas like, all managers are bad; any attempt to control people is bad; any attempt to assert authority over people is bad. I'm not convinced that this is true, and I think that Lean thinking people have a different view. They believe in building systems and that there is a class of people who do that and who operate the system. Kaizen Culture is not self-organization. So there's a very different approach to people and organization between Agile and Lean.
For me it is perfectly OK if somebody wants to come to work, do their job, collect their paycheck, and go home and get on with the rest of their life - to worry about their family. It’s okay if their passions lie outside work. I believe a lot of Agile people think everyone on a team should be deeply passionate about their profession. I don't think that's practical or realistic or pragmatic for large scale implementations and for bigger companies. This idea of depending on profound passion for the profession may work for a six-person startup company, but not for a 300-person business unit at a big company.
InfoQ Brasil: What about empowering the team, doesn't it go against this idea?
David: Empowerment isn't about letting people do whatever they want, or assuming they'll somehow self organize to produce the right outcome. Empowerment is about defining boundaries, and we do the same with children when bringing them up; we tell them things like when their bedtime is, where they're allowed to play, whether they're allowed to go outside the yard of the house, they're allowed to swim at the shallow end of the pool, they aren't allowed to jump from the diving board... all these things. So empowerment is about giving people clear boundaries, and then letting them use their initiatives inside the boundaries.
InfoQ Brasil: You recently added an additional core practice to Kanban: Implement Organizational Feedback. Why did you feel the need to do that?
David: I didn't really add the practice, I've just made it explicit. In my book, Kanban: Successful Evolutionary Change for Your Technology Business, there was always an entire chapter on that topic; I just didn't enumerate that as one of the core practices. I realize that was a mistake because we were not seeing enough adoption of organizational-level feedback loops. Sometimes, if something is not happening you need to make it more obvious, and adding it to the list of the core practices had this objective. So it's not new, I've just highlighted it.
InfoQ Brasil: You say Kanban is a form of leveling demand with capacity. Could you tell us the advantages, and how should we try to convince business people this is important?
David: We want to balance the demand against the capacity and against our capability, and it's clearly important that we avoid overburdening our capability . If we overburden ourselves we actually produce less, with poor quality, and it usually takes longer. By creating a balance we can actually improve the capability and see things happening faster. We will get more done. Quality will be better.
In regards to the business people, they need to be able to understand what it means to limit demand against capability. It means that we have to ration demand against our capability to supply, because there will always be more demand than we are capable of supplying. There is no limit to human ingenuity. What's really important is to be able to accurately assess the risks, reward and benefits of all this ideas for new software that people will have.
So, there is great value in helping the business to analyze the risks and understand the benefits of their ideas, and help them focus down on providing the best ones with some balanced portfolio of demand against our capability. So, while we may try to improve our capability to supply, they also need to learn how to choose the best options from the available set of ideas.
If we can do both of those things (increase our capability and limit/improve the risk management of demand), then we can live with a lot more harmony. One of the reasons we see more and more demand is that there's uncertainty in the future and business people can hedge their bets by saying "Just build everything". Clearly that is not practical so we need to help them to better assess risks and to understand the uncertainty that they are facing. That way they can have a greater confidence in the choices they are making.
InfoQ Brasil: Are there any myths and misconceptions about Kanban? If so, which ones would you say are the most frequent or important?
David: Alan Shallaway has published an article on myths of Kanban, it may be a good reference. I think there are a number of myths, one of them is about the board. In fact the Agile Alliance has a web page about the kanban board as an Agile practice. The Kanban method is not called “Kanban” because there is a board; it’s called Kanban because it implements a virtual kanban system, a pull system for limiting the work in progress and deferring commitment until what Lean people would call the "Last Responsible Moment"; the board is just a way of visualizing what is going on there.
The board was added later; the kanban system came first. Boards were just known as “card walls” back then, and they were common enough within the Agile community. The board wasn’t novel, it didn’t represent an innovation. The use of virtual kanban systems was the innovation.
There are a number of other recurring myths. One of them is that Kanban is only for maintenance and IT operations and you shouldn't use it on big projects, that's clearly just disinformation; in 2007, for instance, we did an 11-million-dollar project with more than 50 people using Kanban.
So we've being doing it on big projects since the very early days, and you would choose to do Kanban because it helps to improve your predictability and your risk management. These are clearly important things when it comes to project management and governance – having some certainty over delivery schedules.
Unfortunately, the myth that Kanban is only for maintenance and IT operations and that you shouldn't use it on big projects is common and recurring, amongst those in the Agile community.
InfoQ Brasil: What about the myth that Kanban would bring us back to waterfall? Is this one still around?
David: The waterfall myth was very common from 2007 to 2009, but we don't hear that so much anymore. That was primarily because a lot of early examples were done with teams using traditional SDLCs or methods that are not recognized as Agile – like the Personal Software Process and Team Software Process. So the early Kanban examples were all non-Agile examples.
This was natural because I introduced Kanban as a way to improve teams that were rejecting Agile methods, so it's natural that, if that was the case, all the early examples are non-Agile examples. However, nowadays it's very common; maybe more than 50% of cases for people to be adding Kanban on top of Scrum, so I think that myth has largely gone away.
InfoQ Brasil: You have recently mentioned considering to add the practice of “giving permission for ideas and encouraging process innovation”. Would you tell us why you didn't do it? Do you see the need for a “Kanban Master”?
David: Actually, I added the idea that you have to encourage leadership and get people to recognize that leadership and management are different things, in the principles of the Kanban method. Managers are responsible for the system they're operating, the design of that system, all the policies, and the decisions that get made to change a policy or override it. So that's all very well; but truly, we want anyone who's involved in doing the work, whether they are individual contributors, or managers, to show acts of leadership.
An act of leadership is to say that whatever's happening now is not good enough and suggest or show that we can do better. If you don't have that, then you don't have the catalyst for continuous improvement. Everyone could shrug their shoulders and say "Oh well, that's the way it is. Back to work!" Nothing would ever get any better. So leadership is the magic ingredient. It's the catalyst.
Recently there's another similar example: Håkan Forss who's a Kanban consultant from Sweden, has been reading Mike Rother's book on Toyota Kata and this led him to suggest that Kanban has 3 kata - 3 Kanban kata.
One is the daily standup meeting that provokes local kaizen events. Another one is the operations review that provokes those inter workflow, inter Kanban system, improvements. And the third one is the relationship between the superior and the subordinate, the first line management and the second tier manager where the more senior one is coaching the less senior one on "how well is our system operating?", "Do we have the right policies?", "Are we gathering the right metrics?", "Are we visualizing the right things?" So that we can understand the world we are living in and make changes to improve it.
InfoQ: Is the community getting used to the term Kanban Master?
David: No! We are really discouraging the idea of a Kanban master (as a direct comparison to the Scrum Master role). I do think there is value in using a coach. It is a different role typically from how we see Agile coaching. When I look at Agile coaches, they are often embedded with teams, and they are there every day of the week.
We see that Kanban coaches are typically only there two or three days a month and are usually talking to people about policies and visualization and metrics, and they are helping them understand capability and think about improvements. In order to do that, they don't need to be there every day of the month.
InfoQ Brasil: InfoQ has recently published an article about Kanban being the next step after Scrum. What do you think about this?
David: If they are talking about market development, that we see Kanban becoming the next significant thing in the software process market, I think that's correct. There's a lot of evidence that we have real momentum for Kanban training, coaching, consulting, Kanban software, simulation, games – all sort of things, so I think from a market perspective Kanban is developing as the next thing. If you think that there was CMMI, there was RUP, there was XP and there was Scrum, Kanban is the next thing in that succession.
But if they meant that people should do Scrum before they do Kanban I think that's completely wrong. Scrum is difficult to adopt for a lot of organizations. it's culturally the wrong fit for many companies and people resist adoption of it.
Kanban, on the other hand, is designed for easy adoption. It's designed as a way to start with what you do now. It's an alternative to Scrum. If we waited for people to overcome their resistance [to Scrum], they would have lost a great opportunity to have made improvements much quicker if they had adopted Kanban earlier. If people are already doing Scrum and they feel the need to improve even further, then maybe adding Kanban later is a good idea. But if they are not currently doing Scrum, they should think about Kanban as an approach that they can start immediately.
InfoQ: In Jurgen Appelo's book, Management 3.0, he talks about “memeplex”. Appelo argues that it is a reason Scrum was so successful in its adoption, that Scrum replaces the whole current memeplex with a new one. What’s your take on this?
David: I'm not gonna argue with that suggestion; the challenge is, can you do that complete removal and replacement of the memeplex? So while we can say it's been successful, there has also been a tremendous amount of resistance. There are a lot of either challenged or failed Scrum adoptions. One relatively recent piece of trustworthy market research I saw said Scrum had about 15% of market adoption. That's better than RUP has ever achieved; the best RUP got was about 11%. So 15% is good, and you have to say: OK, out of that 15% how many of those are challenged implementations?
But let's be generous and say all 15% are working wonderfully. That leaves the other 85% of the market. I think that's the problem I want to solve. What's better, help people do Scrum better and focus on 15% of the market or try and help the other 85% of the market? I wouldn't doubt that many of these things Jurgen has said about Scrum are correct and accurate. However, there are many other more interesting problems to be solved in the universe and in the world of management and software process and I'm more interested in the rest of the space. I'm sure there are plenty of people in the Scrum community that are interested in improving Scrum.
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.