Rapid Feedback Propels Agile Development

by Ken Orr, Fellow, Cutter Business Technology Council

The time between an action and the feedback on that action is critical.

-- Scott Ambler, Senior Consultant, Cutter Consortium

As agile development gains further currency, it is in danger of becoming watered down. Agile development in the hands of traditional project managers is likely to become neither agile nor development. As this happens, it is particularly important for the best and brightest in this business to distill what the best features of agile development are. As I say, "You can fake everything but testing."

Agile Development and Quality

There is one overarching lesson to be learned from the agile movement for everyone involved in software development, and that lesson is the vital importance of rapid feedback to the communication process. For more than 50 years, quality- and lean-manufacturing gurus have been telling us that the sooner a part or subassembly is used, either by the end user or by another process in the assembly line, the higher the quality of the part produced. The reason is feedback.

While the elimination of inventory is often sold as a cost saving in manufacturing organizations, on a larger scale, eliminating inventory has the more important effect of improving quality. The reason is clear: if a part or subassembly is used immediately, then any problem it has will be noticed right away, and changes will be made before millions of bad parts are created.

This same quality process is at work in software, especially software requirements and design. If a mistake is made in specifying, capturing, or implementing a requirement, then the quicker the problem is discovered, the quicker it will be corrected. If that correction occurs in days or weeks as opposed to a few months or years, then less time and effort will be wasted. And if the corrections are made in minutes or hours, as is possible with really agile tools, then so much the better.

Agile development clearly exploits this quality feedback effect. As the time between specifying a requirement and the implementation decreases, the level of real meaningful communication between business users and the development team increases.

Clearly, requirements don't get better with age. In fact, in a great many traditional (waterfall) methodologies, by the time the requirements are actually validated through implementation, most of the people who were involved will have moved on to other jobs. (Recently, I worked on a very large governmental project where the business process definitions were created but not immediately used. In fact, those business specifications still have not been used nearly two years later. The chances of those requirements having any real relevance for the final systems are minuscule and diminishing by the day.)

I welcome your comments on this issue of the Cutter Edge and encourage you to send your insights on the market in general to me at korr@cutter.com.

-- Ken Orr, Fellow, Cutter Business Technology Council