Having read both the Phoenix Project and The Dev Ops Handbook, both which heavily reference The Goal, I felt that I had to read the book that was the inspiration.

The Goal — Eliyahu M. Goldratt

The Goal is a fictional account of how a manager of a manufacturing plant turns his business around, saving the plant and division from closure. There are key lessons in the story, which the novelization help the reader consume.

The author uses the Socratic method to get his ideas across, asking questions of the protagonist, helping him to come up with the correct answers himself.

The guide throughout the novel is a slightly remote character called Jonah, who’s jet setting lifestyle, presumably as a consultant, makes him difficult to track down. We are always left wanting more from rushed encounters with him.

The Goal of the plant, as the protagonist learns, is to make money. This seemingly obvious concept is shrouded in different established measurements, such as those that measure local work station efficiency, and which mask the fact that they do not contribute to the bottom line.

Jonah uses three simple measurements to assess whether the business is in a good state when told about the installation of some new robots to help plant efficiency.

Has the overall sales increased? Has inventory dropped? Have costs gone down?

When the answer is no to all three, he perceives that the plant has not seen any improvement, and may even be in a perilous state. When the protagonist figures this out for himself, he decides to track Jonah down. Thus begins his journey of discovery.

Like The Phoenix Project, the lessons we learn seem obvious once they are spelled out, but are also difficult to act on. Here are a few of the ideas that I took away.

Don’t try to do too much at once

I used to think that employees should be fully utilised, and that there should not be any slack time allowed. Yet we constantly missed cut-offs and deadlines. Things take longer in general than we estimate.

By filling up the schedule completely, there is no time to handle unexpected outages; there is no room for manoeuvre. If we keep the team at ninety percent utilisation or above, there will be delays and cycle time goes up.

What is a good amount of time? It depends. There is a correlation between the amount of Work In Process (WIP) and the cycle time. How much work does a Scrum team have on its plate compared to how fast the changes can be released into production.

We have had some success recently by not overpopulating the sprint with too much work, leaving some slack time. Developers sometimes ask “What will I do when we run out of work?”. My answer has been to take the spare time to do some on-line training, but in reality, unplanned work always shows up.

We have been able to use this to complete sprint goals for a few sprints in a row, although the pressure this time of year, when the team are taking holidays, means little will get completed over the next two week sprint.

Keep inventory low

A Dev Ops principle that is often extolled is that changes are released quickly to production, using automation, both for testing and deployment, to speed up the process.

As a means in itself, the benefits appear quite obvious. By quickly reacting to market movements, a company can gain a competitive edge by being able to release new features before their competition.

The risk of making a wrong move in the marketplace is mitigated by being able to quickly course correct and fix things. The short turnaround time is key here.

The benefits go further, however, as pointed out in The Goal. Having work Done (whatever the definition of done means for your company) has no value until it is released to production, and users or clients can start using it. In fact, it costs you every day that it sits in a test or pre-production environment, taking time from developers or operators to make sure it does not drift from production.

When making the case for test automation and continuous delivery, do we emphasise the cost of keeping code, (inventory) lying around? Our monthly release cycle, although a lot more regular than what it was in the past, means that change sits waiting for release for up to six weeks. Too long. How long can we ignore the cost of this inventory?

Focus on adding value

It can be hard to focus on what to improve. As shown in The Goal, the changes required can seem counter intuitive until you see them in action and as Goldratt points out, we often desire to fix the problems that we know how to fix, rather than face the problem that is hardest, but will give the biggest return on investment.

Doing Agile or Dev Ops just for the sake of it within the software industry and because it is the buzz at the moment seems foolish.

Agile works by helping to highlight what is causing pain, not by removing the pain. Getting to the Dev Ops Nirvana is only possible by removing those sources of pain using all the skill sets required to release software.

Give yourself space

The main character in The Goal makes his first breakthrough by stepping away from the job. He goes missing for an afternoon, endangering his job and relationship with his wife in the process.

This action creates a breakthrough in the story. The character overcomes the inertia of inaction, or of taking action that has little effect on making the business succeed.

It’s probably not good advice for any everyone with management responsibility to go missing for an afternoon, however, giving yourself space to think beyond the day to day slog is important, whether it is fire fighting production issues, or simply trying to keep up with the demands that the business places on IT.

This goes beyond creating space to pay down technical debt, which should be mandatory for every IT team. It means taking time to consider what the effect on the bottom line for the company is and if a measurement is missing, to figure out a way of getting it.

Conclusion

If you enjoyed reading either The Phoenix Project or The Dev Ops Handbook, then The Goal is definitely worth reading or listening to. I used the Audible version, which dramatises the parts of the various characters.

The fact that what seem to be sensible cost-saving actions, such as optimising for local efficiency, can actually be counter productive to the goal of the organisation is an eye opener.

Dev Ops takes a more overall view of IT delivery. If there is a bottleneck, a constraint, somewhere along then producing more code change will not make the company money. Identifying and utilising the constraint is a key.

There are still lessons to be learned from The Goal for everyone in IT, or any business. I plan to go back and re-read The Dev Ops Handbook. It will be interesting to read knowing more about the origin.