Kanban helps organizations to get insight into their work-in-progress, and establish a pull system where demand and capability can be balanced. A first step is to find out what the real capability is and visualize the flow. If there is a misbalance then organizations can take action adapting their capability towards the demand.
Florian Eisenberg presented Kanban: not "yet another development process" at the 2013 international conference in Central Europe about Lean and Kanban. InfoQ interviewed him about evolutionary change and how you can balance demand and capability in organizations.
InfoQ: At the Lean Kanban Central Europe conference you talked about Kanban as an evolutionary change management method. Can you elaborate on that?
Florian: Change traditionally comes along with a defined end state and a plan to reach that state. This approach ignores the fact that organizations are complex adaptive systems within a complex environment and that they have humans as employees. Because of this complexity, we are unable to gather full information about the general environment (e.g. governmental regulations), behavior of competitors, behavior of customers, and how all this will change over time. Like Niels Bohr said: „Predictions are hard, especially about the future!“ If we accept this as a truth, the only sensible one is an evolutionary approach to change. Taking one small step at a time, testing out what is working and what is not. This means that you can not and should not plan your change on a long time horizon - unless you‘re willing to throw away lots of work to exploit the changing environments.
But does that mean we should change evolutionary without an agenda in mind? It doesn't. Evolutionary change is a mean to reach the three agendas of Kanban: sustainability, service orientation and survivability. These three agendas are what defines business agility. And within these three agendas, there are sets of fitness criteria that will help you towards agility in your field of business. Kanban is agnostic about the fitness criteria themselves, but it should force you to think about these criteria constantly. Whenever your business and environment change, your approach to business should change, and maybe your fitness criteria, too. Since we can not know in advance when this change is going to occur, we can not plan for it. We can only build up resilience on a system level and enable quick reaction to changing constraints. With Kanban, we can experiment fast and in a safe-to-fail way. We make sense of our system collaboratively, try different approaches and follow through with the ones that give us the most benefit for our business and environment. That’s called evolutionary change.
InfoQ: Kanban can help to balance demand and capability. Why is this balance so important?
Florian: Let’s look at the three states of capability versus demand:
First, there is „more capability than demand“. That means, we can service all requests instantly with minimal delay for our customer. That’s a very comfortable position from a service perspective. If we look at it from an economical perspective, it might become obvious that we are spending money for excess capability. We would need to make our clients pay premium for an excess capability
Second: Demand exceeds capability. This is the opposite of the first case, meaning that our clients will have to wait for service. Understandably, they will ask from time to time why their service request is not being serviced, adding more demand to the system. From an economical perspective, this looks very comfortable: full resource utilization, more requests from our clients than we can service. We can make the ones that need better service pay more and just push these items through with higher priority. That’s what lots of organizations do. From a client’s perspective, this is a total disaster. As a client, I have little to no predictability (due to high priority items delaying mine), very slow service times and yet I am not paying an extra low service fee. The understandable reaction is, of course, pushing more requests into the queues, requesting better service, and expecting better quality. Slowly but surely, the clients will start looking for alternatives on the market, putting pressure on my economical situation, making me raise utilization even further and becoming more cost-effective, meaning accepting more demand into the system. So the situation which looked very comfortable became very uncomfortable because I was not able to service my clients at the level that they expected.
The third state is balanced capability and demand. Work can flow freely through the system filling it out to an economically reasonable level, yet there is almost no excess capability for which clients have to pay. It becomes clear that for both sides - clients and service provider - balanced capability and demand is a worthwhile goal.
InfoQ: Can you give some examples on what organizations can do on a short term when the demand is too high for their teams?
Florian: The one sensible thing to do is finding out what the real capability is. A lot of teams I meet don’t know how high their capability is, they just know that demand is too high. Whining about a situation usually doesn't improve it. So, find out what your real capability is and start negotiating and making some tough decisions. If you have lived beyond your standards it’s not the time to wish it was the way you wanted it to be. It’s the time for facing your reality, start communicating with your clients about your service levels, your capacity, and what they can do to improve their level of service. That usually means focusing on the few valuable things rather than getting it all.
My colleagues was at a clients the other day. He started with putting one empty sticky note per item in the product backlog on the wall in the unfinished, in progress, and finished status. When the team saw their work visualized, they realized that the question was not „how do we get the whole backlog finished until January 31st?“ but „which are the items that have the highest cost of delay?“. When this question became apparent, they obviously changed their behavior to regulating their demand instead of pushing everything into an in progress state.
So the question really is: How do we determine how high capability really is? We can do that by measuring the amount of work that flows through the system. We need to make sure, though, that the items of work stay in the system for roughly the same time. The measurements can be fairly rough if we don’t want to be overly precise. „Traverses the system in the same time“ means, however, that we can’t have unlimited buffers where work stays to rot. Unlimited buffers often cause a big distribution in lead time and make it very hard to determine the real capability of the system. Once we have the real capability, we can start forming the demand by negotiating.
InfoQ: Can you give some examples of organizations / teams that have increased their capability? How did they do it?
Florian: Most people know how to improve their capability. And most people have done it - by hiring new people, or by cross-training staff. It’s not that it is very hard to do. It’s just that it is an investment you have to make. The bad thing is that it takes time and usually money. If you‘re in an economically tight situation, it’s probably not the number one approach to spend more money. In these situations, I‘d usually rather look at ways to raise liquidity without investing heavily. Sometimes canceling one project (which might cost money) can give you more short term liquidity than hiring an additional tester or developer.
InfoQ: Could you give advice what teams can do if they want to get more insight into their demand-capability balance?
Florian: First thing I usually do is to ask whether anybody is dissatisfied with the current state of workload, service they get, or concerned about the market agility the team or organization is showing. If everybody is really happy with the performance of the team and the cost associated with it, then there’s usually no problem with the demand-capability balance on this level. If there are dissatisfactions which should be addressed, then visualizing the work in progress and the upcoming backlog can give you great insights as a next step. Overburdening of a system will almost always become obvious when demand and actual work is being displayed. So now that you see your problem, the question changes from „do we have a problem and of what kind is it?“ to „how big is the problem and what can we do about it?“ So the next step is data analysis of the demand, queues within the system, work-in-progress, and the actual outcomes - both quantitatively and qualitatively. Take a look at your work item types, talk to customers of expectancies, have a look at how much rework you‘re doing, and find out what’s a sensible work load for team members. With all this data you can sit down with the team, other parts of the organization and your customers and figure out what the next step to improving is.
