Five Focusing Steps

1. Identify the Constraint

In order to increase the throughput of the system, you must alleviate the current bottleneck — the thing currently limiting you from attaining your goal. A common failure in identifying the constraint is the discovery of future assumed constraints. Remember that alleviating a constraint will result in the emergence of a new constraint: this means any effort expended toward solving a future constraint is a waste until the current constraint is removed.

This is due to the highly probable possibility that you will identify an incorrect future constraint. The system will evolve once you alleviate the current constraint, meaning that whatever currently looks to be a future constraint may disappear completely once your new reality takes hold. Therefore, it is sensible to only identify and address the current constraint.

In our example desire of quickly delivering software with minimal defects, we identified that developers and QA do not find all defects via manual testing. We discovered this root problem by building a Current Reality Tree, outlining the causal relationships between undesirable effects.

The Evaporating Cloud, Current Reality Tree, and Five Whys are tools you can use to identify core conflicts or root causes for undesirable effects in a system.

 

2. Exploit the Constraint

Once the constraint is identified, you should maximize productivity at the constraint. In other words, the constraint should be 100% utilized. As the constraint is the slowest or most limiting aspect of the system in terms of attaining your goal, ensuring the constraint is utilized is the first step in increasing throughput.

Once we recognize our constraint is that we can only deliver software with minimal defects as quickly as QA can approve completed features, we must exploit the constraint by ensuring that all QA people have exactly as much work lined up as they can handle. Let us assume that this means each QA person has 40 hours of work per week, as we find that working over 40 hours in a week reduces team members’ happiness and productivity, which will hurt the quality of their work and, in turn, the survivability of the company.

Why do we say only to line up exactly as much work as QA people can handle? If we do not have sufficient work to keep QA people busy, they must not truly be the constraint in the system. If we have too much work lined up to keep QA people busy, we create a backlog greater than can be reasonably processed, which will back up earlier parts of the process.

In this example, an unsuitably large QA backlog will decrease the velocity of developers, as they receive feedback on their work more slowly, making continued production before the QA “machine” eventually come to a halt. If the development team is unable to receive feedback on their work product, they will be unable to deliver software to customers or end users. Therefore, we only benefit by lining up exactly as much work as QA people can handle.

 

3. Subordinate Everything Else to the Constraint

The constraint is the slowest or most limiting aspect of the system. Non-constraints should therefore provide the constraint with exactly enough resources to fully utilize the constraint. The constraint should never be starved of input.

If our developers begin outpacing our QA people, development work will slow down due to an unsuitably large QA backlog. In order for developers to continue doing their job, we must address the QA backlog. This may mean that developers should assist QA in working through the QA backlog. Reassigning developer throughput from completing features to performing QA on completed features will decrease the QA backlog, alleviating the constraint. This reallocation of non-QA resources to address the QA bottleneck is considered subordination. Developers must subordinate completing new features to completing QA tasks.

As an aside related to this specific example, you may recognize that a developer should not verify their own work. This is true: if a developer is capable of approving their own work, there is no need for a QA process at all! However, assuming that QA is a valuable part of quickly delivering software with minimal defects, we can address this negative branch reservation by instituting a policy that no developer may perform QA on a feature they have completed.

 

4. Elevate the Constraint

Once the productivity at the constraint has been maximized, the resources addressing the constraint must be expanded in order to further increase the throughput of the system. Increasing the capacity at the constraint requires investment, perhaps in purchasing new equipment or hiring additional staff.

Once our existing team is completely utilized by addressing the constraint, it may be necessary to hire more QA people to increase throughput. Alternatively, as we did in earlier Reality Tree examples, you may devise a systematic change in how work is produced or managed. Introducing automated testing to address the QA constraint requires a time investment of retraining the development team to write automated tests, and monetary investment in testing tools, frameworks, and continuous integration servers. Hiring more people is a common example in elevating the constraint, but other indirect or or implicit costs such as these may be incurred by implementing changes to a system.

 

 

5. Prevent Inertia from Becoming the Constraint

Once a constraint has been elevated, a new constraint will emerge within the system. To further increase the throughput of the system, you must identify the new constraint, exploit the new constraint, subordinate everything else to the new constraint, and then elevate the new constraint. The process of on-going improvement is simply defined as the repetition of these five focusing steps.

Continuing our example, we may find that hiring more QA people alleviates the constraint of quickly delivering software with minimal defects and that a new constraint presents itself. For example, perhaps the constraint becomes developers can not complete features as quickly as QA can verify features. In order to address this new bottleneck, you can begin the Five Focusing Steps process over again: once the constraint has been identified, move on to exploiting the constraint, and then subordinating everything else to the constraint, and so on.

It is possible that identifying the new constraint and exploiting it may be enough to address the constraint. You will know that you have gone far enough in addressing a constraint once you no longer have enough work to keep resources at the constraint busy, or once resources focused on the constraint begin producing a backlog of work for resources located later in the flow of work. If you lack appropriate measurements around the current constraint, you may otherwise notice the constraint has moved by encountering undesirable effects elsewhere in the system.