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.