Foreword

It is so good to finally have a book targeted at the software industry that challenges some of the basic business assumptions behind software engineering, and particularly those behind managing software organizations. At the time these words are written, the software business is facing huge difficulties worldwide. I hope that these difficulties also generate a willingness to look afresh at the business and to have the courage to contemplate changes. Other industries, particularly in manufacturing, went through such conceptual changes in their business processes during the 1980s and the 1990s. It is certainly not easy, but as I've personally experienced, it is highly desirable.

In 1985 I managed my own software company in Israel and was quite proud with my new package for certified public accountants. But, even though my package competed very nicely in the market, I noticed an on-going business problem: More and more development was needed to keep the package alive. In such a case, how do I justify the on-going investment? Eventually, I was not sure that a small software company, focused on a specific market niche, could be a good business--even when the product itself was enthusiastically accepted by the market. I felt that even though I already had my MBA, I needed a better perspective to understand the business.

Then I met Dr. Eli Goldratt.

I had heard a lot about Dr. Goldratt's international software company, Creative Output, Inc., which was seen as much more than just an excellent and innovative software company. It challenged some of the most sacred norms of business, such as the concept of product cost. I could not understand how anyone could challenge the basic concept that a unit of a product has a certain cost associated with it. I was intrigued enough to be open to an offer: Join Creative Output in order to develop a video game for managers that would deliver some new managerial ideas. At the time, computerized games were focused on fast fingers and perfect coordination. They were certainly not something of interest to adults. How could a computer game be readily accepted by grown-up managers and deliver new managerial ideas?

This was the start of a mental voyage into a new management philosophy that does not lose its grip on reality. I turned myself into a management consultant with a focus on improving whatever is the particular goal of the organization. Software became an important supporting tool, but not the focus of the change efforts.

The relevance of the Theory of Constraints (TOC) to the software industry is twofold:

1. Vastly improving the flow of new products to the market.
2. Determining the real value of a proposed project, or even just a feature, to the final user. The underlying assumption is that if we know the real value to the user, it is possible to develop the right marketing and sales approach to materialize the value to the user and to the software organization.

David Anderson focuses mainly on the first aspect in this book, which includes looking at the business case and ensuring the ability to make it happen. Software organizations can definitely be improved with the help of the new generic managerial insights that have already changed traditional western industries. David does a great job in bringing together the generic managerial ideas and rationale and combining them with software-focused approaches to come up with a coherent approach on how to improve the business.

Read this book carefully with the following objective: Learn how to make more with less. Don't accept every claim David raises just because he says it is so. If you truly want to make more with less, you need to be able to internalize the claim. All I ask is you give it a chance. Dedicate time in order to rethink your environment, and then see for yourself what to do. Overcoming inertia is the biggest challenge of any really good manager in any organization. Of course, rushing to implement new fads can be even worse. Keeping an open mind and confronting new ideas that invalidate basic assumptions are what I suggest you strive for. This book is for you to struggle with. It is not trivial, and it is not a fad. If you like what you do now, it should be your responsibility to check out new ideas that might yield huge improvements.

Here are some brief insights regarding the assessment of the value to a potential customer of a new feature, particularly to a new software package.

A new Feature can bring value to the user only if it eliminates, or vastly reduces, an existing limitation. The amount of the value depends on the limitation removed--not on the sophistication of the feature itself. Let us take a simple example. At a certain time in the history of word processors, somebody had an idea: Why not add a spell checker to the package?

What is the value of the spell check we now have as a routine feature? What limitation does it eliminate or reduce? For people with a very good knowledge of the language, spelling mistakes are caused by writing too fast. So, without a spell checker, those people need to read carefully what they just wrote. People who are not in full command of the language (for example, me, as an Israeli) need to look at the dictionary very often, which is quite time consuming.

This need leads us to recognize two additional insights.

People developed some rules to help them overcome the limitation. People who used word processors had to go over whatever they just wrote before sending the document to others. People without good command of the language needed to be supported by a dictionary.

Once the limitation is vastly reduced, people should replace the old rules with new ones that take full advantage of the removal of the limitation. If this does not happen, then there is no added value to the Feature.

Now we can see whether adding a spell checker to an existing word processor brings value. Suppose you have perfect command in the language, would you now refrain from carefully reading your recent document before sending it away? Spelling mistakes are hardly the main reason to go over any document that I want other people to read. So, for people with perfect knowledge, the spell checker offers no real value. But, for me as a person in good command of Hebrew, but not good enough in English, spelling mistakes in English are a nuisance. But, could I really avoid them just by the use of a spell checker? As long as the spell checker does not suggest how to write the word correctly--the limitation is only marginally reduced and thus not much value is produced. This means that if we want to generate significant value for the specific user group that has not mastered the language, we need to add good suggestions of what should be written instead.

In this simplified example, we already see the need to check the behavior rules both before the limitation is eliminated and after. Is it always clear what the new behavior rules should be? Assuming the user is well aware of what the new rules should be is a very common trap for too many software features.

Suppose that a new Feature is added to a sales-graph display module in which the trends shown by the graph are analyzed for statistical significance. The limitation is lack of knowledge on whether market demand is really up or down or just part of the normal statistical fluctuations. The current behavior of the management is: If sales are up, the sales agents are complimented and get appropriate bonus; if sales are down, there are no bonuses and some hard talk from management.

What should the new management rules be once management knows whether the rise in sales is significant? I'm afraid that in the vast majority of the cases the behavior will be exactly the same. Hence, the newly added Feature will not add value to the customer, even though some customers might ask for it and even exert a lot of pressure to have the Feature developed. Eventually, the value to the software company of developing the Feature will be negative.

Of course, for a good managerial consultant assisting in the formation of better decision processes, a specific Feature can bring immense value both to the consultant and the client. In this case, a strategic partnership between the consultant and the software company can be a win-win for all, including the client.

Improving the flow of the Features that truly bring value to the customer and also have a good chance of generating revenues for the software organization is what this unique book is all about. The Agile Manifesto principle of "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software" is fully in line with the Theory of Constraint's objectives. To be more precise, TOC strives to generate more of the organization's goal. But, in order to do so, the organization has to generate more value to its customers. The means of early and continuous delivery of software that truly generates value should assist both the software organization and its clients in achieving more of their respective goals.

Please bear in mind that improvement has only one criterion: Achieving more of the goal. The path to truly improving the performance of your software organization may well start with this book.

--Eli Schragenheim