Studying “The Goal” — Chapters 1–4
At SoundCloud, we’ve started a study group where we’ll read books about workflow improvement and management. We’ve decided to start by reading The Goal, at a pace of 4 chapters per week. In this series of posts, I’ll be sharing a selection of study questions for each 4-chapter section which I’ve come up with or cribbed from this list, and my thoughts about them. I hope they’re useful to others studying this book, or thinking about the effectiveness of their workflows.
Why does Alex think the robots are so successful when he first talks to Jonah? How does Jonah indicate that the robots were not successful?
Alex tells Jonah that the robots have led to a thirty-six percent improvement in one area. He measures this improvement in terms of productivity, which he is able to define (vaguely) as “something about the value added per employee equals…” before trailing off.
Jonah indicates that this is not a good measure of productivity in two ways.
First, he asks if the introduction of robots has affected any of three areas: rate of products produced and sold; people expenses; or inventory. If the robots had increased the rate of products produced and sold, they would be producing more revenue. If they had reduced people expenses or inventory, they would be effective at reducing costs. Alex answers that people expenses have not been reduced, products are being produced and sold at the same rate, and inventories have gone up. On this basis, Jonah argues that they haven’t increased productivity.
Later, Jonah changes tack and offers his own definition of productivity: “[e]very action that brings a company closer to its goal is productive. Every action that does not bring a company closer to its goal is not productive.” Alex agrees that this is common sense, but he and Jonah cannot reach agreement about what the goal of Alex’s company is. Nonetheless, Alex cannot claim under this definition of productivity that the robots are productive, since he does not know what the goal is.
Leaving aside the question of what “the goal” is, we can see that Jonah has had a powerful insight. Alex has invested in robots and made one department more efficient. But he has not made his plant more efficient. In fact, the introduction of robots has increased his inventory costs and hence made his plant less productive. The lesson here is: making an individual department more efficient does not necessarily increase the efficiency of the whole system. In systems like a manufacturing plant, where inventory/work in progress carries costs, making the wrong department more efficient can make the whole system less efficient.
Is Donovan right to celebrate shipping order 41427? Why can’t every order work that way?
Yes. Donovan and Alex share a diagnosis of the problem: their plant is not good at shipping orders. Shipping an order, therefore, is cause for celebration. Donovan also celebrates the speed at which they were able to do it. If every order could be shipped at that speed, the plant would be doing its job well.
Alex tells him they can’t always run the plant the way they did to ship order 41427, because it would involve drastically reducing the efficiencies of the plant. What he doesn’t say is whether every department would become less efficient, or just most. He also equates cost with low efficiency, without mentioning inventory. These are key topics which we’ll revisit later in the book.
What is similar between a manufacturing plant and a software delivery organization?
In a word: inventory. Imagine a simplified process for moving from an idea to usable software: first the idea is developed into user stories with acceptance criteria, then the developers work on the user stories, then changes are integrated into a release candidate, then QA is performed, then the release candidate is handed to users.
At each step of this process, excess inventory carries costs.
If more ideas are developed into user stories than can be worked on by developers, a backlog forms. The larger this backlog becomes, the more work must be done to prioritize it and prune it.
If developers complete work on user stories faster than their changes can be integrated, another backlog forms. The larger this backlog becomes, the greater the risk that the integration of one code change will mean rework is required in a later change. (“Changeset 2 changes the type of the second parameter to function B; new code in changeset 5 calls function B, but with the old type”)
If release candidates are created faster than they can be checked for bugs, then the fix for a bug will have to be integrated into the release candidate where it was found, and all subsequent release candidates. This is before one accounts for the costs involved in having developers revisit old code that they have forgotten about.
One can design better workflows for delivery of software than this one, but in any process where there are a series of steps between an idea and working software in the hands of users, excess inventory has costs and will decrease the speed of delivery.