Book cover: Tame your Work Flow

Tame your Work Flow

I find Chapter 14 useful in a book of useful chapters. In this chapter, Steve and Daniel explain the foreshadowed idea of full-kitting and introduce two different versions of kanban boards.

I am a big fan of the idea of the definition of ready. I have written several columns on the topic (for example, Ready to Develop from 2015, in which you will note that my definition is much closer to Steve and Daniel’s concept of full-kitting than some of the austere definitions of ready). It has never made sense to me to start working on a story if you didn’t think you could complete the work. It’s like making a platter of hamburgers for a party if you haven’t bought or even planned to buy the meat. The definition of full-kitting is “everything that is needed for the whole journey to done is known, available, or can be made available just-in-time when required.” This helps to ensure that there is no logistical reason not to complete a work item. I have found this concept to be useful and now is a “must consider“ when pulling any piece of work from my backlog. Full-kitting puts a lot of pressure on getting work prepared before it enters the workflow. This might feel esoteric or like it is a tweak on the idea of the definition of ready, but I have seen examples of teams (including whole Agile Release Trains) working for months on features only to have them warehoused because the overall application was not ready for them. Having your work warehoused is frustrating, not to mention expensive to do work that can’t go forward.

The second major idea in this chapter is the idea of flow-efficiency boards. In this type of board, it splits every column into two half-columns (the authors use the term semi-columns). The first semi-column is “waiting for” and the second is “in-process”. Many standard kanban boards break columns up into doing and done. This difference might seem to be a nuance, but by switching perspectives there are profound implications when finding the constraint in complex scenarios and then refocusing on flow-efficiency. Flow-efficiency is the amount of touch time (time work is happening) divided by the total time in flow. Higher efficiency is generally better. 

A focus on flow and the flow-efficiency boards also answers a question I wrestled with for years. The question is what to do with an item when it goes pear-shaped (a defect is found). A few years ago I would have suggested that the item go back to the process and column that injected the defect and then flow forward. I think it was a reasonable response to flow back as Steve and Daniel call the scenario. It was significantly better than the antipattern of declaring the broken item “done” and then opening a ticket to fix it someday over the rainbow. I have seen this more often than I like. My reading of Daniel Vacanti’s book a few years ago and now Tame your Work Flow has provided me with the information to shape a better answer. The best solution is to swarm to the piece of work where it is and fix it so that it can continue moving forward. This sounds simple but requires all sorts of disciplines most organizations fail to muster. One discipline is the need for simple slack, if everyone is 100% utilized when anything goes wrong a ripple effect will slow everything down. A second required discipline is the discipline of system flow. Ensuring flow needs to be of paramount importance. FYI, just in case you can’t execute the best case solution or flowback, the second-best solution is to send the ticket back to the process and step that injected the defect and put it into the “waiting” column. While this violates flow discipline it at least communicates that the work item is waiting to be addressed.

The second type of kanban board introduced in this chapter is the Drum-Buffer-Rope (DBR) Board. This board also leverages the “waiting for” idea from the flow efficiency board. The goal of the DBR board is to ensure the constraint is never starved. The buffer in front of the constraint needs to have a set amount of work waiting. When the buffer drops below its limit, the system pulls so that it will be ready when needed. Maintaining the right amount of work to ensure the constraint never “starves” (runs out of work) requires understanding how long items need to proceed from work entry to the constraint’s buffer.  I strongly suggest defining the value stream in an organization. Without defining the overall value stream it is easy to see a piece of a process as being the whole, leading to misidentifying the constraint and local optimization. Finding, exploiting, and then optimizing the constraint addresses common cause variance which has a huge payback (because it applies to all cases, not just special scenarios).

Chapter 14 reinforces my belief that flow is important. Full-kitting is a great idea that requires intense thought about what is needed to get a work item to done across the whole value chain. The failure to visualize the whole value chain is the reason that so many teams operate in locally optimized bubbles. Developing this meta-view is one of the often-ignored roles of product owners and managers. Using flow efficiency and DBR boards are a useful evolution on classic kanban boards that make it easier to visualize and exploit the constraint.

Have you bought your copy of  Steve Tendon and Daniel Doiron’s  Tame your Work Flow?  Use the link to support the authors and blog!

Week 1: Logistics and Front Matter –

Week 2: Prologue (The Story of Herbie) –

Week 3: Explicit Mental Models –

Week 4: Flow Efficiency, Little’s Law and Economic Impact –

Week 5: Flawed Mental Models –

Week 6: Where To Focus Improvement Efforts –

Week 7: Introduction to Throughput Accounting and Culture –

Week 8: Accounting F(r)iction and  Show Me the Money –

Week 9: Constraints in the Work Flow and in the Work Process –

Week 10: Understanding PEST Environments and Finding the Constraint in PEST Environments –

Week 11: Drum-Buffer-Rope Scheduling –

Week 12: Portfolio Prioritization and Selection in PEST Environments –