Understanding the 5 focusing steps

The Theory of Constraints (TOC)

The Theory of Constraints complements Agile software development extremely well, it is about applying a mindset of ongoing improvement to your organization. It contains the notion of applying efforts to improve to the areas that will have the most impact and offers some practical techniques for achieving this.

When we talk about the Theory of Constraints what is often thought about are the 5 focussing steps. The steps are not always easy to understand and the wording can be confusing. I’ll attempt to explain the steps with a few examples, where possible I’ll use examples more common to software delivery organizations.

What is a constraint?

Firstly a constraint is neither good nor bad, it just is. Your system has a constraint and no matter what you do, it will always have a constraint. You may say that in a perfect system the constraint is the external demand for your product or services, but even then there are ways to increase demand or open new markets, and markets have a tendency to change over time.

Do not treat a constraint as a bad thing to be eradicated, awareness and understanding of the constraint is the goal, what to do with that knowledge is a secondary consideration.

Constraints:

A constraint limits the useful output of your system, so any improvements to the constraint will directly impact on the total output of your system.

Conversely improvements to an area that is not a constraint will have no impact on the output of your system.

example:

Let us consider a simple system.  I can build 3 units a day and I can ship 1 unit a day.   

Shipping is my constraint, Building is NOT my constraint.  If I make improvements to shipping and can now ship 2 units a day I have doubled the output of my entire system.

If however I improve the building aspect of my system and can now build 4 units a day, it is wasted effort as I can still only ship 1 unit.  The over production is stuck there.

Any effort to improve any part of the system that is not your constraint is wasted effort. You should instead focus on improving your constraint.

This sounds obvious, but when your organization breaks areas into silos and measures managers on the performance of their area alone you tend to see this a lot. Teams striving for improvement and additional output when they are not the constraint.  The result is make-work. Things that “you know will be needed later” building inventory and so on.  Sadly cost-accounting supports this dysfunction by rewarding the behavior by classifying work in progress and finished goods inventory as an asset when in most cases it is a liability.

I say an hour lost at a bottleneck is an hour out of the entire system. I say an hour saved at a non-bottleneck is worthless. Bottlenecks govern both throughput and inventory.

Eli Goldratt

What is the system?

Our goal when applying the TOC is to identify constraints or rather the constraint in your system.  But that begs the question what is the system?

As a very broad rule of thumb, the system is all that is within your (organization’s) sphere of influence. It is not limited to just one area of the business.

Note: Your sphere of influence should include your market and potential market, and your supply chain, which includes potential recruitment candidates. Anything within which you have authority to influence.  

The 5 focussing steps

1. Identify the system constraint
2. Exploit the constraint
   (Make the best use of what you currently have)
3. Subordinate everything to the constraint
   (Make decisions based on the constraint, the system should run at the pace of the constraint)
4. Elevate the constraint
   (Make improvements to the constraint)
5. Repeat the steps

Step 1 Identify the System Constraint

The three most obvious signs of a constraint are:

• They are always busy
• Work is piling up in front of them (in the case of people this may be requests for help)
• Work downstream is starved, people that are dependent on them are regularly waiting

Note: busy work or excessive Work in Progress can mask these signs, so the first step is to stop any non-essential work, anything that is not needed immediately or cannot be traced to the top priority.  By reducing work in progress it will help reveal where your constraint is.  All too often your constraint is busy doing something not needed.

Once you have identified where you believe your constraint is, we move on to the next step.

Step 2: Exploit the constraint

There is nothing so useless as doing efficiently that which should not be done at all.

Peter Drucker

As we identified earlier any improvement to the constraint improves the output of your entire system. but the converse is also true. Any time your constraint is not working then your entire system is not working, any effort your constraint spends on something that is not immediately needed to deliver value to your customers is output lost to your entire system.  It may not be obvious but this is a key aspect to understand.

Your constraint should be considered in that manner, we say exploit the constraint in the sense that it should be used in the most effective way possible. This means doing the very best you can achieve with what you currently have.

