Theory of constraints

Planning

Identify bottlenecks and establish the right strategy for optimal production

Planning

What is the theory of constraints?

The Theory of Constraints (ToC) is a management paradigm to ease flow. It is based on the novel “The Goal” [Goldratt 1984] which exposes the idea that "a chain is no stronger than its weakest link". Goldratt proposes 5 steps to implement the ToC:

  1. Identify the System's Constraints
  2. Decide How to Exploit the System's Constraints
  3. Subordinate Everything Else to the Above Decision
  4. Elevate the System's Constraints
  5. If in the Previous Steps a Constraint Has Been Broken, Go Back to Step 1

Simply put, you should remove any bottleneck except if it impedes any other part of the organization in order to support a systemic view. Bottlenecks are not always what and where we think they are and  Gemba walks will help you to spot genuine issues [Marris 2016].

At a bird view, there are four kind of organization named VATI [Cox 2010]

  • V-Shaped organizations: from a unique raw material, intermediate components are generated from multiple combinations and finally assembled to build different products
Illustration of V-Shaped organizations from [Moustier 2020]
Illustration of V-Shaped organizations from [Moustier 2020]


  • A-Shaped organizations: from a set of raw materials, the organization makes combinations to assemble a unique product
Illustration of A-Shaped organizations from [Moustier 2020]
Illustration of A-Shaped organizations from [Moustier 2020]

  • T-Shaped organizations: from a set of raw material, a transformation pipeline provides a template of the product which is declined at the end to deliver multiple purposes
Illustration of T-Shaped organizations from [Moustier 2020]
Illustration of T-Shaped organizations from [Moustier 2020]

  • I-Shaped organizations: from a set of raw material, a transformation pipeline provides a unique product
Illustration of I-Shaped organizations from [Moustier 2020]
Illustration of I-Shaped organizations from [Moustier 2020]

At a lower level, the ToC proposes a model named “DBR” [Cox 2010] for Drum-Buffer-Rope:

  • the Drum provides some cadence which is also found in SAFe [SAFe 2021-07]
  • the Buffer provides some small intermediate storage area to avoid the “nothing to do” effect on a process but small enough to avoid wastes from important stocks
  • the Rope is a trigger pulled notably from the slowest process to inform upstream producers some bandwidth may be available downstream to enable pulled systems with tamed WIP
Illustration from [Moustier 2020]
Illustration from [Moustier 2020]

The DBR teaches the processes should apply cadence based on the slowest process to avoid congestion [Cox 2010]. The cadenced system shown above should then be aligned with the process #2.

Impact on the testing maturity

The DBR part of the ToC states that the process steps upstream of a bottleneck should be aligned with the slowest part of the process. Therefore, if testing is done at the end the ideation process (development included) should wait for the end of testing with a “rope” to trigger new needs to arrive in the sprint. If the rope is not located after testing, the upstream activities will inevitably congest testing and the WIP. The diagram here below shows the DBR configuration for a Scrum team with testing after development and appropriate ropes:

  • buffers at Product Backlog (PB), Sprint Backlog (SB) and testing
  • cadence set at Sprint Planning level - there could also be a sub-cadence at development level for the daily sprint but it does not cadence processes unless you are doing Scrum in #noestimate [Jeffries 2013] [Ageling 2018] flavor
  • the rope should be set between 

           o PB and SB - the amount of needs inserted in the PB should not exceed a maximum thanks to 5S on the Backlog done on a regular basis in the PB

            o Testing and SB - the SB should regulate the items to get started once items are “done” (Definition of Ready (DoR) may also be used to regulate the flow on the SB)

The Sprint in terms of DBR as per Scrum if testing happens at the end
The Sprint in terms of DBR as per Scrum if testing happens at the end

To improve your flow, Lean Management techniques should be involved such as Value Stream Mapping (VSM) [Poppendieck 2006] and other agile/DevOps techniques to spot improvement opportunities. For instance, to make testing more flow-compatible, we need to introduce some DevOps techniques:

The Sprint in terms of DBR as per Scrum with flow-compatible testing
The Sprint in terms of DBR as per Scrum with flow-compatible testing

The ToC is actually part of a wider scope of practices named PanTesting to scale agile testing.

Agilitest’s standpoint on this practice

Even if scripting test scenarios with Agilitest is rather lightweight since the tool is #nocode based [Forsyth 2021], automating scripts is something to take care of in terms of flow.

Traditional waterfall like organizations would delegate automation at the end of the SDLC which impedes the delivery flow. Introducing Lean/agile/DevOps techniques should improve your time-to-market and the First Pass Yield that goes along.

To discover the whole set of practices, click here.


To go further

© Christophe Moustier - 2021