The Goal, A Process of Ongoing Improvement, by Eli Goldratt is a business novel that introduced the Theory of Constraints.

Being a novel means that this theory is presented almost casually as a story. We follow Alex Rogo, a plant manager. His plant is in trouble. Big trouble. Alex finds out that it will be closed in three months if things don’t improve. Alex runs into his old physics teacher, Jonah, who starts helping him. Not by telling Alex what to do, but by asking questions. Questions that can only be answered by challenging fundamental assumptions about running the plant. By letting go of these false assumptions, Alex finds ways to dramatically improve his plant’s operations. Not only is the plant not closed down, Alex gets to run the entire division.

I don’t read much fiction. I have too little time as it is to read all the non-fiction that I want. So why did I read this book? Well, the story I outlined above isn’t what this book is about at all. This book tries to teach us to not lose track of the real goal, i.e. making money in the case of an enterprise. We make more money by

1. Increasing throughput
2. Decreasing inventory
3. Decreasing operational expenses

Preferably all of those at the same time.

The primary tool to help us with this is the Theory of Constraints. This is a scientific, i.e. evidence-based, approach to process improvement, based on the assumption that any process is limited by some constraints. To improve the process, you need to follow the 5 focusing steps:

1. Identify the constraint
2. Decide how to exploit the constraint
3. Subordinate all other processes to the above decision
4. Elevate the constraint
5. If, as a result of these steps, the constraint has moved, return to Step 1.

It all starts with identifying the constraint. Visualizing the process helps here, e.g. using a Kanban board. We may need to do some root cause analysis to find the real constraint underlying the symptoms that our visual tool shows.

Exploiting the constraint means making sure that the constraint’s capacity isn’t wasted. For instance, if QA is the constraint in a software development process, then we must make sure they’re not sitting idle. One way of doing that would be to decrease iteration size, which will give QA a more even supply of work. Linking back to the 3 elements that help achieve the goal, we see that this is a way of decreasing inventory (of coded, but untested features).

Exploiting the constraint often requires the use of buffers before the constraint, to make sure it doesn’t run out of things to do. For instance, Scrum assumes the development team is the constraint in the organization, and uses a buffer called a backlog to keep it busy.

Subordinating all processes to the decision to exploit the constraint is not easy. It may mean you need to take counter-intuitive actions, such as keeping non-constraint resources idle. For instance, coding more features is not going to help us make more money if QA can’t keep up with testing. So if QA is using up all its capacity, then no more features should be coded. If the coders have more capacity, they should do something else than coding new features. I’m sure that raises some eyebrows somewhere, but it makes perfect sense when you think about it.

Elevating the constraint means improving the capacity of the constraint. For instance, we could hire more people for QA. Better yet, we could have coders use their idle time to write automated tests, which will prevent defects reaching QA, which means less work for QA per feature, which means more features per unit of time can be tested. We know this is a better solution when we compare the 2 proposals against the 3 ways of reaching our goal: the first proposal increases operational expenses, while the other doesn’t.

The final step embodies the “ongoing” part of process improvement. Once QA finds less bugs because of automated tests, they may stop being the constraint. That is good news, but no reason to sit back and relax. By assumption, something else is now the constraint, so we repeat the whole process for the new constraint.

The 5 step process is quite general. The Goal uses it in the context of a manufacturing plant, but the examples I gave talk about software development. This generic ability makes it a very useful tool, so if you haven’t read the book, I suggest you do. It’s a decent read as a novel as well.