• Exploit your employees that are constraints to get the maximum value (NOT EFFORT) exploiting a constraint isn’t about a death march, it is about getting the most value from them in the long-term.  A happy employee working a sensible number of hours will deliver far more value than an overworked employee.
• Work to keep your employees engaged, engaged employees deliver more value.
• Pay well, your constraint(s) are your company’s most valuable asset, pay them well, they are worth far more to your company than their salary.  replacement, training and adjustment of new employees to replace a constraint directly impact the output of your entire system, learn that cost and value are not the same thing.
• Only work on the highest priority items, make sure you understand the concepts of cost of delay and opportunity cost. Maximize Value !
• Ensure there is a buffer of work before the constraint so that there is no idle time, idle time is time lost to your entire system.
• Avoid multi-tasking, context switching is waste, better to complete one thing at a time, so ensure tasks for the constraint are prioritized properly.
• Ensure your constraint is not working on anything that could be done (even less efficiently) elsewhere.
• Ensure your constraint is not working on anything that is not directly leading to immediate value. Is your constraint booking their own travel, or filling in time sheets, or even making coffee? Or are they busy on a feature that you think will be valuable later?  All of those tasks are directly impacting on the throughput of your entire system, could they be done by someone else (or not at all).
• Does your constraint have all the materials they need, do they have access to the information they need, the right tools and the right support, the right training.  Your constraint should have the right tools, the best tools available.  Your development team should have the fastest computers and the best software for the job, skimping here is one of the most costly errors a company can make.

This leads to a mini-debate on the use of admin assistants and Scrum Masters.  There is a trade-off between the ability for people to solve their own problems, and do their own admin and generally have a broader skill set.  Having an admin to do certain jobs can be a form of exploiting your constraint, but can also create a new constraint if you become dependent on them. Same goes for a Scrum Master, they are a great example of exploiting the constraint that may be your development team: Someone to handle blockers; chase things down; and generally ensure the team is enabled to be most effective all of the time by taking non essential work off them and keeping them focused on delivering value.  But again the risk is that they become the constraint.  Everything is a trade-off.

Step 3: Subordinate everything to the constraint

This is generally the step that is the most confusing. What we are saying here is that all decisions you make in your system and for your system should be made based on understanding where your constraint is.

• Quality, your constraint should not be working on things that are poor quality and may need to be reworked.  Ensure work handed to the Constraint is of the best quality it can be.
• Identify and anticipate problems, if there are dependencies or potential blockers or risks ensure that they are mitigate BEFORE the work gets to the constraint, blocks at the constraint are blocks to your entire system. Have questions answered in advance where possible.
• In the case of story writing, it may be that getting the input from the development team upfront at story writing time leads to fewer problems later, focus on flow and using valuable time effectively.  This is not an excuse to silo the constraint, this is about thinking of ways to use the time in the most effective way possible.
• The rest of the system should work at the pace of the constraint, work should flow, sensible buffers of work should be maintained but no overproduction. Identify a cadence and have the whole system work to that rhythm.
• Have non-constraints use the inevitable slack time to work on tasks at the constraint.  Developers should be testing, testers coding, anyone and everyone should use their slack to alleviate the work at the constraint, regardless of how inefficient they may be – so long as they are not introducing errors or knowledge gaps that may cause further demands on the constraint later.  This is where encouraging T-shaped people can enable us to maximize flow through our system.

As you can see the importance of understanding your constraint and making decisions based on that

Make the bottlenecks work only on what will contribute to throughput today … not nine months from now. That’s one way to increase capacity at the bottlenecks. The other way you increase bottleneck capacity is to take some of the load off the bottlenecks and give it to non-bottlenecks.

Eli Goldratt

Step 4:  Elevate the Constraint

Once we believe we have done all we can to Exploit the constraint and to subordinate everything to the constraint and we still want to improve further then the next step it to elevate the constraint.

Up until now the efforts have been without investment, it has been to utilize what you have in the best way possible, elevating the constraint will generally require an investment of some kind.

• Hiring more or better people to support the constraint (only hire for the constraint)
• Purchase more machines to support the constraint
• Training or coaching the constraint(s) to improve their skills and effectiveness
• Purchase better software, faster machines, better tools, conferencing equipment, more meeting rooms.
• Team building activities, or other ways to improve effectiveness of teams that are part of the constraint.
• You can consider more drastic options such as switching to a different tech stack, if that enables solutions to be solved quicker or may make hiring easier.
• Moving to a new location.
• Entering a new Market or creating more (diverse) products.

Remember all of these options should be undertaken with the specific constraint in mind.

Step 5:  Repeat

Once you have worked through these steps it is expected that you will have been a catalyst for change, it would be good to have a measure of the impact if you can.  But the end result is that your constraint is less of a constraint, allow time to see the impact of the changes and re-assess where your constraint is now. It may be in the same place or a new constraint may have been identified. But in either case repeat the steps and see if further improvements can be made.

Repeat again

The Theory of Constraints is a process of ongoing improvement, if you stop improving entropy sets in and things will get worse, these steps should be repeated and repeated indefinitely and frequently