The Goal: A Process of Ongoing Improvement

(link) by Eliyahu M. Goldratt & Jeff Cox

I try to choose books that I see often or hear about from reliable sources. One of the books that I try to read yearly is the Phoenix Project which mentions it as a source. I heard about it in some videos that I watched about Lean Agile for software. It often shows up on lists of “To Read Agile” books.

This book will go on my list of books to re-read yearly. The concepts in it will mean different things each time it is read as things around us change.

We’re a team. And the team does not arrive in camp until all of us arrive in camp.

STEP 1. Identify the system’s bottlenecks. (After all it wasn’t too difficult to identify the oven and the NCX10 as the bottlenecks of the plant.) STEP 2. Decide how to exploit the bottlenecks. (That was fun. Realizing that those machines should not take a lunch break, etc.) STEP 3. Subordinate everything else to the above decision. (Making sure that everything marches to the tune of the constraints. The red and green tags.) STEP 4. Elevate the system’s bottlenecks. (Bringing back the old Zmegma, switching back to old, less “effective” routings. . . .) STEP 5. If, in a previous step, a bottleneck has been broken go back to step 1.

For the ability to answer three simple questions: ‘what to change?’, ‘what to change to?’, and ‘how to cause the change?’

More importantly, our software worked. I don’t just mean that it didn’t bump, or that it performed according to the written specifications, or that it was efficient in producing reports. It really worked.

If the goal is to make money, then (…), an action that moves us toward making money is productive. And an action that takes away from making money is non-productive. For the pat year or more, the plant has been moving away from the goal more than toward it. So to save the plant, I have to make it productive; I have to make the plant make money for UniCo.

A bottleneck is any resource whose capacity is equal to or less than the demand placed upon it. And a non-bottleneck is any resource whose capacity is greater than the demand placed on it.

Balance flow, not capacity.

Don’t give the answers, just ask the questions.

A measurement not clearly defined is worse than useless.

Key Thoughts:

• Making sure there is alignment of the goals of the organization, the goals of the department, and the goals of the team will give us the guide posts needed to know that all decisions move us towards success.
• Having clarity on the questions that we need to answer so that we can make sure that our measurements (KPI’s) are valuable is key. Just measuring data will not tell us if we are moving towards our goals. Finding ways to measure the things that actually matter will give us the information we need to be successful.
• We need to understand the flow of our systems, where bottlenecks (constraints) are and where we can make changes to help things flow better.
• Clearing a constraint allows us to move forward at a steady pace and unblock us for the future. But remember that clearing one constraint will reveal more that were hidden and may even create new ones that didn’t exist before. Looking for them needs to be a constant effort.
• In a manufacturing plant they fulfill orders to make money. In software we keep our systems running and improve them to enable us to sell more to make money. How can we successfully deliver software when the customer orders change. Too often we are asked to do work where the requirements are fuzzy, incomplete, or just not correct. This slows everyone down. How can we clarify our “orders” to make sure they are as accurate as possible before the work begins and will bring us the value that we are looking for.
• How do we determine if our teams have achieved success? When do we consider them to be “efficient”? What would we do then?

• How do we succeed at building software
• The projects need to be valid
• The outcome needs to be clear
• Things need to flow steadily in and out of engineering
• We need to be able to build software at a steady reliable pace
• When emergencies arise we need to solve them quickly and safely
• Communication is critical

Potential Action Items:

• Find concrete key things that we can measure that will help us to understand our constraints (bottlenecks). Make sure that the measurements align with the goals of the organization and department. Design projects that will help us to clear the constraints and measure concrete progress.
• Assume that you are new at the job you are doing. Answer the question “what is the first thing you should do in your new job.” Then take some time to align what you are doing today with the answer to that question.
• Track each step in the flow of work though our system looking for places where bottle necks may occur. Work on those areas to help find ways to clear them out, make them faster, or work within their limitations.
• Make sure that the Teams understand “why” we are doing the project. Not just the product changes but truly understand the business value that it will bring.
• Spend some time learning about the Socratic approach.
• While discussing this book with others in an online Reading group the book “Accelerate” was suggested as a good follow-up.

Book Summary – The Goal: A Process of Ongoing Improvement