eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
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, Ive 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 Ill 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.
Thats 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 isnt agile development becoming so much the norm that it no longer needs a name?
Fortuitously, the report also offers a list of the factors that survey respondents named as likely to hamper agile adoption in their organizations. As I went down that list, I realized why I was getting a sinking feeling: The factors that make an organization a tough sell for agile development, it seems to me, are precisely the factors that make it likely to be a problem organization for development by any means.
Im talking about listed concerns such as:
- Lacks internal experience and/or skills
- Requires too much business involvement of organization
- Perceived difficulty in maintaining/integrating developed code
My reaction to these first three concerns is, “Compared to what?” If a development team is serving an organization that doesnt want to invest in skills, doesnt want to provide a high level of business involvement in IT, and doesnt treat code as a high-value asset deserving high levels of care and custodianship, those are problems waiting to happen.
Other objections to agile development include:
- Projects are too big for agile practices
- Projects are too technically complex for agile practices
- Distrust of agile practices for mission-critical systems
My reaction to these is that they sound a lot like “Our projects are too big, our projects are too complex, and our mission depends on systems that are too big and too complex to evolve as quickly as they should.”
You get the idea, I hope. In saying why their organizations may find it hard to assimilate agile development, I feel as if some developers are summarizing the reasons that their organizations are already in a danger zone of inability to cope with crucial application development issues.
Tell me how youre steering clear of the shoals at peter_coffee@ziffdavis.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.