Last week we introduced the Theory of Constraints. Every situation will always have a constraint that needs to be alleviated. There are three key questions that ToC can help you answer.

1. What to change?
2. What to change to?
3. How to change?

This post will look into answering the first question: what to change?

 

What to Change

Assess the current reality of the situation. The following tools are used to identify the core problem or conflict and the assumptions that sustain it.

• Evaporating Cloud: examines a core conflict to prove that any conflict in requirements to attain a goal are merely due to unexamined assumptions (e.g., “in order to have X, we must do Y, which conflicts with Y’, because…”).
• Current Reality Tree: describes (only to the level needed to achieve agreement) how problems are related to each other, to policies, to measurements, to practices, and to the core conflict (e.g., “if X occurs, then Y, because…”). This tool provides guidance for developing a solution to the root problem.
• Five Whys: an iterative question-asking technique used to explore the cause-and-effect relationships underlying a problem. This is a tool which can enable you to determine the root cause of a problem.

 

Evaporating Clouds

The Theory of Constraints assumes that there is no true conflict within a system. All conflicts are actually unexamined assumptions. The Evaporating Cloud is a tool which exposes this assumed conflict and attempts to resolve it by examining the underlying assumptions. In an Evaporating Cloud, a goal or objective has at least two requirements whose prerequisites are in conflict.

 

 

For example, if our objective is to quickly deliver software with minimal defects, it may be required that (1) quality assurance approves completed work before release and (2) developers deliver new features as quickly as possible. In order to have QA approve completed work before release, all work must go through QA before release. In order for developers to deliver new features as quickly as possible, however, they should continuously deploy software to users.

 

 

 

The above graphic is read as:

In order to quickly deliver software with minimal defects, I must have QA approve all completed work. In order for QA to approve all completed work, I must have all work go through QA before release. On the other hand, in order for developers to publish new features as quickly as possible, I must have developers practice continuous deployment. I can not have all work go through QA before release and have developers practice continuous deployment.

The conflict in this example is that we can not have all work go through QA before release and also have developers practice continuous deployment. This conflict, however, is due to at least one unexamined assumption. We believe we must have work go through QA before we deliver new features, creating a backlog of QA work and thereby forsaking speed of delivery for a minimization of defects.

This assumption can be proven false by identifying a way we can deliver new features with minimal defects without creating a backlog of QA work. Once we prove that we can quickly deliver new features with minimal defects, the conflict evaporates: developers can practice continuous delivery and all work can continue going through QA for approval before release. This allows us to quickly deliver software with minimal defects.

For example, we may identify an assumption such as “QA is performed manually, which takes time,” or “due to unpredictable changes in software, every feature must be re-verified before any new feature is published.” Either of these assumptions can be proved invalid by introducing automated testing, removing the human time constraint on verifying all past completed work.

 

Current Reality Tree

A Current Reality Tree describes the cause-and-effect relationship between undesirable effects. Tracing these relationships down to their causes should result in the discovery of a single root cause.

 

 

“If … then …” relationships are read from bottom to top. Additionally, you may add assumptions underneath undesirable effects. An assumption is a statement accepted to be true or certain to happen, without proof. Assumptions add a “because” clause to the if-then statement: “If … then … because …”

 

 

In the above example, the identified root cause — the lowest-level cause from which all other undesirable effects originate — is that developers and QA do not find all defects via manual testing. The above can be read as:

If developers and QA do not find all defects via manual testing, then we will introduce QA processes to find defects. If we introduce QA processes to find defects, there will be delays in delivering new features. Multiple undesirable effects stem from this undesirable effect: developers try to work faster, and QA people work longer hours. Developers try to work faster because developers need to deliver features faster to compensate for QA process delays. If developers try to work faster, then developers will introduce more defects because working faster causes developers to miss details, resulting in more mistakes. QA people work longer hours because QA people need to work extra to compensate for QA process delays. If QA people work longer hours to compensate for process delays, then QA people will miss more defects because longer hours will reduce cognitive function, resulting in more mistakes.

 

Want to improve your situation? Use a #CurrentRealityTree to find the root cause #MetovaToC [Source: @Metova]  (Click to Tweet!)

 

The above Current Reality Tree adequately outlines the cause-and-effect relationship between the system’s undesirable effects in our current reality. Due to this cause-and-effect relationship, you can determine that we will continue to see these undesirable effects so long as the root cause remains in effect. So long as we fail to find defects, we will have unhappy developers and unhappy QA people.

Note that a Current Reality Tree is best used as a communication tool. As small of a group as possible should be used to identify undesirable effects, assumptions, and the causal links between undesirable effects. Once you have built the Current Reality Tree, you can present it to the group for scrutiny — identification of logical fallacies, and additional undesirable effects and assumptions. Through this exercise, your entire team will gain a clearer understanding of the root cause of the system’s undesirable effects.

For the purposes of this example, only a few assumptions have been identified. Note, however, that any undesirable effect may have several assumptions, and that most undesirable effects have at least one assumption.

Assumptions may be true or false: a false assumption does not negate the undesirable effects presented in a Current Reality Tree. However, a false assumption can be used as a starting point when identifying injections that transform your Current Reality Tree into a Future Reality Tree. This will be covered in later tools. For now, understand that a Current Reality Tree may have false assumptions.

The Current Reality Tree can be transformed into a Future Reality Tree by injecting new proposed actions, policies, and behaviors.

 

Five Whys

Taiichi Ohno devised the Toyota Production System based upon a simple practice: asking “why” enough times to dig down into the underlying root cause of a problem. Known as the Five Whys, you can begin identifying a constraint in the system by asking why an undesirable effect exists.

Continuing with our previous example of quickly delivering software with minimal defects, one might start with an undesirable effect such as QA people follow a strict QA process that takes a long time. Why do they follow this slow process? QA has failed to identify defects in the past, so it makes sense to institute a process that identifies concrete functional requirements and requires verification from a QA person. This takes more time, however, so QA people have to work more to compensate for a heavy process. This extra work results in decreased cognitive function for overworked QA people, which in turn causes QA people to miss more defects.

There may be an even deeper cause than has been identified in this example, or perhaps this string of decisions was made with underlying assumptions which can be proven false. The key takeaway is that simply asking the question “why?” can allow you to gain a deeper understanding of problems in the system.

Also recognize that you may have answered any one of the above “why?” questions completely differently than what is written here. You may have even jumped to deeper conclusions with more or fewer questions. Ask “why?” as many times as needed to satisfy your curiosity and identify a root problem.