During our discussions about The Phoenix Project at an engineering bookclub at work, one of my colleagues recommended Eliyah Goldratt and Jeff Cox’s book The Goal: A Process of Ongoing Improvement. In The Goal, the didactic novel that inspired The Phoenix Project, Goldratt and Cox explain the Theory of Constraints by telling the story of how a plant manager turns a failing plant into a successful one.

The book’s protagonist, the plant manager Alex, learns about the Theory of Constraints from his old physics professor Jonah who he runs into while waiting at an airport. Jonah asks Alex to identify what his company’s goal is. Although it might seem like the goal is to reduce costs or increase manufacturing efficiency, these measures are not quite right. If a plant automates something, it cannot be called “more productive” unless the plant is actually making more money. Jonah introduces three metrics to monitor productivity:

  1. Throughput: “the rate at which the system generates money through sales”
  2. Inventory: “all the money the system has invested in purchasing things which it intends to sell”
  3. Operational expense: “all the money the system spends in order to turn inventory into throughput”

These measures may differ from their traditional definitions, but they help focus on the business’s real goal—making money. Anything that improves the efficiency of a part of the system without helping the system increase throughput and decrease operational expense is not productive.

Throughout the book, Alex realizes that his team needs to identify the bottlenecks in their production process. Goldratt and Cox define a bottleneck as “any resource whose capacity is equal to or less than the demand placed on it”.

To improve productivity, we need to learn to focus on bottlenecks at the exclusion of non-bottlenecks. Alex and his team come up with five steps for a process that improves productivity by alleviating constraints:

  1. Identify the bottlenecks.
  2. Decide how to exploit the bottlenecks.
  3. Subordinate everything else to the decisions about how to alleviate the constraints and to maximize flow through the constraints.
  4. Evaluate the system’s constraints.
  5. If you have broken a constraint, start the process over. But don’t allow inertia to create a new constraint.

Perhaps these steps sound obvious, but they have serious implications for improving productivity in manufacturing and many other fields. A colleague of mine and I were discussing yesterday what constraints we have in our process, which we loosely defined as taking user stories and turning them into production features. This approach definitely helps us focus on how we can improve our team’s throughput and how we can identify the constraints in the larger software delivery process.