I don't normally read comic books or graphic novels but I saw a tweet about The Goal: A Business Graphic Novel by Eliyahu M. Goldratt and it peaked my interest. This particular version is a graphical adaptation of the original novel which was printed in 1984. The novel introduces Goldratt's Theory of Constraints in an exciting and memorable way with plots, twists and romance. Ok, there's no romance and some of the story plot feels a little contrived, but nevertheless the information is interesting and presented uniquely in a fun format.
The novel starts off with the main character, Alex Rogo. Alex is the manager of a manufacturing plant in quite a dilemma. The plant is in bad shape and he has 3 months to turn it around else the powers that be is shutting it down and laying everybody off.
As anyone can imagine (manager or not), this is quite a perplexing problem. As luck would have it, Alex runs into an old professor that gives him words of wisdom as he treks down this challenging path. Words to help him think about and improve the processes in the plant in order to achieve "the goal".
Now you might be wondering:
"What does assembly line type manufacturing have to do with software development?"
It turns out quite a bit. Software organizations are comprised of people and processes in order to produce software. Similar to how a plant (also comprised of people and processes) would produce physical products.
Even as individual software engineers, we have our own personal processes to produce the work we do everyday.
One of the underlying themes of the book is the idea that "a chain is only as strong as the weakest link." Or a company is only as fast as it's slowest department. How many times have you rushed to finish some bit of work, only to have it sit and wait in queue for the next part of the process. Perhaps your code needs to go through QA and the QA department is understaffed. It doesn't matter how furiously fast your wrote your code, it's not going to production any quicker.
Hurry up and wait.
These are the types of issues that are relatable across all sorts of companies and it's really interesting to see the parallels.
At the end of the day, it's all about POOGI, the Process Of Ongoing Improvements and the book describes in 5 steps:
So to make the 5 steps a little more concrete, let's go back to our QA constraint example.
Side note: I'm not picking on QA organizations. I was a QA engineer for 13 years and have a lot of sympathy and respect for them but also understand deeply the challenges.
Identify the System's Constraint(s).
There are many reasons why a QA department can be one of the constraints of the overall software production cycle. Perhaps the department is understaffed, or needs test automation, or better test automation.
Decide How to Exploit the System's Constraint(s).
How do we address some of these constraints? If it's a resource issue, the solution could be as simple as hiring more people. If it's a need for test automation, maybe it's setting aside time to train the staff to create automation.
Subordinate Everything Else to the Above Decision(s).
If you identify a problem and find a solution, it's all meaningless if you don't actually execute on it. If this means taking developer time to train QA staff or help out with automation, just do it!
Elevate the System's Constraint(s).
In doing this process, the QA department becomes less of a bottleneck, contributing to the overall efficiency of the whole system.
Go Back to Step 1.
Iterate, iterate, iterate.
Conclusion
There are many other details in the book and though they are in the context of product manufacturing, I think the takeaways from it are invaluable to those of us in the software world.
Top comments (0)