Can You Scale Kanban?

When organizations are scaling agile and want to apply kanban as one of their agile methods the question can pop up if kanban can also be scaled? Kanban has scaling build in so in the strict sense of the word you cannot not scale it said Klaus Leopold because scaling kanban is simply an improvement step of the current situation. Scaling kanban means doing more real kanban, more improvement, as he explained in his presentation kanban at scale at the Lean Kanban Central Europe 2014 Conference.

It is a misconception that in an agile organization all teams would use agile methods. There are many different methods, teams have to apply what works for them and adapt it to their situation. Organizations are living social systems said Klaus. Teams are not alone in organizations, they are connected to each other and the interactions is what creates value.

InfoQ interviewed Klaus about using kanban for managing a program, deploying and connecting kanban boards on team and program level, managing work in progress across the full delivery cycle and the benefits that kanban can bring.

InfoQ: You talked about continuously adapting the working environment to reality instead of trying to fit a blueprint. Can you give some examples of this?

Klaus: There is a scene in Alice in Wonderland where the rabbit says, “you have to run very fast here in order to stand still.” I think this explains today’s business reality very well. If you’re not continuously adapting your working environment to the always changing circumstances, the world will overtake you. Unfortunately, I’m not smart enough to provide a blueprint with a couple of practices which fits for each and every organization on this planet in order to be successful on the market. I’m profoundly convinced that every organization has to figure it out on their own. 

The most well described example is probably Toyota who provided access to their factories to competitors and showed them how they build their cars. See e.g. the book "Toyota Kata" by Mike Rother. Although a lot of companies were copying Toyota's practices, none of them was nearly as successful as Toyota. So it’s totally not about installing best practices and solutions of others. Practices are only the reflection of learning loops - of improvement steps. If you apply somebody else’s solution to your problem don’t be surprised when the solution does not solve your problem!

InfoQ: At the Lean Kanban Central Europe conference you talked about a software development program that used kanban. Why did they decide to use kanban?

Klaus: The organization I was talking about was pretty much lost in complexity. There were roughly 200 people in the program, trying to accomplish a common goal but they didn't have any idea, where they actually are and if they would make the target or not. They wanted to keep the change as minimal and painless as possible because people where simply sick and tired of the ongoing organizational change waves that break over their heads. The idea was to keep the teams working and don’t bother them too much with changes. So in a first step we only wanted to do a better coordination of the input to the teams to make sure that they do the right thing to the right time. 

You can compare a company with a keyboard where each key is pressed by a team. If you’ll have to write a letter for your client, you don't want to optimize for team efficiency so that each key on the keyboard is pressed faster. That doesn’t bring barely any more output. When it comes to writing a letter, it’s much more important that you hit the right key to the right time. And the same is true when the value creation in your company depends on more than one team.

When you start your improvement journey at this Flight Level (see kanban and its flight levels and why kanban flight levels), teams don’t have to change a lot in the way they work. In fact, it even doesn’t matter whether teams are doing Kanban or Scrum or whatsoever. You basically establish flow across teams and you make sure that everybody is doing the right thing to the right time.

InfoQ: Can you give elaborate how kanban was introduced in the program?

Klaus: That’s a big question. I’ll try to sketch the most important events: In the beginning we built a cross-functional and hierarchy-bridging change team who was basically leading the change. They were the primary contact persons for any questions regarding the change and they also led all activities around the introduction. One of the first activities of the change team was to identify stakeholders and to understand where exactly the problem is. Having this information we were ready for the system design workshop. The teams nominated delegates who designed the Kanban system.

In the beginning we only had one Kanban system for the coordination across all teams. Later, more and more teams decided  to start with Kanban on team level too. That was fantastic because teams pulled the change - nobody told them that they would have to do Kanban! Of course, we totally supported their decision.

InfoQ: Why is it important that teams build their own kanban boards instead of taking a standard board?

Klaus: I think it’s a whole lot about ownership. When I built MY system, I understand the purpose of it and how it works. So if something is not working as it is supposed to be, I have an intrinsic motivation to improve MY system. However, if a smart guy comes along with a board and tells me how I’m supposed to work most effectively, my goal is to show this smart guy that he’s wrong! Chances are much higher that people try to circumvent the system instead of using it for their favor if they didn’t design it on their own.

