This week we begin Part 2 of Daniel Doiron and Steve Tendon’s Tame your Work Flow. Part 2 transitions us from improving wait time and flow efficiency and begins a deep dive into the Theory of Constraints (ToC). The authors use the metaphor of an Archimedean lever to point out that in order to make major changes you need a fixed point or fulcrum and a big lever. In process improvement, the constraint is that point where a lever can be inserted to make change happen. The problem in knowledge work is that it is hard to identify the constraint.
Chapter 5, Where to Focus Improvement Efforts has several important definitions. For example, the definitions of constraint and bottleneck. For the longest time, I struggled with the difference between the two. Several years ago Steve Tendon set me right during a conversation on the Software Process and Measurement Cast. I will use a real-life, unfortunate but true, example to illustrate the nuances in concepts in Chapter 5.
The example: I worked with an organization that had a team (many of the teams had problematic structures) that consisted of three business analysts (BAs), one coder, and part of a tester. The team worked on small enhancements and user complaints/bugs. Everybody was pushed to work full blast on things that were in their individual span of control (BAs writing requirements, coders coding, and testers testing) and then throw it over the wall to the next person in the process. The BAs were always piling work on the coder and the coder was always tossing more work on the tester that was addressable.
It was decided that fixing the organization structure by repurposing a BA as a tester would cause too much upheaval. In the book, Daniel and Steve point out that “Changing the way work is performed (acting on Touch Time) is always an expensive proposition and has a huge risk of failure.” It was easier to begin to build trust in changing the process by driving out wait time. As we noted in Chapter 4, reducing wait time is cheap and has a very low risk. While flow efficiency improved, work still piled up in front of the coder and the tester.
The flow had two bottlenecks. The authors define a bottleneck as “any kind of resource that cannot deliver up to the demand that is placed on it.” Coder and tester in this circumstance. The push to go full blast and only focus on your specialty ensured that no one did much to help anyone else out. Once we had improved wait time and built some trust that change was not a dirty word, work restructuring finally became an option. The issue was that we would only have one shot if things went wrong. Finding the constraint was critical.
The operational definition of a constraint in the book that I find most useful is that the constraint is the bottleneck (out of possibly many) that has the least Capacity or longest Flow Time. In our example, the part-time tester was the constraint but was nowhere near the problem we expected. Never trust your gut, we gathered data and built a mathematical model that showed that once we solved the testing backlog coding would quickly become the backlog. Daniel and Steve offer a visual approach in the text of the book that builds on cumulative flow diagrams that I wish I had when we were making presentations on the changes we were going to make. In the end, instead of having a BA move to testing, the team traded a BA for a person that could code and build automated testing tools. The change smoothed out the flow of enhancements and bugs which improved customer satisfaction.
Chapter 5 drives the point home that all constraints are bottlenecks but not all bottlenecks are constraints. Just be aware, when you fix the constraint, another will pop up. All processes have a constraint. There are all sorts of types of constraints, some that are within the span of control of the process and some that aren’t. For example, management constraints rob change teams of the capacity to make change happen. Unless you identify the constraint, exploit it, and then improve it will you not be able to deliver improvements.
Remember to buy a copy of Tame your Work Flow to support the authors and blog!
Week 1: Logistics and Front Matter – https://bit.ly/2LWJ3EY
Week 2: Prologue (The Story of Herbie) – https://bit.ly/3h4zmTi
Week 3: Explicit Mental Models – https://bit.ly/2UJUZyN
Week 4: Flow Efficiency, Little’s Law and Economic Impact – https://bit.ly/2VrIhoL
Week 5: Flawed Mental Models – https://bit.ly/3eqj70m
