24 Nov, 2022
In my previous blog I discussed the Theory of Constraints, a process improvement model used to determine the bottleneck in a process and break that constraint. It can also be used as a continuous improvement method to identify the new constraint that emerges each time the existing constraint is broken.
But what happens when we encounter a constraint which is immovable? Do we give up trying and accept that all systems are imperfect?
No. We must work to protect the constraint. And there is one such concept that exists for doing so: Drum Buffer Rope.
Drum Buffer Rope (DBR) is a concept developed by Dr. Eliyahu M. Goldratt, originator of the Theory of Constraints. It is a scheduling model that sets the overall rhythm of a process to that of its constraint (or bottleneck). It may sound whimsical but you are bound to have encountered the problems that it aims to solve.
Let’s break the concept down into its three components:
The drum in DBR is the constraint. Think of it as a drum beat which sets the tempo for the entire process, because the constraint will always determine the rate of output.
The buffer in DBR is a construct used to protect the constraint and absorb variation. There are two types of buffers in Drum Buffer Rope:
The first is the constraint buffer, which is the amount of work before the constraint. Because the constraint determines the speed of the entire process, we need to ensure that there is always work available for the constraint. The rate at which work is fed into the constraint buffer is determined by the rope (more on that shortly).
The second buffer is commonly referred to as the shipping buffer - I prefer to call it the delivery buffer. This buffer’s purpose is to absorb the variability of estimates for work performed by the constraint, thereby protecting performance against due dates.
The rope in Drum-Buffer-Rope is the mechanism used to pull work to the constraint buffer only when it needs to be replenished. Though we always want work available in the constraint buffer, arbitrarily pushing work to it will often lead to a build-up of work in process and risk decreasing productivity.
Now that we’ve defined the three components of DBR, let’s apply them to real-world scenario:
Let the Beat Drop
Daphne is a business systems manager at a big box retailer which recently implemented a new third party ERP system.
The ERP system has been live for two months. Now that people in the business are familiar with the new system, the 5 business unit leaders are beginning to raise new requirements with Daphne to improve its functionality.
Daphne creates a specification for each new requirement and submits it to the vendor’s technical account manager, Arman, for review. Arman’s team performs analysis for each new requirement and provides a quote back to Daphne.
If the CTO signs-off on the quote, Arman’s team will proceed to implement the new requirement. The changes are deployed as microservices which can then be enabled by Daphne using a feature toggle.
Daphne’s business stakeholders are becoming increasingly frustrated with how infrequent new requirements are being delivered. It seems that the more new requirements Daphne raises with Arman, the less requirements actually get implemented. Daphne raises these concerns with Arman.
Arman estimates that it takes the same amount of time to perform analysis or implementation of a change (1 day). In a single week, his team has the capacity to perform 10 days of work.
There are some weeks where Daphne might raise 8 or 9 new requirements from the business. There is an agreed SLA in the vendor contract that new requirements be analysed within 1 business day of being submitted – however there is no agreed SLA for the implementation of new requirements. The end result is that Arman’s team spend most of their time performing analysis rather than implementing changes.
Therein lies the fallacy of “keeping busy” - by creating more work for Arman’s team, Daphne has made them less productive!
If we’re to visualise the process as it stands, it looks a lot like a traffic jam with very little work flowing through to completion:
Here is how Daphne can apply DBR to her situation:
Daphne has identified the constraint in the process – Arman and his team – but as the constraint is a third party, breaking it may be outside of her control. So instead of trying to break the constraint, Daphne can try to protect it.
The constant pushing of work to the constraint (analysis of new requirements) has created significant work in process, which in turn has reduced the constraint’s productivity (implementation of new requirements, i.e. the output).
Daphne realises that a buffer is required before the constraint – there should always be replenishment of work for Arman and his team, but it should be gated and released as required.
If Daphne controls the amount of work being fed to the constraint buffer, Arman can start to provide accurate delivery dates for his team’s outputs. To account for work that goes over or under the estimated 1 day, Arman includes a 0.5 day delivery buffer to absorb any variability.
Daphne advises the 5 business unit leaders that there will be a temporary freeze on raising new requirements until the backlog is down to 10. She then sets up a weekly prioritisation meeting where each business unit leader can nominate 1 new requirement for Daphne to raise with Arman.
This new process ensures that Arman and his team spend only half their week performing analysis, and the other half actually implementing changes. The existing backlog also ensures that the constraint does not run out of work.
If Arman and his team get ahead or fall behind on their work, Daphne can always make adjustments to the number of new requirements raised during the week.
If we’re to visualise the changes to the process, things may look a lot less busy, but that’s because the traffic pile-up has been cleared and work is now flowing at an even pace! And most importantly, less work in process = more work actually being completed.
Technology delivery is not about doing the most work (pushing), it’s about doing the right work (pulling).
In order for your pipeline to deliver value, it must work to the beat of its constraint. Drum Buffer Rope is a simple but versatile tool for doing just this. You may not always be able to break a constraint, but that doesn’t leave you powerless to optimise its performance!
So put an end to the chaotic drum solo, and start working to some smooth, soulful house beats in 4/4 time!