The Goal of Product Development

In the early 1984, Dr. Eliyahu M. Goldratt introduced the Theory of Constraints, a management philosophy largely based upon the principles of just-in-time inventory and lean manufacturing, in a book called The Goal. I read this book (and wrote a paper) in the fall of 2003 for an Operations Management class in graduate school at SMU. Because of the class I became very interested in manufacturing, logistics, and supply chain management. What go me hooked was the Beer Game, a multi-stage supply-chain simulation invented by MIT professors in the 60's (not a college drinking game).

Three years after the class, I was introduced (more like immersed) in Agile development, while leading the development of InSite, a software/hardware pharmacy automation solution for Long-Term Care (LTC). By then, I had led several successful development projects throughout my career, but that was my first experience with Agile (specifically Scrum). I was doubtful at first, having been "raised" using the Unified Process for software development. But we had an increadible coach (thank you Gary McCants!) and were able to gain a very high level of productivity with unprecedented visibility into status and predictability in planning. I was sold. That team was able to accomplish some amazing things, in large part because of Agile. It created a team dynamic and culture unlike anything I had ever experienced in my 10 years of software development.

During that time, I began recognizing many similarities between the fundamental concepts of Agile development and the Theory of Constraints, so I reread The Goal. In January 2008 I presented a brown bag to my team, entitled The Goal of Product Development, which outlined the similarities between lean manufacturing and software development and generated discussion on how we could apply the Theory of Constraints to increase productivity. The following is the first in an upcoming series of blogs I will post based on the concepts in that presentation...

“The goal” of any company, as Dr. Goldratt explains, is to "make money, now and in the future." And, Goldratt concludes that productivity is the act of bringing a company closer to its goal, i.e. productivity = making money (it's so simple!). In the book, Dr. Goldratt rejects typical Cost Accounting as a means of measuring productivity, and offers three new measurements: throughput – rate the system generates money through sales, inventory – money invested in purchasing things in which the company intends to sell, and operational expense – money spent turning inventory into throughput. In order to maximize productivity, as Goldratt explains, a company must improve all three measurements simultaneously, not each one in isolation. Therefore, if a company can increase throughput while decreasing inventory and operational expenses, it will achieve its "goal."

So, how does this apply to software development? I believe throughput, inventory, and operational expense can be used to measure the productivity of a software development team. Here's how...

Most product development companies make money (directly or indirectly) by selling new products and upgrades. Generally speaking, the faster a company introduces new products and features that have value in the market, the faster it makes money. And, the less new products and features a company introduces, the less money it makes. Therefore, a key productivity measurement for a development team is throughput, or its ability to produce market-ready products and features. In fact, one of the main principles of the Agile Manifesto is “working software is the primary measure of progress.” I prefer the term "market-ready" over "working," to include testing, documentation, sales/support training, marketing, and other activities required to make a product ready to be sold.

In addition to throughput, a development team can be measured by its inventory. A fundamental principle of the just-in-time (JIT) manufacturing philosophy is “inventory is waste.” This concept was introduced into the software development world in the book Lean Software Development by Mary and Todd Poppendieck. According to the Poppendiecks, inventory in software development refers to work that is partially done. Anything that does not add value to the customer can be considered inventory, including (but not limited to) incomplete or unwanted features, process delays, bureaucracy, unnecessary documentation, and unclear requirements. These things do not make money. They are inventory; they are waste.

Finally, operational expenses, or the money spent turning inventory into throughput, can also be useful in measuring the productivity of a development team. Since monetary expenses are relatively fixed on software development teams (mostly just salaries), operational expense can instead be measured in the time and energy expended in developing a product or feature. Excessive overtime, time wasted on dead-end requirements, huge code rewrites (iterative refactoring is ok), and gold platting are all examples of unnecessary operational expenses. The more efficiently and effectively a team can develop a new product or feature, the higher its productivity. Lowering operational expenses means working smarter, not harder.

As you can see, Goldratt’s three measurements (throughput, inventory, and operational expense) are very applicable to product development. Productivity of a development team can be maximized by monitoring throughput, inventory, and operational expenses and taking measures to improve each.

The Goal of Product Development is to increase sales by delivering market-ready products and features (throughput) while reducing the number of incomplete products and features (inventory) and minimizing the time and energy expended by the team (operational expense).

In The Goal, Dr. Goldratt provides tools for measuring and improving throughput, inventory, and operational expenses. He explores the relationship between dependent events and statistical fluctuations (which convinced me that typical Waterfall development methodologies are mathematically flawed). Goldratt highlights the importance of bottlenecks and how to exploit and elevate them to improve productivity. He also discusses “balancing the flow” of the system and the “fallacy of local optimums.” Finally, Goldratt presents a management model, the Theory of Constraints, to help companies maximize productivity. I believe each of these concepts, including the Theory of Constraints, can be directly applied to software and product development. Therefore, in the upcoming weeks and months, I will explore each of these topics (and more) in detail on this blog.