5. Write Value-Based Vendor Contracts

Another long-standing Agile tenet is "reduce the waste." In this context, "waste" is anything that does not bring clearly defined and immediate value. Today, the Agile movement is knocking on the door of the CFO, offering new approaches to software development vendor contracts.

Jeff Sutherland, one of the Agile movement founders, wants the higher performance demonstrated by Agile teams to be rewarded. In his talk, "Money for Nothing and Your Change for Free: Agile Contracts," he reminded us that clients are tired of vendors who promise low-ball prices and then make their money on change requests. Current practice suggests that vendor and client agree at the start on project overruns. Sutherland offers a way out for both parties. His approach is:

• Create a project backlog identifying all the features to be developed. Prioritize the features on business value (for example, expected ROI).

• Offer a usual fixed-price contract with time and materials (T&M) for changes.

• Add a "change for free" clause that allows a client to introduce a change and to remove features from the bottom of the prioritized list. The overall amount of work (project size) would not change; the vendor assumes the risk of late delivery.

• If a client is unwilling to remove the less-important features, the contract reverts to a regular T&M schema for changes.

This approach looks attractive to a client because it permits scope changes. It also avoids the trap of high cost of changes.

Sutherland also suggested that Agile contracts include a "money for nothing" clause. A high percentage of developed features are never used. When a development team releases software in stages, with the highest-priority and best business value features completed first, at some point a client may be satisfied with the partially completed project. In this case, the client would have the option of terminating the contract at any time, for 20 percent of the remaining contract value. This allows the client to get back 80 percent of the remaining money without severing the vendor relationship.

Of course, the "money for nothing" clause cannot be applied if the project backlog is not prioritized or if trust between management, the development team and the client is lacking.

6. Avoid Building Plank Roads

A movement's strength can be evaluated based its self-criticism, and several presentations were dedicated to questioning Agile. For example, in her presentation, "Expanding Agile Horizons: The Five Dimensions of Systems," Mary Poppendieck raised issues of Agile's sustainability, using a story about plank roads as an analogy.

About 160 years ago, she explained, the US had a massive boom in plank road construction. The road construction technology required high capital investment but brought immediate positive result. However, plank roads deteriorated quickly; their annual maintenance was 20 to 30 percent of the initial cost. The approach was eventually abandoned. Is Agile a sustainable solution, Poppendieck asked, or a plank road?

It wouldn't be the first such "silver bullet" offered to the software development community. High-level languages initially promised to solve what Edgar Dijkstra called a "software crisis" in his famous Turing lecture 50 years ago, but COBOL, Fortran and PL/1 made programmers' jobs more complex. Every industry veteran remembers the waves of structured programming, 4GLs, rapid application design, "programming without a programmer" and other solutions to all our problems. With time, all these "universal" solutions found a much more humble place.

Waterfall was a plank road, said Poppendieck, aimed at solving the process problem by applying project management methods already used in other industries. But its applicability to software development was dramatically overestimated, and the ramifications of this strategic mistake haunt us to this day. She cited an article from ACM Software Engineering Notes from April 1982: "To contend that any life cycle scheme, even with variations, can be applied to all system development is...to fly in the face of reality."

Said that article, "System requirements cannot be stated in advance, not even in principle, because the user doesn't know them in advance-even in principle." The same paper suggested that our development process changes the user's view of the requirements. To think that this was said in 1982! Poppendieck also suggested additional approaches to provide longevity and sustainability [PDF] to system development.