Agile development is popular. All the cool kids are doing it: Google, Yahoo, Symantec, Microsoft, and the list goes on.[2] I know of one company that has already changed its name to Agili-something in order to ride the bandwagon. (They called me in to pitch their “agile process,” which, upon further inspection, was nothing more than outsourced offshore development, done in a different country than usual.) I fully expect the big consulting companies to start offering Certified Agile Processes and Certified Agile Consultants—for astronomical fees, of course—any day now.
Please don’t get sucked into that mess.
In 1986, [Brooks] famously predicted that there were no silver bullets: that by 1996, no single technology or management technique would offer a tenfold increase in productivity, reliability, or simplicity. None did.
Agile development isn’t a silver bullet, either.
In fact, I don’t recommend adopting agile development solely to increase productivity. Its benefits—even the ability to release software more frequently—come from working differently, not from working faster. Although anecdotal evidence indicates that agile teams have above-average productivity,[†] that shouldn’t be your primary motivation. Your team will need time to learn agile development. While they learn—and it will take a quarter or two—they’ll go slower, not faster. In addition, emphasizing productivity might encourage your team to take shortcuts and to be less rigorous in their work, which could actually harm productivity.
Agile development may be the cool thing to do right now, but that’s no reason to use it. When you consider using agile development, only one question matters.
Will agile development help us be more successful?
When you can answer that question, you’ll know whether agile development is right for you.
The traditional idea of success is delivery on time, on budget, and according to specification. [Standish] provides some classic definitions:
Despite their popularity, there’s something wrong with these definitions.
“Completed on time, on budget, with all features and functions as originally specified.”
Despite their popularity, there’s something wrong with these definitions. A project can be successful even if it never makes a dime. It can be challenged even if it delivers millions of dollars in revenue.
CIO Magazine commented on this oddity:
Projects that were found to meet all of the traditional criteria for success—time, budget and specifications—may still be failures in the end because they fail to appeal to the intended users or because they ultimately fail to add much value to the business.
... Similarly, projects considered failures according to traditional IT metrics may wind up being successes because despite cost, time or specification problems, the system is loved by its target audience or provides unexpected value. For example, at a financial services company, a new system... was six months late and cost more than twice the original estimate (final cost was $5.7 million). But the project ultimately created a more adaptive organization (after 13 months) and was judged to be a great success—the company had a $33 million reduction in write-off accounts, and the reduced time-to-value and increased capacity resulted in a 50 percent increase in the number of concurrent collection strategy tests in production.[3]
[2] Source: various experience reports at the Extreme Programming and Agile conferences.
[†] See, for example, [Van Schooenderwoert], [Mah], and [Anderson 2006].
[3] R. Ryan Nelson, “Applied Insight—Tracks in the Snow,” CIO Magazine, http://www.cio.com/archive/090106/applied.html.