Theory of constraintsPlanning
Identify bottlenecks and establish the right strategy for optimal production
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:
- Identify the System's Constraints
- Decide How to Exploit the System's Constraints
- Subordinate Everything Else to the Above Decision
- Elevate the System's Constraints
- 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
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 go further
- [Ageling 2018] : Willem-Jan Ageling - SEP 2018 - “The logic of #NoEstimates” - https://medium.com/serious-scrum/the-logic-of-noestimates-4238e0be3bb6
- [Beyer 2016] : Betsy Beyer, Chris Jones, Jennifer Petoff et Niall Richard Murphy - « Site Reliability Engineering: How Google Runs Production Systems » - O’Reilly Media - 2016 - ISBN-13 : 978-1491929124 - https://landing.google.com/sre/sre-book/toc/index.html
- [Cox 2010] : James F Cox III & John Schleier - “Theory of Constraints Handbook”
- [Forsyth 2021] : Alexander Forsyth – JAN 2021 - « Low-Code and No-Code: What’s the Difference and When to Use What? » - https://www.outsystems.com/blog/posts/low-code-vs-no-code/
- [Goldratt 1984] : Eliyahu M. Goldratt et Jeff Cox - « The Goal - A Process of Ongoing Improvement » - North River Press - 2004 (1ere ed. 1984) - ISBN: 0-88427-178-1
- [Goldratt 1990] : Eliyahu M. Goldratt - « What is this thing called Theory Of Constraints and how should it be implemented? » - North River Press - 1990 - ISBN 9780884270850
- [Jeffries 2013] : Ronald E Jeffries - APR 2013 - “The NoEstimates Movement” - https://ronjeffries.com/xprog/articles/the-noestimates-movement/
- [Marris 2016] : Philip Marris - « How to identify bottlenecks in production and projects » - 04/JAN/2016 - https://www.youtube.com/watch?v=ulXqO86OfpU
- [Moustier 2020] : Christophe Moustier – OCT 2020 – « Conduite de tests agiles pour SAFe et LeSS » - ISBN : 978-2-409-02727-7
- [Poppendieck 2006] : Mary Poppendieck & Tom Poppendieck - SEP 2006 - “Implementing Lean Software Development: From Concept to Cash” - ISBN 9780133812848
- [SAFe 2021-07] : SAFe - FEV 2021 - “Principle #7 – Apply cadence, synchronize with cross-domain planning” - https://www.scaledagileframework.com/apply-cadence-synchronize-with-cross-domain-planning/