InfoQ: In your talk you mentioned doing a program stand-up for coordinating the work among teams. Can you explain how that was done?

Klaus: That was actually not really a big deal. The teams sent delegates to a coordination meeting twice a week. The aim was to coordinate the work across team boarders - who needs information from whom, who can help unblock work, what dependencies do we have, etc. What I really liked is that the teams sent delegates on a rotation principle: every week a different person was representing the team. That really helped a lot in terms of understanding the whole program world compared to the own small team garden. It was no longer “the guys in our team are the good ones and all the others are troublemakers.” It was much more like, "what can WE all together do to make the program successful?” Furthermore, it also fostered leadership among team members. I’m not so much a fan of the Highlander Principle “there can be only one.” I think we need much more leadership on all levels than single point of failures like Kanban Masters or so.

InfoQ: You gave an example where you connected kanban boards to manage WIP levels across the full delivery cycle. Can you explain how it works?

Klaus: Connecting systems is a way of scaling Kanban. However, it’s a little bit difficult to talk about scaling in the context of Kanban because what you’re actually doing when you’re scaling is that you’re simply solving a problem. In real life I encountered especially two kinds of problems, where scaling is a solution: 

(1) Aggregating Services

There is a pattern that I see quite often: Service A depends on service B consistently. An example could be e.g. there is a Kanban system for frontend development and this service is consistently waiting for a backend development service as shown in the Figure below.

(Click on the image to enlarge it)

This dependency of course adds up quite a lot of lead time. What I see quite often is that you simply combine these two services to one service like “Frontend and Backend Development”. I’ve seen multiple realizations of this. The easiest is that two teams simply merge to one bigger team. However, there’s of course a limit of persons where this makes sense. What I also see quite often is that the teams do not merge to one big team but they use a common Kanban system for coordination.

(2) Connecting Services

Connecting is similar. There are again two services which depend on each other but now the situation is that service B takes the output of service A as input. Example: Imagine there’s a development service and an integration service. When development is finished, they pass the work over to integration. When the services are not connected they do it by putting the work item in an unlimited buffer like “ready 2 integrate” which is basically the Done column of the board. From development's point of view the work item might be done. However, from the customer’s point of view it isn’t because it has to be integrated to the whole system and it also needs to be rolled-out, etc. Kanban is a lot about seeing the world through the customer’s eyes and therefore, it simply makes sense to connect the two services. Furthermore, eliminating unlimited buffers means that you get a predictable work flow.

(Click on the image to enlarge it)

To fix this, you simply connect both services and put a WIP limit on the “ready 2 integrate”. What you actually do is, you scale in a service oriented fashion by connecting single services like shown in the Figure below. That’s a really SAFE way of scaling ;-) Scaling Kanban means simply doing more Kanban. You don’t need a blueprint to do it because it is just common sense - it’s just how your organization works. You can find more on this in the blog article “Scaling Kanban”: 

(Click on the image to enlarge it)

InfoQ: Can you mention some of the benefits that the program got from applying kanban?

Klaus: The biggest benefit was definitely that all teams were coordinating their work in order to reach a common goal: the success of the program. In the beginning it was really hard for all parties to focus on flow and not on utilization. It doesn’t feel right not to start new work because we reached a WIP limit and focus on improving the system instead. However, it totally paid off: after only a couple of weeks, lead times of Epics were halved, on the other hand we could see throughput going up, and a lot of pressure was taking off the teams. The result was that we were able to deliver more stuff in a shorter period of time with happier people.

About the Interviewee

Klaus Leopold is computer scientist with many years of experience in helping organizations from different industries on their improvement journey with Lean and Kanban. He is co-author of the book “Kanban in der IT” (in German, published by Hanser Verlag in 2012) and co-author of the English translation "Kanban Change Leadership” (to be published by Wiley in May 2015). Klaus is one of the first Lean Kanban trainers and coaches worldwide. He was awarded with the Brickell Key Award for “outstanding achievement and leadership” within the Kanban community in San Francisco, 2014. Klaus is also a founding member of the management network Stoos. His main interest is agility beyond team level, especially in programs from 30 to 500 people. He publishes his current thoughts on his blog www.klausleopold.com and you can follow him on Twitter at @klausleopold.