Metova uses the Theory of Constraints in daily decision making. As such, we want Metovians to have a working knowledge of tools that will help them find and alleviate the constraint. This series of blog posts follows along with a class our CTO, Dave Lane, is teaching at our Franklin, TN office. If you missed the other articles, it’s not too late to catch up! They are listed below.
Introduction to the Theory of Constraints
What to Change to?
Visualize the solution or ideal situation that does not exist in your current reality. The following tools are used to describe a goal-oriented system’s desired state and to address undesirable effects that may result from the proposed solution.
Future Reality Tree: describes a new reality by building upon a Current Reality Tree through the injection of new proposed actions, policies, and behaviors (e.g., “If we do X, then Y, because…”). This tool provides guidance for communicating a vision of how to change the undesirable effects found in a Current Reality Tree to desirable effects.
Negative Branch Reservation: a reservation which describes a new branch of undesirable effects that will be created as a result of the injections made in a Future Reality Tree. A negative branch links a proposed action with a suspected negative outcome (e.g., “If we do X, then Y, because…”). Negative branch reservations serve to complete the solution while creating buy-in to the solution from those who bring up the reservations.
Future Reality Tree
Taking the previous Current Reality Tree example, we can inject new proposed actions, policies, and behaviors, to alter the reality we face within the system. It is difficult to appropriately illustrate a Current Reality Tree that includes injections that will transform into a Future Reality Tree as each injection will result in a rebuilding of the reality of the system. Due to the cause-and-effect nature of a reality tree, injecting a new behavior will alter all linked effects. In the below template, we replace lower-level undesirable effects or problems (such as a root cause) with Injections (new proposed behaviors). The result is a change in behavior in the mapped system, resulting in the desirable effects we wish to see in our new reality, as well as the potential for new undesirable effects.
Note that it’s perfectly okay for an injection to result in an undesirable effect so long as the injection helps address the core problem (root cause). These undesirable effects can be addressed through a Negative Branch Reservation, a concept which is covered in the next section.
Desirable effects in the Future Reality Tree rely on preconditions instead of assumptions. A precondition is a condition which must be fulfilled before a desirable effect can happen. Whereas an assumption in a Current Reality Tree may be true or false, a precondition in a Future Reality Tree is assumed to be necessary to enact the desired changes to the system.
For a more concrete example, we will continue with the earlier example of tying our value to the time we work. We can start building our Future Reality Tree by identifying the desirable effects, the positive outcomes of changes we inject into the system. Our desirable effects include: software is delivered quickly, and software is delivered with minimal defects. From there, we can identify the injections and preconditions that must exist in order to realize this new reality.
Negative Branch Reservation
In the Future Reality Tree example, one of our injections created an undesirable effect: if developers write automated tests for acceptance criteria, then no one outside of the developers has the opportunity to verify feature acceptance. This could lead to other undesirable effects, such as incorrectly implemented features. When an injection creates undesirable effects, we refer to the undesirable branch of the tree as a Negative Branch Reservation.
These reservations are best dealt with by modifying underlying injections. In the above example, imagine we have an injection below write automated tests for acceptance criteria. The underlying injection can be if we specify acceptance criteria for each feature, then we can write automated tests for acceptance criteria.
By modifying that deeper injection,we can ensure there is an opportunity for the product owner to independently verify feature acceptance. For example, we may decide to change the injection to read the product owner approves acceptance criteria for each feature. Adding product owner approval for acceptance criteria will clearly delineate what is expected to be covered in automated tests for each feature.
If the product owner approves acceptance criteria for each feature, then the product owner has the opportunity to verify feature acceptance, developers write automated tests for acceptance criteria, and QA approvals take less time. Everyone wins!
In the upcoming weeks we will be discussing how to change and the five focusing steps. See you then!
