IMG_1249

As I began to summarize my Re-Read notes from Chapters 25 and 26, I was struck by a conversion I participated in at the QAI Quest Conference in Atlanta this week (I spoke on scaling Agile testing using the TMMi, but that is a topic for another column). A gentleman at my lunch table expressed his frustration because his testing team could not keep up with all of the work generated by the development team his group served. They read that for every ten developers there should be two testers, and his company had been struggling with balancing the flow of work between testing and development for a longtime. It was not working. I asked what happened when they were being asked to do more work that they had capacity to deliver. The answer was that it sometimes depended on who was yelling at them. The tactics they used included expediting work, letting some work sit around until it became critical or just cutting the amount of planned testing. He capped the conversation by evoking the old adage; “the squeaky wheel gets the grease.” My lunch companion had reverted to expediting work through a bottleneck much in the same way suggested by Alex (and rejected by Johan) in today’s Re-Read Saturday installment.

Part 1       Part 2       Part 3      Part 4      Part 5      Part 6      Part 7      Part 8    Part 9

Chapter 25. In Chapter 24 Alex and his team suddenly found that 30 parts of their product have become constraints. As Chapter 25 beings, Johan arrives. After being briefed on the problem and the data, Johan suggests that Alex and his leadership team go back out into the plant to SEE what is really happening. The milling machine has become a problem area. Red tag items, priority items that to need ready for NCX-10 and heat treat bottlenecks, are being built to the exclusion of green tag (non-priority parts). Two things have occurred, excess red tag inventory has built up and now overall products can’t be assembled because green tag parts are missing. Johan points out the red card/green card process and running all steps at 100% capacity have created the problem. Remember, by definition non-bottleneck steps or processes have more capacity than is needed and when the non-bottleneck process is run consistently at 100% capacity it produce more output than the overall process needs. Bottlenecks as we have noted earlier define the capacity of the overall process. When output of any step outstrips what the bottleneck excess inventory is generated.  In this case, since everyone has been told to build red card items first they have less time to create non-bottleneck parts therefore inventory is being build up for parts that are not currently needed to the exclusion of the parts needed.  A mechanism is needed to signal when parts should start to flow through process so they will arrive at assemble when they are needed.

Alex and his team discover two rules:

  1. The level of capacity utilization of a non-bottleneck step is not determined by its own potential capacity, but some other constraint. Said differently, non-bottlenecked steps should only be used to the capacity required to support the bottleneck steps and to the level customers want the output of the process.
  2. Activation of a resource (just turning a resource on or off) and utilization of a resource (making use of a resource in a way that moves the system closer to the goal) are not synonymous. Restated, work that does not support attaining the goals of the system generates excess inventory and waste.

Returning briefly to my lunch conversation at QAI Quest, my new chum noted that recently one small project had to wait so long to be tested that the business changed their mind, meaning that six months of coding had to backed out. Which is one reasons that work-in-progress increases waste even in software development.

One the great lines in Chapter 26 is, “a system of local optimums is not optimum at all.” Everyone working at full capacity rarely generates the maximum product flow through the overall process.

Side Note: At the beginning of the chapter Alex and his team had the data that indicated that a problem existed. Until they all went to the floor as a whole team and VISUALIZED the work the problem was difficult to understand. Both Agile and Kanban use visualization as a tool to develop an understanding of how raw material turn into shippable product.

Chapter 26. Alex sits at his kitchen table thinking about the solution to the new dilemma of making sure the right parts flow through the system when they are needed without building up as inventory. Parts should only be worked on when they can continuously move through the process without stopping. This means each step needs to be coordinated, and if the full capacity of a step is not needed it should not be run. This means people might not be busy at all times. Sharon and David (Alex’s children) express interest in helping solve the problem. Using the metaphor of the Boy Scout hike David and Alex participated on earlier in the book, both children try to find a solution of pace and synchronization. Sharon suggests using a drummer to provide a coordinated pace. In Agile we would call the concept of a drummer: cadence. Cadence provides a beat that Agile teams use to pace their delivery of product. David suggests tying a rope to each part flowing through the process. Parts would move at a precise rate, if any step speeds up the rope provides resistance which is a signal to slow down and if slack occurs it is a signal to speed up in orders to keep the pace. Parts arrive at the end of the system when they are needed in a coordinated fashion. In Kanban we would recognize this concept as work being pulled thought the process rather than being pushed.

