As technical jargon goes, "agile development" has a great ring to it. Even to business managers, it sounds dynamic and vibrant -- just the thing to speed up production and rescue a flagging software project. Maybe that's why companies so often expect too much of agile methods.
Take SAP, for example. For the world's fourth-largest software company, SAP sure has trouble shipping software. Business ByDemand, the company's promised Web-based ERP offering, has suffered interminable delays. Even some of SAP's own user group members claim SAP is no longer innovative, citing a list of recent failures.
[ Keep up to date on the latest developments in and insights on software development with InfoWorld's Developer World newsletter. ]
Little wonder, then, that "accelerating [SAP's] innovation capability" is Job One for Bill McDermott and Jim Hagemann Snabe, the company's newly minted co-CEOs. "I don't think we did a lot of wrong things in the past," Snabe said at a press conference at SAP's Silicon Valley office last week. "We just have to do things much faster." Specific details of how that speedup will occur were scant, however, with one exception: According to Snabe, SAP's development teams have already begun to embrace agile development processes.
That's all well and good, but agile methods are no magic fix for what ails SAP. McDermott and Snabe seem to be making the all-too-common mistake of assuming agile development and business agility are the same thing. They aren't.
What agile development is and isn't
The agile development movement began in 2001 out of concern that traditional project management practices, when applied to software development, were ineffective, inefficient, and overly cumbersome. Managing programmers has often been compared to herding cats; the central idea common to all agile methodologies is to stop herding.
Agile projects are inherently iterative. Tasks are broken down into small increments that can be delivered in short timeframes. Programming teams are largely self-organizing, with tasks distributed based on skills, rather than titles or corporate hierarchy. Long-term planning is de-emphasized or even discouraged. Instead, developers work directly alongside other stakeholders to establish and refine project requirements in an organic way.
This isn't to say agile development encourages reckless decision-making or "cowboy coding." Rather, agile methods embrace a different philosophy from traditional practices, one based on the Agile Manifesto. Among its principles are that businesspeople and developers must work together; that requirement changes should be welcomed, not resisted; that teams should deliver builds frequently; and that working software should be the primary measure of progress.
Note, however, that the Agile Manifesto's focus is on generating code, not concepts. Agile methods aim to deliver working software based on requirements, but that doesn't mean the software will necessarily be innovative or that it will meet market requirements. If SAP's Snabe wants to accelerate innovation at his company, he can't expect coders to lead the way. Product managers and other stakeholders remain just as important as ever; if they can't change, then neither will the product cycle.
Where agile fits
Mind you, SAP is hardly the only software vendor hoping agile development methods will help it deliver products faster. Earlier this year, the Mozilla Foundation announced a new development model for the Firefox browser that melds agile practices with more traditional methods. The aim is to allow Firefox to roll out features faster to compete with the likes of Chrome and Safari.