Review By: Jan A. Scott
05/22/2006The subject matter in this book is much broader than its subtitle. The book is divided into three sections. The first deals with metrics and project management techniques for agile projects. The second discusses software development using the traditional waterfall method, the Feature Driven Development method, the Extreme Programming (XP) method, the Scrum method, and Rapid Application Development (RAD). The third section compares the four development methods.

The author introduces what he calls “throughput accounting,” which seeks to put a business-like value on software using the analogy of manufacturing. Ideas and software requirements are considered inventory, while the amount of money spent to create the requirements is considered investment. Throughput is defined as the sales price of the software (or the budget for an in-house project) minus the direct costs of distributing the software. Net profit is equal to throughput minus operating expense. Return on investment equals net profit divided by investment. Unlike cost accounting, which focuses on reducing costs, this method focuses on delivering value to the customer--a basic agile development goal. The author shows how these metrics can be applied to each of the development methods treated in the book.

The book touches on many principles familiar to project managers and quality engineering professionals. Waste is defined as requirements that are not used because they were poorly analyzed or changed. Poorly written code is also considered waste. Metrics based on throughput accounting are introduced to track and control these elements. According to the author, the traditional project management method, in which scope is fixed early, is wrong because it forces us to be extremely accurate in our estimates of work. He maintains that scope (which has the least certainty) should be flexible and date (which has the most certainty) should be fixed. This is one of the principles upon which agile development methods are based--pick short iterations and deliver valuable, working code within that iteration.

The author is clearly an advocate of agile programming methods, but he encourages the agile programming community to prove its worth in business terms by using metrics that can be compared across development methods. Agile developers often say that metrics are unnecessary because working code is all that is needed. The author’s response is that a CIO needs language that will “appeal to his wallet . . . profitability and return on investment.”

Although some of the metrics seem a bit contrived--even to a traditional project manager such as myself--I think the book’s basic premise is correct; we need to prove the value of agile methods.

In the last section of the book, four different methods are compared. The author is clearly most familiar with Feature Driven Development. He spends four chapters discussing it and only one chapter discussing RAD. These chapters are a good overview of each method, and enables readers to see how they differ.

The author concludes that Rigorous Software Methodologies (RSM)--those large-scale, traditional methodologies--are best when done well for big projects in mature industries where the requirements are well-known. Agile methods work best on smaller projects with less certain requirements. He points out that it is harder to do RSM well than XP or Scrum, so we must not compare a poorly executed traditional project with a well executed XP project. This, in itself, is an argument for agile methods.

Although you may not agree with the book’s conclusions--and I believe a good portion of the agile community may not--it is interesting and thought-provoking reading. If you’ve ever struggled to explain the value of Scrum or XP to your CIO, try the metrics explained in this book.