When back at the plant, Ralph (the computer guy) announces he can calculate the release rate needed for the red tag parts to flow smoothly through the process.  This would mean only the parts that will needed for orders being worked on would be created. No excess inventory would be created at any step including the bottlenecks.  Johan points out that Ralph can also use the same data to calculate the release rates for needed for the green tag items. Ralph thinks it will take him a long time to get both right. Alex tells them to begin even though it won’t be perfect and that they can tune the process as they get data. Do not let analysis paralysis keep you from getting started.

The chapter ends with Donavan (OPS) and Alex recognizing that their corporate efficiency reporting (they report efficiency of steps not the whole system) aren’t going to look great.  Even though they will be completing and shipping more finished product the corporate measures have not been syncronized to the new way the plant is working. The reduction in efficiency (cost per part – see installments one and two)  is going to attract Alex’s boss, Bill Peach’s attention.

Summary of The Goal so far:

Chapters 1 through 3 actively present the reader with a burning platform. The plant and division are failing. Alex Rogo has actively pursued increased efficiency and automation to generate cost reductions, however performance is falling even further behind and fear has become central feature in the corporate culture.

Chapters 4 through 6 shift the focus from steps in the process to the process as a whole. Chapters 4 – 6 move us down the path of identifying the ultimate goal of the organization (in this book). The goal is making money and embracing the big picture of systems thinking. In this section, the authors point out that we are often caught up with pursuing interim goals, such as quality, efficiency or even employment, to the exclusion of the of the ultimate goal. We are reminded by the burning platform identified in the first few pages of the book, the impending closure of the plant and perhaps the division, which in the long run an organization must make progress towards their ultimate goal, or they won’t exist.

Chapters 7 through 9 show Alex’s commitment to change, seeks more precise advice from Johan, brings his closest reports into the discussion and begins a dialog with his wife (remember this is a novel). In this section of the book the concept “that you get what you measure” is addressed. In this section of the book, we see measures of efficiency being used at the level of part production, but not at the level of whole orders or even sales. We discover the corollary to the adage ‘you get what you measure’ is that if you measure the wrong thing …you get the wrong thing. We begin to see Alex’s urgency and commitment to make a change.

Chapters 10 through 12 mark a turning point in the book. Alex has embraced a more systems view of the plant and that the measures that have been used to date are more focused on optimizing parts of the process to the detriment to overall goal of the plant.  What has not fallen into place is how to take that new knowledge and change how the plant works. The introduction of the concepts of dependent events and statistical variation begin the shift the conceptual understanding of what measure towards how the management team can actually use that information.

Chapters 13 through 16 drive home the point that dependent events and statistical variation impact the performance of the overall system. In order for the overall process to be more effective you have to understand the capability and capacity of each step and then take a systems view. These chapters establish the concepts of bottlenecks and constraints without directly naming them and that focusing on local optimums causes more trouble than benefit.

Chapters 17 through 18 introduces the concept of bottlenecked resources. The affect of the combination dependent events and statistical variability through bottlenecked resources makes delivery unpredictable and substantially more costly. The variability in flow through the process exposes bottlenecks that limit our ability to catch up, making projects and products late or worse generating technical debt when corners are cut in order to make the date or budget.

Chapters 19 through 20 begins with Johan coaching Alex’s team to help them to identify a pallet of possible solutions. They discover that every time the capacity of a bottleneck is increased more product can be shipped.  Changing the capacity of a bottleneck includes reducing down time and the amount of waste the process generates. The impact of a bottleneck is not the cost of individual part, but the cost of the whole product that cannot be shipped. Instead of waiting to make all of the changes Alex and his team implement changes incrementally rather than waiting until they can deliver all of the changes.

Chapters 21 through 22 are a short primer on change management. Just telling people to do something different does not generate support. Significant change requires transparency, communication and involvement. One of Deming’s 14 Principles is constancy of purpose. Alex and his team engage the workforce though a wide range of communication tools and while staying focused on implementing the changes needed to stay in business.

Chapters 23 through 24 introduce the idea of involving the people doing the work in defining the solutions to work problems and finding opportunities. In Agile we use retrospectives to involve and capture the team’s ideas on process and personnel improvements. We also find that fixing one problem without an overall understanding of the whole system can cause problems to pop up elsewhere.

Note: If you don’t have a copy of the book, buy one.  If you use the link below it will support the Software Process and Measurement blog and podcast. Dead Tree Version or Kindle Version