My top-tier task this week is a barely-touch-the-ground visit to Minneapolis, there to keynote the Agile 2006 International Conference that addresses many aspects of agile software development. Prior to the event, I've had the privilege of an early look at a survey of the state of agile practice adoption, conducted during the past year by developer and integrator Digital Focus with input from 128 organizations.

What struck me most strongly in that survey report was the statement, "The benefits people are seeking from agile methods are essentially two sides of the same problem. IT professionals are looking for agile techniques to help them manage scope while being more responsive to change. Non-IT professionals are looking for alternatives that will allow them to react more quickly to changing business priorities."

On reading that bullet point, I had a vision that I hope I'll find time to translate into a photo to illustrate a presentation chart. I imagined an electrical cable with a fitting at one end, with an adapter to make that compatible with another fitting, and yet another adapter connected to that ... until we get to the final adapter to the next cable in line, there to find that the cables were really compatible in the first place: that the adapters were merely adding mechanical bulk and electrical losses to a connection that could have been made more directly.

That's the image that comes to mind when I think of the business analyses, that get turned into specifications, that get turned into sub-specifications and test plans, that give rise to bug reports and defect resolution plans—with results then flowing in the opposite direction from developers back to business process owners and users. As every good electrical engineer knows, the longer the signal path, the greater the parasitic losses due to inductance (opposes rapid change) and capacitance (soaks up energy that could go directly into change, but instead goes into getting the process to pay attention). Agile development shortens that path and reduces those losses.

Later in the report, I found a comment that further confirmed my thinking on this: "Participants reported the greatest value provided by agile development is the ability to respond to change. This is exhibited in the form of challenges in managing scope, increasing the speed of delivery, responding to unclear business requirements, or responding to changing requirements."

So, why isn't agile development becoming so much the norm that it no longer needs a name?

Read the full story on eWEEK.com: Imagine How Agile You'll Be Tomorrow