Today's publication on Drum Buffer Rope (DBR) Kanban boards is a first. A first like "world premiere" first. A few weeks ago, I made my first DBR Kanban boards for academic purposes. The experience was quite enlightening and when I discussed it with Steve Tendon, creator of TameFlow Kanban, we were pleased with the result.
I pointed out that we had gone through a quantum leap: getting to the end result without covering the space between a traditional Kanban board and a DBR Kanban board. So together, we undertook a simple recipe to do the "mutation" so that you can reap the benefits of TameFlow.
Before forging ahead any further, Drum Buffer Rope Kanban boards have been used intensively by Steve Tendon and his teams over the last 7 years and are very popular in the Netherlands.
For Steve, the driver for a DBR Kanban board is to provide the necessary mental model to constantly have flow efficiency in mind: a paradigm that really belongs to FLOW TIME (touch time & wait time).
We must remember that flow efficiency deals with the tough times and the wait times while in the process FLOW TIME. Wait times spent outside the process's FLOW TIME, which is Queue Time or Delivery Time, are often wrongly included in Flow efficiency calculations. This is where Steve and I came to a halt in our discussions to clarify things. I fetched this very popular illustration just below from his book TameFlow Kanban to pursue the conversation.
Figure 1 - Steve Tendon - The TameFlow Times
We commonly see many variations for Flow efficiency measurement and no traditional Kanban boards really visually support motivation towards reaching more actionable Flow efficiency metrics. That is until now with the first public edition of a DBR Kanban board.
Flow efficiency is obviously concerned with effort. Service Time is not the proper denominator if you think this through. Nor is Lead Time. FLOW TIME in the process is the more accurate denominator in terms of mastery of the topic.
(A note on terminology: in TameFlow we use FLOW TIME for what is often referred to as Cycle Time.)
As a CPA and IT Professional for 40 years now, I have positive affective pre-dispositions to fight coordination costs. Do I need to remind you that, generally speaking, the higher your Flow efficiency, the lower your coordination costs! That's one managerial incentive for adopting Drum Buffer Rope Kanban boards today if you ask me.
Transforming a Kanban Board to a DBR Board
Let's come back to a traditional Kanban board for a minute.
The next topic deals with column buffers in traditional Kanban that have no design provisions in TameFlow boards. Traditional Kanban boards have at least five reasons that justify column buffers for wait time:
- Options from Upstream
- Releases (storing in front of a big batch)
- Done buffers
- Capacity Constrained Resource (CCR) bottlenecks
- Non-Instant Availability (NIA) bottlenecks
A Drum Buffer Rope Kanban board can do without those "Ready" columns.
DBR Kanban boards from TameFlow are to be viewed as uninterrupted and stable flow boards. In contrast to the traditional Kanban boards, they have psychological triggers embedded. Adding or removing column buffers is a form of tampering (so is adding or removing swim lanes in a throughput Kanban centric world). TameFlow is as much technique, practice, and metrics as it is psychology, mindset, and attitude.
So, if you have a problem, you need to fix it. This is one reason that "Full Kitting" exists as a column at the beginning of the flow on a DBR Kanban board. You have to know your process and how to get things done.
Full Kitting is more powerful than "Ready". Ready typically means ready for the next immediate step (column). Full Kitting means that everything that is needed for the whole journey to "Done" is known/available or made available JIT when needed. Better keep things waiting "out of process" which leaves options open like Chris Matts would paraphrase in his book "Commitment"!
Granted, the challenge remains the same and these wait times inside FLOW TIME have by no way disappeared. And make no mistake, such wait times make for a good chunk of knowledge work!
The difference is in TameFlow's psychological flow and how we visibly manage problems and issues while they are in a TOUCH TIME state in the "In Process" columns.
TameFlow, in this context, has more affinity with Daniel Vacanti's approach to actively manage "wait times". In this unique throughput paradigm, we use his "Cumulative WIP aging charts". Not paying attention to WIP aging in the process steps will severely skew your Lead Time data.
In daily stand up meetings, aging signals should always drive your focus: the reddest item from an aging perspective makes sense to act upon. It is most likely the one impacted most by wait times.
Choosing the work by taking into account an item's cumulative WIP aging in a high throughput environment will always produce better Lead Time data than any other pull policy.
One will notice that Daniel Vacanti does not use column buffers to distinguish wait times. He does, however, have the provisions to visualize the WIP aging hotspot in both the "Waiting for..." and "In Process" columns!
Figure 2 - Eliminate Buffers from Traditional Kanban board
Once the buffers have been removed, the next step is more of a distinction. No design changes needed from the illustration below:
Figure 3 - Bottlenecks and Constraints
Traditional Kanban boards identify bottlenecks in the workFLOW visually as highlighted in the red area, to trigger a reaction from the team.
Bottleneck management is linked to special cause variation. It is useful. This approach was taken from Lean manufacturing, where you would pull the "andon" cord when a problem made itself visible.
The red and green numbers appearing in boxes at the bottom show you the constraint in the work PROCESS. This is a constraint management paradigm linked to Daniel Vacanti. It is more in line with the Theory of Constraints.
In figure 3, the constraint is revealed by the highest average in-state flow time observed in the flow. It is the Herbie. It is important to know where Herbie is. In this case, UAT is our Herbie.
Now we are at a critical transformation point. We need a board that will accurately reflect Flow efficiency and motivate us toward reaching that goal. Simplicity, robustness of design, and linearity are of paramount importance to a Drum Buffer Rope Kanban board as illustrated below:
Figure 4 - DBR Lead Time Kanban board with Columns WIP Limits
The reader will notice that the two required states for calculating Flow efficiency are explicit within the process: WAIT TIME & TOUCH TIME. It better focuses the mindset and attitude of a knowledge worker towards Flow. This allows to properly treat Flow efficiency with regards to costs since we are actively instrumenting the board to measure and reduce WAIT TIME states.
- When items are inside the FLOW TIME, the wait time is wait time. What matters is execution. Getting the work done.
- With the traditional "Done" buffer, the reaction is: "Oh good... I have more stuff coming my way... I don't have to worry to appear idle doing nothing waiting for work" (cost accounting mindset lurking there).
- With the "Waiting for ..." column right before you, the reflexes are otherwise: "Damn! I need to get my stuff done ASAP, so I can take care of the next thing ASAP".
- It is a mindset. Wait time is always wait time. But what do you (and everybody in the organization) understand wait time to be? An asset or a liability?
- In the cost accounting world wait time means resource efficiency. It is an inventory that is valued.
- In the throughput accounting world, wait time is less throughput. It is inventory piling up and that is a burden.
Back to the mechanics and more on the transformation steps from figure 3 to figure 4:
- The "Ready" column at the beginning is renamed "Full Kitting" meaning that in order to optimize Flow efficiency all the required information is encapsulated before commencing work. This way, you get to the end with minimal occurrences of wait times. (Ready is just fine as well as long as it has a sturdy definition of Ready: one that will take you to the end of your journey, and not only through the first column!)
- There are no technical or psychological benefits to maintaining "buffer/ready" columns, or any type of "dampening" columns for that matter, as the time spent there has deep psychological impacts on the way a knowledge worker goes about his/her work. Get rid of those!
- Every traditional Kanban "In Progress" queue needs to be labeled "Waiting for..." and each corresponding "Done" buffer must be renamed "In Process". It is a significant enhancement, especially at the psychological level to get better Flow efficiency metrics. In TameFlow, Steve Tendon chose not to use an "In Progress" column as something might very well be "In Process" but not making any progress at all! (Yes, the items in the old "In Progress" queue need to move to the new "In Process" column. The items in the old "Done" buffer need to migrate to the next process under the "Waiting for..." column.)
- The popular traditional Kanban boards with 'Done' semi-columns do not allow for flowbacks. With DBR boards, work is in Process until it leaves the system!
- All Kanban queues (Dev-UAT-Demo) have a "Waiting for..." column as an entry step at the beginning. It is a bit of:
1) a psychological stressor as the "In Process" folks do not want to be the ones having the system come to a halt (I don't want to be Herbie) and;
2) a place where WAIT STATE metrics for flow efficiency can be tallied up and measured more precisely.
Note: There is no dishonor in becoming the Herbie, it cannot be avoided. But remain assured that the team is always there to support Herbie.
- A Drum Buffer Rope Kanban board is architected to be better at Flow efficiency measurement by capturing proper "Waiting for..." times. The "In Process" columns are exclusively suited to measure TOUCH TIME while in FLOW TIME. It motivates you to stop starting and start finishing knowing full well that the less WIP you have in the "In Process" column, the better touch time statistics you will end up getting! Wait times in TOUCH TIME state exist and have to be minimized. The Cumulative WIP aging is the best way to spot those items.
- Flowbacks: Preferably, you should never do flowbacks. But the DBR Kanban board design helps manage flowbacks. Companies do flowbacks, especially at the start. Traditional Kanban boards with the "Done" column sort of disabled this eventuality. How can you send back something to a previous "Done" state? Doing this may seem trivial, but you are, in fact distorting flow metrics! The problem with the traditional Kanban board layout and the intermediary "Done" columns after a working state is that you send work back to where? Then... try again... send the work back to an effective working column. That works correctly only if the work item has the top priority, which very seldom happens with flowbacks. So, you end up putting the item in a working column while the item is really waiting for the worker. The flow metrics are distorted. You are recording it as touch time (if you are recording wait/touch times at all), while in reality, it is waiting time. Flow efficiency figures will appear much better than what they really are.
- If the upstream ("to the left") resource you are requiring to work for a flowback is not available, you must leave the ticket where it is. When an item gets stuck because it requires upstream resource (or other resources), then all of those resources should "swarm" onto the item if they are free, while the item remains in the column where it was stuck. We want items to leave ASAP.
So here we are at a point where you have a DBR LEAD TIME KANBAN BOARD design. Use it, enjoy it. Agile Project managers in the Netherlands love it.
Operating a DBR Throughput Board
Now before you can operate a Drum Buffer Rope Throughput Kanban board, two more transformations and one small adjustment are warranted as shown in the image below.
Figure 5 - Drum Buffer Rope Throughput Kanban Board
The small adjustment requires to do away with sub-columns for each state. The "Waiting for..." columns are not sub-columns. The same applies for the 'In Process" columns. The motivation here is to eventually calculate flow time at the most atomic level possible.
Finally, we merge the column WIP limits of the FLOW TIME processes in what resembles a CONWIP system. Although it looks that way, it is not for two reasons:
1) CONWIP systems only have one kind of token, we have 2;
2) CONWIP systems do not accommodate classes of service, DBR Kanban boards do.
If you are like me, you would have picked up instantly that these tokens would be more in line with Patrick Steyaert's system that we find in his Customer Kanban work.
Most of you must now be in worry mode and ask: "How do I redesign the process for flow efficiency?" The answer is quite simple and in line with Goldratt's TOC: If one part of the system is "slower", find the Herbie and adjust accordingly with the 5FS!
We are not quite finished and just one step away from the full-fledged Drum Buffer Rope Throughput Kanban board.
The last transformation and design steps are to make sure that the constraint is kept busy. In this case, we allocate a feeding buffer sized to 3 in front of UAT. This is not a WIP limit; to the opposite, it is there to have a minimum (not a maximum) number of items always ready for Herbie.
We don't want Herbie to stop. Never. Because if Herbie stops, the whole process suffers. If we get less than three items here, then we need to worry. Having three Kanban tokens is a green status, two yellow and one red. Pretty simple stuff to visualize and let's have it drawn right this moment:
Figure 6 - Drum Buffer Rope Kanban board with Explicit Constraint Buffer
So, we finally have our DBR Throughput Kanban board with all its components! The UAT constraint is fully visible and must be kept busy.
There are 2 kinds of tokens on a Drum Buffer Rope Throughput Kanban board:
- Kanban Tokens:
1) Upstream of the constraint to keep the system busy. They are attached to an item which is a Replenishment token.
2) Downstream of the constraint to keep the system busy, but without the Replenishment token which has been returned to the front of the board to signal that the constraint is hungry for work. Once an item is done and out of the system, the Kanban token is detached from the item and returned to the entry pool.
- Replenishment Tokens:
To keep the constraint busy. This is the replenishment pull rule: a new item may be released into the workflow only if there is a free Kanban token AND a free Replenishment token that can be attached to it. (A Replenishment token alone is not sufficient to allow for a new card to be released in the system.) Once consumed by the constraint, the replenishment token returns to the corresponding pool of the DBR board.
In our system, we have a WIP of 13 tokens. There are always as many Kanban tokens as there are Replenishment tokens.
These Kanban tokens act as flow enablers. We hear nowadays that the next wave is flow: "Flow where you can, Pull where you can't". Drum Buffer Rope Kanban boards meet this constraint by design as opposed to traditional Kanban boards where pulling is required at all times! Now let's decapsulate the Drum Buffer Rope parts on the board:
- Drum: The drum signals the beat of the constraint. Kanban tokens in front of the UAT constraint make up the Drum component of the DBR board. On the Kanban board on figure 7, there are three Kanban tokens downstream (to the right) of the constraint. Those are the only Kanban tokens that do not impact the beat of the constraint.
Figure 7 - Green, Yellow & Red Constraint Buffer Column
- Buffer: The constraint buffer column signals - in figure 8 above - represent the amounts of work that are put right in front of the constraint so that it does not starve. In our example, it has been set to three. If it goes below three, yellow or red signals interpretation will determine our course of actions. Buffer signals are key in identifying Upstream issues that can impact the constraint.
- Rope: The rope is the WIP limit, the capacity put onto the constrained Kanban system. In our example, it is set to 13 as depicted in figure 7 with the label on the first line "IN PROCESS (WIP =13)". It prevents the system from going out of control with too much work to accomplish.
Back to the drawing board! There are always two scenarios for flow concerns: You have either a flow issue upstream or downstream of the constraint. Let's examine the visual clues that a Drum Buffer Rope Throughput Kanban board can offer.
DBR Boards Upstream Issues
Figure 8 - Appearance of UPSTREAM FLOW ISSUE AT CONSTRAINT BUFFER
Figure 9 - Materialisation of UPSTREAM FLOW ISSUE AT CONSTRAINT BUFFER
The status of the UAT constraint buffer column is the only signal you need in order to interpret Upstream issues. Both scenarios are well illustrated in figures 9 and 10. The issue in this context is linked to the buffer having less than three items in store to keep the constraint busy.
DBR Kanban Boards Downstream Issues
Figure 10 - Materialisation of UPSTREAM REPLENISHMENT ISSUE
Figure 11 - Materialisation of REPLENISHMENT ISSUE IDENTIFIED DOWNSTREAM
To conclude, it is really not that difficult to transform a traditional Kanban board into a flow efficiency centric Drum Buffer Rope Throughput Kanban board. The benefits of motivation, alignment, and flow efficiency metrics are undeniable.
Psychologically, the "Waiting for..." and "In Process" columns are in line with Goldratt's DBR as you don't want to be the Herbie! Again, in TameFlow, there is no dishonor in being the Herbie: TameFlow has a Community of Trust pattern regrouping many Kanban values and the entire organization will support Herbie and you! Always help Herbie, never blame him.
One last word of advice: Drum Buffer Rope Throughput Kanban boards must be used where it makes sense!
The concept is that if you have multiple teams/ multiple projects/ multiple streams, then typically one team is the constraint of the overall process. For that team, it makes sense to use a DBR Throughput Kanban board. The pull signals of the Herbie in the board will propagate to the source, even if there are multiple teams in between. Other teams can use the DBR Lead Time Kanban boards.
Daniel has been involved in IT since 1981 in a wide range of roles and responsibilities primarily in client-facing consulting projects. Daniel's involvement with Agile started with Scrum in 2005 and, more recently with Kanban and Management 3.0. Daniel is heavily involved with Steve Tendon's Tameflow method. Read more articles by Daniel at http://agileagonist.com/