Opinion: Obstacles to agile adoption are danger signs of development dysfunction.
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
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
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 planswith 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
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
Tell me how youre steering clear of the shoals at firstname.lastname@example.org.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.