Agile development should be more than just a buzzword

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.

But Firefox is a very different kind of product than SAP. For starters, it’s just one client application, as opposed to the massive suite of SAP software. More important, Firefox is typically installed by individual users, rather than being deployed and managed on an enterprise scale. That makes it well-suited to a highly iterative development model, where bug fixes and new features are pushed out frequently. Enterprise products, by comparison, cater to a more predictable, regular shipping schedule, to allow IT managers to properly test updates before deploying them.

Furthermore, as an open source project, Firefox caters to the agile methodology. Easy access to source code and bug databases allows independent teams to organize around specific tasks in an ad hoc way. Multiple code forks can proceed on separate timelines, to be merged at a later date. And community-based development is inherently non-hierarchical; there may be project leaders, and some developers’ voices may carry more weight than others, but no one is directly accountable to a corporate board of directors.

By comparison, SAP is attempting to apply agile methods to large projects that cross many teams — an area where they’re largely unproven. And switching to an agile approach could potentially hamstring SAP in other ways. For example, SAP products are infamous for their obscure and Byzantine documentation, while agile methods are infamous for not producing any documentation at all.

Can agile work for SAP? Most crucially, however, proprietary, commercial software companies such as SAP are likely to require significant organizational changes before they can become as comfortable with agile development as an open source project like Firefox. A company that can’t even settle on a single CEO seems an unlikely candidate for such decisive change. Some customers have even observed that SAP culture is itself un-agile; it favors defining business processes up front and setting hard design goals, and the tools don’t allow easy code reviews or multiple source code branches.

It’s possible, then, that SAP’s embrace of agile methods is mere hand-waving. In fact, the main thing SAP has to show for its agile revolution so far seems to be layoffs. At the press conference last week, Snabe bragged that he had cut the Business ByDemand development team by 30 percent — proof, he said, of SAP’s newfound agility.

The real proof, as they say, will be in the pudding. So far, Business ByDemand has about 100 customers. SAP is promising a full-scale rollout later this year, but it has promised that before. If it happens this time, then perhaps agile methods should get part of the credit for setting SAP back on track — but only part.

If Business ByDemand’s schedule slips again, however, other developers should take note: If you try to accelerate your product schedule by altering your software development process from the bottom up, without making corresponding adjustments in your management structure, you may find yourself merely accelerating toward a precipice. A buzzword won’t save you.

This article, “Agile development should be more than just a buzzword,” was originally published at InfoWorld.com. Read more of Neil McAllister’s Fatal Exception blog and follow the latest news in software development at InfoWorld.com.