During our conversations with David J. Anderson, Kanban pioneer, at the Lean Kanban Conference in Chicago, we asked if there was any Kanban quick-start guide that might demystify things. David recommended we speak to Dr. Arne Roock of IT-Agile, author of the 30-page Kanban booklet "Stop Starting, Start Finishing". Dr. Roock is a speaker and chair of the "Scaling Kanban" track at the conference, and also works as an Agile consultant and trainer in Germany.
InfoQ: Based on the current literature Kanban seems to be somewhat philosophical. How can a team start to evaluate whether it is the right tool, and what is required to kick it off?
Dr. Roock: The most important thing is to agree whether we want to change at all. If we don't want to change, then Kanban is not for us, because Kanban first and foremost is a change method. Often people mix it up with project management methods or development methods, but it's not; it's a change method. There is just one prerequisite for change, there needs to be what leadership authority John Kotter calls in his book by the same title "a sense of urgency".
The second thing is if we agree we want to change, there are two main strategies. The first one is revolutionary. That means turning the organization upside down and inside out and making a huge change, which causes a lot of pain, but we are hoping that after this change we are a lot better off than before. That is not the Kanban approach. Kanban is a method for evolutionary change.
InfoQ: Let's say we agree we are ready for change. We want to do the right thing, if it takes a revolutionary change we are prepared to do that, but if we can realize significant improvements with an evolutionary change we prefer that. We want to see results in terms of improved delivery, and improved predictability and transparency.
Dr. Roock: In my experience, before we start introducing Kanban, we need to agree on the major goals. That means we need to have management support.
You might try to introduce a grass-roots “stealth” approach, hiding it from management, doing it in just one team. There can be some limited success with this approach but you will hit your limit very soon. If you want it to be really successful company wide, you will need management support. It's important to talk to the management and understand what they are trying to achieve, what are their pain points, and what are the goals they want to achieve.
In your example it would be "we want predictability and improved delivery." So the first thing I would do is create visibility for the end-to-end flow. A huge problem in knowledge work is that we cannot see or touch our work. If you go to a factory you would see a lot of raw materials and unfinished goods on the shop floor. But if you look in any random office, they all look the same; you have the desk, you have the keyboard, telephone, computer, and a lot of paper, and that's it. We cannot see our work, and that means it is very hard to improve things.
So the first thing we do when we start with Kanban is a visualization of our work. How many tasks have we started and what stage are they? How much work do we have in development, how much do we have in analysis, and testing and so on.
This should be very insightful. In many cases, people are not aware that they had so much work in progress, (which means work that has been started but not finished.)
The next thing is to create a feedback loop. Observe our flow and our work on a regular basis, and agree on things we want to do to improve our flow.
Now we have this transparency, and we see in the testing column, things are piling up. So we are faster in developing things than in testing and deploying them. So let's come together, have an improvement workshop to see what we can do to smooth out our flow.
What can we do to work on this bottleneck? The thing that comes to mind first might be to hire additional testers. But very often, that is not the right solution. Perhaps improving the quality of the work that goes into the testing stage, or automating things, or moving developers into testing because very often developers can do this.
So transparency is the first one. Feedback loops are very important. Most Kanban teams do daily standup meetings in front of their Kanban board, where they can see their work. And they are doing improvement workshops, or as they are often called "Retrospectives" or "Kaizen meetings".
Next would be to have some kind of metrics to decide if we are moving in the right direction.
If the goal is to improve predictability and deliver fast and often, it might be a good idea to measure cycle time, meaning the time from when you started a task until it was finished. And then let's see what happens if we move one guy from development to testing. Or what happens if we slice our work differently. Or if we agree on a policy that we don't want to have more than two items in development and three items in testing.
There are a couple of other things we might want to try. So now that we have the feedback loops and the metrics, we can see if this is a good thing and should be amplified, or is it not working correctly, and we would want to dampen in.
InfoQ. You spoke about the board, which seems to be the central focus. I would like to understand how granular that should be. Do I go from the beginning to the end, or do I only include my development steps?
Dr. Roock: Start with this section of the value stream you can control. If your sponsor is the head of development then the starting point should be the development. Our board would start with some kind of analysis task breakdown, then development, testing, and then some interfaces with upstream processes such as product management, and downstream processes such as deployment.
Of course in the long run we want to extend the boundaries. We don't want local optimizations we want collaboration across department boundaries. But if we cannot control this it does not make sense to have all of this on your board if your up and downstream partners don't agree to collaborate with you. This is very important.
Start with the parts you can control. Don't try to evangelize, that's not going to work. What will work is if you achieve better results and make them transparent, people will become curious, and curiosity is a very powerful tool. People will keep coming over and asking you questions, “how are you delivering so often?” or “why do you have fewer bugs?” Then what we observe very often is that Kanban spreads across all teams.
We heard a presentation from Jimdo, a German company that has Kanban for their online marketing team, Kanban for their press team, for their video team, and for the partners teams, and of course the Kanban boards look differently for every team, but they are applying the same principals. That means continuous improvement in small steps.
InfoQ: How do you scale the board across distributed regions?
Dr. Roock: That's a tricky question but it's very relevant because a lot of teams today are distributed. There are a lot of good Kanban tools in the market, but there are upsides and downsides to electronic tools. I would try to keep it physically present as long as possible. Even if you have two locations it can work with physical Kanban boards. Then you have to synchronize the teams of course. You can use web cams, instance messaging, a buddy system, where each region has a buddy in the other region.
InfoQ: What do you mean by a buddy?
Dr. Roock: The buddy system is where every team has a buddy that permanently resides in the other location. Every time you change the Kanban board, say moving a ticket from development to testing, you would notify the buddy to update the board there. Now you can use phone or video conferencing or instant messaging, and it sounds like a lot of overhead and it is. But you need to have this communication. But you will observe that now the buddies will start communicating, not just about moving tickets but about things like “I am out next week on vacation, so please remind the other team members to do this and that.” Or “I see you are working on this part of the code. I know this and there are tricky parts, so let me give you some hints.” So now people are communicating across the team boundaries and that is really valuable.
InfoQ: What if there are more than two teams, and large time differences like New York and Singapore, which can be 12 hours apart?
Dr. Roock: Two regions can work but not three; I have never seen that work. The other problem is the time difference, which makes it very difficult to do this.
What I like to point out is that Kanban can be like a mean mother-in-law; she tells you what you are doing wrong all the time, but she does not improve you. In this case if you apply Kanban you will see that you have a lot of pain with your distributed teams, it takes a lot of effort to synchronize those teams. But that's the reality, regardless of whether you have Kanban or not. So Kanban will make these problems transparent. For more than two locations, you will surely need an electronic tool. But what you also need is a lot of bandwidth for your communication. I have seen this over and over again. When people are only communicating via the tool, you’re nailed! People need to keep communicating. Face to face is of course better than video conferencing, which is better than telephone, which is better than email. So make sure people communicate as often as possible. That means you have to ship people from time to time to the other location, even if it is Singapore. And you need to have really good equipment for video conferencing, and you need to have a good Kanban tool. What is very important for changing the organization, (and that is what Kanban is designed to do), is building trust. It is easier to build trust when people know each other. When people see each other, talk to each other face to face, have a beer together, know a little about their private lives, if they have children, or the kind of movies they like, that builds trust, and that is really, really important.
Standup meetings are one way to create this forum so that people can come together and talk to each other on a regular basis. Of course if there is a time difference that is a problem, but you have to solve that in any case, nothing to do with Kanban.
InfoQ: Is there a standard solution for conducting standup meetings cross-region?
Dr. Roock. Even if there is a time difference, you often have one or two hours of overlap.
InfoQ: Well, Singapore is 12 hours, so even if they work late it would be hard to do it on a daily basis.
Dr. Roock: Yes, even if you could you’re at different points in your days, so the energy level is different. It is a tough question. There needs to be regular communication, even if some people have to work in the night. You can have one person talk to the other team using a round robin mechanism.
Also we have to tear down the boundaries. Very often we see where you have one team in the US and one team in Singapore, the team in the US says "oh these guys from Singapore, they broke our build", or vice versa. Often this starts as a joke, but there is a reason behind it. Sending delegates to the other location for a few months, then having their delegates come here, can be a very effective relationship device.
InfoQ: So now, let's say we have buy-in from management, isn't it better to start small to mitigate the risk?
Dr. Roock: Yes that is the basic idea about Kanban. You start with what you have, then evolve. If you are visualizing your work, visualize what you have now; don’t try to visualize your target state.
We had a presentation from Daniel Vacanti who was responsible for implementing Kanban at Siemens Health Care. They did it differently; they had a huge Kanban rollout throughout the whole enterprise.
But usually we start small, and it spreads virally, or by team after team.
There is a very important principal in Kanban that says respect current roles, processes and responsibilities. That is very important and it is related to the evolutionary approach I was talking about.
So if you have an organization where the departments are not collaborating, or you have certain management structures or roles, you must retain all of that. Respect the current status quo. If you have test managers, architects, business managers, you need to keep that. Experience shows that people do not like it when we change their responsibilities, their titles and their roles. They have a lot of self-esteem from their professional roles. If I worked as a business analyst for the last twenty years, and now we're doing a new process where there's no room for a business analyst, I have to print new business cards with a new title on it, and I will be offended. That's the reason we don't do this in Kanban at the beginning. But when we move on with our journey, we start to develop trust, and we can start to introduce those kinds of changes.
InfoQ: Regarding the Kanban board columns, how granular should they be?
Dr. Roock: The columns on the board should reflect the way you work at the moment. It's usually easy to detect this by listening to people talk. They will say "Are done with development; have you started testing?" That indicates there should be one column for development and one for testing, reflecting the way people are working anyway. We want to have a realistic picture of our workflow.
On the other hand, if we have too much granularity, too many columns, too many swim lanes, the board is not transparent anymore. There is a rule called "three-by-three; if you're standing 3 meters from the Kanban board, then in 3 seconds you want to know what is going on. You can't read every card but you can see where things are piling up, and where people have nothing to do. But if you have too many columns or too many swim lanes then you start to get lost. (Editor's note: "columns" refer to the vertical columns on the Kanban board. "Swim lanes" refer to the horizontal rows.)
InfoQ. Regarding "Work in Process" (WIP); in a Scrum process, we have a certain number of stories, we work on those, if we don't finish, we bring them into the next sprint, but we keep an eye on how much time is left, so that we can apply our velocity and determine how many stories to pull in. So in practice, WIP is already a Scrum concept!
Dr. Roock. Yes, it is. Scrum limits WIP by the concept of having sprints. It is different from what we are doing in Kanban, even though the principal is the same. In Kanban we have WIP limits per column or per swim lane or per person. The trick is to balance demand against capability. We don't want to accept more work than we are capable of finishing.
InfoQ: So let's say we have ten developers working on a project. My capacity is one, so are the others. Therefore our WIP limit is ten. Someone gets stuck on something, they can take on one more. If there is a production issue, I am forced to take on one more.
Dr. Roock: You are asking two different things. Let me explain. A production issue is called an "expedite" in the Kanban world. If we don't handle those immediately we have a high cost. In such a case, the expedite would need to break the WIP limit, and certain policies would apply to them. For example we swarm on the problems and handle them immediately as a team. Then afterward we must reflect as a team on why we have so many expedites. What can we do to reduce those? That would be the Kanban approach.
The other thing you referred to is an item that is blocked but is not an expedite. I am waiting for another team because I need information or something from them. I can start another item and break the WIP limit, or I can use this “slack capacity” I acquired to improve our system. That is the idea behind Kanban. The WIP limit is one very powerful way of creating slack. Slack capacity lets you take a deep breath, have a look, see what's going on, evaluate what I can do to remove the slack, and to remove the root cause.
For example, if we encounter the same blocker over and over, maybe we should have one person there, or have their person work here for a while so we can transfer knowledge. Kanban doesn't dictate how to deal with these blockers; it just says "use the WIP limits to create slack, and don't utilize your people to 100%.” That's what we do in classic project management. We are always trying to fully utilize people and are thereby wasting slack capacity that could be used for process improvement.
InfoQ: If I am a project manager in my organization, I have some minor exposure to Kanban and I decide I want to give it a try. My organization won't invest thousands of dollars to train me. What is the minimum I need to get started?
Dr. Roock: I have seen companies that are quite successful with Kanban, and they didn't have any external coaching or training, they just read a book, or a blog post, and subscribed to a mailing list. They were small companies, and I would say the chance of being successful would increase if you had at least one really experienced person. The best thing is if they are inside the company, but if you don't have that then that's the reason you have consultants.
Usually we start with a management workshop, and we evaluate such questions as why are we doing Kanban at all? Do we agree to pursue incremental change? What are the goals? After that we train the team so everyone speaks the same language. What are the columns and the swim lanes, how do we deal with expedite tickets, and so on. After this I would help the team on a regular basis to reflect on the system and improve it. Now that's not a full time job five days per week. It's more like a package of a couple of days at the beginning but then decreasing because we are trying to build internal coaching experience. So the amount of coaching is not huge but increases the chance of success.
InfoQ: How much time should the coach spend in the organization?
Dr. Roock: That is difficult to answer generally, it depends how many teams the coach is working with. If the coach is working with three or four teams at the same time, then that would be a full time job. But if you have only one team, the best strategy would be to have small amounts of coaching more often. So for example one day per week would be better than a five-day stint every six months.
InfoQ: Do you have any other final advice?
Dr. Roock: One thing I think is important. What we try to achieve with Kanban is to understand the way we are working, and to understand our work. That is one basic value behind Kanban. If a consultant comes to my company and says you must do this and this, he is probably wrong. A good change manager facilitates the process of having everyone in the company, and especially the leaders, understand the way they work, because otherwise it is really hard to improve. So don't just apply Kanban by the textbook, try to understand why you want to have WIP limits, why you want to have transparency, and all this stuff. If you do that there is a good chance of success.
About the Interviewee
Dr. Arne Roock works as a trainer and coach for Lean and Kanban for it-agile in Germany. His focus is on helping companies establishing a Kaizen culure using Kanban. He wrote several papers on Lean/Kanban and translated the book “Kanban – Successful Evolutionary Change for Your Technology Business” into German. Arne is founder of the first Limited WIP Society in Germany as well as board member and organizer of the conference “Lean Kanban Central Europe”. He has been rewarded with the Brickell Key Award 2012 by the Lean Systems Society. You can contact Dr. Roock via Twitter, his blog or his e-mail adress.