What is The Goal? I was inspired to read “The Goal” by Eliyahu Goldratt last weekend. It’s been several years since I last read it. It was one of my first books that helped me to understand many of the concepts I now take for granted. It was a delight to find it on Audible.com. I am a Platinum member and receive a few audio books each month as part of my subscription. It sounded great so I downloaded it. It was even better this second time. It was a great production and it was wonderful to re-acquaint with Alex and his crew in the amazing novel. Today, I would like to share my thoughts about the book.

• Perspective is everything
• Common Practice is not Necessarily Good Sense Common Sense
• Local Optimums Are Not Optimal

The book shows that perspective is everything. There are many times when the team is confronted with a major problem, and the solution is right in front of them. They had to shift their perspective. Everyone was unable to make the necessary shift in thinking to find the solution because of their deeply held assumptions. It was absurd that they hadn’t realized the solution sooner after they had made the paradigm change. Similar revelations have occurred to me over the years. I have tried to limit work in progress (WIP), and multitask as much as possible on my projects. Many of the improvements I’ve made in resource and release planning, time-boxed agile methods, and Kanban are directly due to my own paradigm shifts. It’s almost painful to think back to how I managed my projects and led my teams before my thinking changed. Common Practice is not Necessarily Good. Common Sense is not Necessarily Good. Many of the common practices in our professional lives don’t really help us reach The Goal. Efficiency is a key concept in the book. Although parts of the system were designed to appear productive, they actually created large amounts of work in progress that clogged up the system and tied up materials. In my world of software development, this is an example of how many people and organizations place high value on a detailed plan. Isn’t it a better goal, to create a product that meets customer needs and is on budget? Isn’t all the rest just window dressing? I won’t spoil the details, but zooming in a little more will bring you to the ultimate goal of the organization. This is the goal that should be remembered. Standard waterfall-style teams tend to spend a lot of time on design and documentation, then code as fast as they can, and then update and create new documentation. The design WIP grows and grows, and you will have to rework your design by the time you implement it. You will have to go back to the code to remember what you did to update the documentation. ?Then, you release it to customers and discover that it doesn’t meet their requirements. Software WIP and other domains can be considered perishable. The longer it sits as WIP, then the more value you lose due to rework or time to familiarize yourself with the WIP. If you have a set functionality, you should be working on it, getting feedback, or documenting it. Every moment you don’t do one of these things is wasted on your project “factory floor”. This is why I have been driven to map the value stream of each team using kanban as my vehicle. Minimizing WIP by focusing only on one item and moving through the entire value stream before moving onto the next is a great way to reduce WIP.