Theory of constraints

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

‍

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

‍

• 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

‍

• I-Shaped organizations: from a set of raw material, a transformation pipeline provides a unique product

‍

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

‍

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)

‍

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:

• Development and testing are merged
• Feature toggles are added to User Stories (US) for dark launching or canary releasing
• When US provide a Minimum Marketable Feature (MMF) that has been tested end-to-end as soon as possible both in Shift Left and Shift Right modes, the toggle flags are activated and the release is now visible to End-Users (or part of them)
• Monitoring the delivered system should also be introduced to get some Feedback from resources, the domain and the business and spot issues with alerting mechanisms such as the one described in Google’s SRE [Beyer 2016]

‍

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.