Book cover: Tame your Work Flow

Tame your Work Flow

This week we tackle two chapters in Steve Tendon and Daniel Doiron’s  Tame your Work Flow. Chapters ten and eleven put our understanding of workflow and process-flow into action in more complex environments. I have been dealing with pests all week; a swarm of yellow jackets made my garden their home. It is a complex and potentially painful situation, but not nearly as difficult as dealing with the common organizational failings. Chapter 9 introduced the concept of dealing with the chaos that can be found in most organizations using the acronym PEST, which stands for scenarios that have: 

  • multiple Projects or Products, 
  • multiple Events (or deadlines), 
  • multiple Stakeholders, and 
  • multiple Teams.

I mentioned last week that the acronym PEST evoked strong feelings. Daniel pointed out that some early reviewers had the same reaction. I think the reaction to the acronym is actually important because it causes the reader to reflect on how to minimize the negative impact of these factors. Chapter 10 walks the reader through three runs of a simulation that highlights how common organizational behaviors generate lots of noise. Noise represents behaviors such as jumping the queue, maximizing personal goals over organizational goals, and the general friction caused by lots of moving parts.  (Note – those of you that are reading along, I recommend downloading the simulation/game, in the books bonus material, used in this chapter).

The three runs of the simulation start with a fairly simple scenario and evolve to something that is only fairly chaotic.  The three are:

  • One product owner and one project, 
  • Two product owners and two projects, and 
  • Three product owners and ten projects.

Two of the overall goals of the simulation is to understand how to find the constraint despite the noise and to show that the type of work a team takes can cause the constraint to shift around.  

Work entry has long been one of the weak spots in most project-based organizations (and one of my pet peeves). Most guardians of work backlogs fall prey to the assumption that saying yes to everything and start work on items in the queue as soon as anyone can get to it will lead to earlier delivery. Daniel and Steve’s simulation demonstrates how this behavior causes a conflict of interest between teams and stakeholders. I recently observed a typical work entry process.  Each stakeholder wanted their work to start before anyone else’s, even when doing something else would have returned more business value. Each stakeholder worked very hard on maximizing their personal performance to maximize chances for promotion and better bonuses – their behavior was very much in line with their organization’s culture. This sounds like poor behavior, but PEST environments make it very easy because of a lack of a common overriding goal.  

Chapter 11 continues with findings from the simulation.  In the simulation, three teams feed work to a single group that puts everything together. Anyone in the software industry won’t have to search their memory too hard to picture a workflow that looks similar. In this circumstance, the natural tendency is to jump to the conclusion that the integration step is the constraint because it is easy to see the work piled up in front of the team. However, as soon as there is contention for the attention of one of the three groups feeding teams (frontend teams) and product owners start to jump the queue and push their work to seemingly free units, things change. The type of work required (the authors call this the shape of work) dramatically impacts throughput, causing work to pile up in front of a team (an indication that they are the constraint). I recently observed a group within a team of teams become the constraint when they were ‘voluntold’ to take the work for several new and not well-understood microservices in front of the work they had committed to doing. The problem was exacerbated because all of the work queues is not observable as a whole. The workload was obscured as a byproduct of the tool they were using. Here’s a simple rule: the type of work and the workload directly impacts how work flows through the system. If you can’t see the queues and flow of work through the entire system the outcome of any analysis or process improvement will be less than useful.

I put “Begin your analysis by building an overall understanding of workflow, and use that understanding to find the constraint in the process flow” on my whiteboard after re-reading these two chapters. 

Remember to buy a copy of Tame your Work Flow 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