Kanban, process design and unintended consequences

Kanban, process design and unintended consequences

A few years ago we embarked on developing a complex data acquisition solution to solve a business problem. Fast forward to successful project completion. On being complimented, one of the lead developers on the project said, “What we deployed was exceedingly simple. It wasn’t rocket science”. I was reminded of Goldratt’s statement, “… the key to problem solving is to accept that any real life situation, no matter how complex it initially looks, is actually, once understood, embarrassingly simple!” How true.

I think some context behind this post is in order. “Bottleneck resolution results in win-lose situation.” While Kanban highlights a bottleneck, I find that we are not always in a position to arrive at a win-win situation. It is usually the bottlenecks caused by policy constraints that get escalated; the technical ones are resolved quickly. Bottlenecks caused by policy constraints invariably end up being “either-or” – a win-lose proposition. It is not always easy to arrive at win-win situation, specially in a matrix organization, and I find myself thinking about ways to achieve that. The theory of constraints thinking process has helped.

In The 7 Habits of Highly Effective People, Steven Covey says, “While we are free to choose our actions, we are not free to choose the consequences of those actions. Consequences are governed by natural law.” Think about it every time you talk about process design and re-engineering.

The quickest path between two points is a straight line. Adding extra processing steps as a result of a new policy, causes work to not only stay in the system longer, but also create unintended consequences. For example, what would you do if you have quality issues? The immediate solution that comes to mind is to make the QC process more stringent or introduce additional checks. While this may be good for quality, completion of work will be delayed – lead time may increase. Now we have a conflict.

The sides of the conflict, by definition, are mutually exclusive. Visualizing them helps. (A case for a conflict Kanban here?) Going back to our conflict, we can write down the conflict as:

  • Improve quality by adding QC steps
    • Necessary conditions and Assumptions
  • Delay in work completion
    • Necessary conditions and Assumptions

Is it possible to have both high quality and decrease lead times? Here is a tip: when you see such conflicts, chances are that the improvement you are putting in place is sub-optimal. You need not have to be content with a win-lose situation. The win-lose situation in this case is quality of work (win) and delay in work completion (lose). The goal should be win-win and it’s possible.

The way to break this impasse is to focus on the step you do not like and question its assumptions. In our example, the assumption is that quality can only be improved by adding additional QC steps or making the process more stringent. This is a “quality inspected in” scenario. How about “building quality in” so that the extra QC steps are not needed? Ah, now we are getting somewhere!

Evaporating Cloud: Source: Theory of Constraints Handbook

By working on what it means to get “quality built in” we can get to the root of the problem and address it, rather than addressing a symptom.

What I have explained here is an attempt to describe the Theory of Constraint’s problem solving technique – the evaporating cloud. The D and D’ in the image shows the conflict, followed by the necessary conditions to reach the objective. The image needs to be read from right to left. I have begun recently experimenting and learning this technique. I find it very effective at resolving conflicts. It takes some discipline to continuously use it in your daily decision making.

While Kanban for software engineering is an awesome process to help highlight bottlenecks, it inherently does not provide the process to resolve issues. It assumes the team would adopt a system thinking process to solve the bottleneck issues. This is not necessarily the case. I find the need to use additional tools to help resolve bottlenecks, especially if it involves a policy change. Evaporating cloud, cause and effect trees (5-whys in the LEAN world) are some of the tools that you would probably need to get to a win-win resolution of a bottleneck.

What tools do you employ to resolve bottlenecks highlighted by the Kanban?

Photo Credit

2 thoughts on “Kanban, process design and unintended consequences

  1. I have evolved my approach to conflicts. First we agree to the objective. Once that is accomplished, figure out the necessary conditions between each of the conflict and objective. During that exercise, a lot of underlying assumptions comes to light. It’s then easy to address the assumptions and take appropriate actions.

    Ultimately, evaporating cloud is just a conflict resolution tool. If you have other processes/tools to help resolve conflict and it works, there is no reason to make the switch. 🙂

  2. 5 Whys is the main one I use. It helps us question assumptions about how my teams are working and ensure we are looking at the whole system instead of doing local optimization.

    I’ve experimented with Evaporating Cloud in the past and I think I’m 80% of the way towards fully understanding it, but for some reason it’s never really resonated with me. I haven’t had a lightbulb moment where I could see how to apply it.

    Any thoughts on Evaporating Cloud for use in our everyday work would be awesome!


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Back To Top