Earlier today I wrote about Forrester Research's findings that agile software development is gaining momentum in the enterprise, with nearly half of IT pros saying agile most closely reflected their companies' development process. NarrowCast Group, the parent company of IT Business Edge, recently switched from a traditional waterfall development process to a modified agile one.
Mozilla has also begun using a hybrid model that incorporates elements of both agile and waterfall approaches for its flagship Firefox Web browser. The goal is to more quickly introduce new features -- aided by agile's emphasis on iterative releases -- while maintaining backward compatibility, security and overall code quality, reports internetnews.com.
Mozilla to date has provided stability and security updates only on the released branch of Firefox (i.e., Firefox 3.5.7) and new features only on major new releases (such as Firefox 3.5). The hybrid model, code named "Lorentz," will make the newly-released Firefox 3.6.x Web browser Mozilla's stable branch, and it will receive both bug and feature updates. So while more time will pass between major new releases, users will get more features in the interim. The approach is similar to one employed in UNIX and Linux development.
Said Mozilla's director of Firefox, Mike Beltzner:
I'd say our new approach is more agile than the traditional model we've used. This is a sprint on a single task that is very tightly focused, and there is a set of goals which are required.
Mozilla developers aren't tied to a single development methodology. The article mentions a more traditional waterfall approach is used for longer-term projects that require fewer iterative changes, such as a project called Compositor that aims to improve Firefox's layout. For those trying to make sense of the agile vs. waterfall debate (including me), Beltzner's final quote is a good one:
Really, we're not tied to any specific development model. We're tied to what is effective.
For those using hybrid models, I think the key is to make sure the desirable aspects of agile, such as its quick iterations, don't get lost in the shuffle. Some time ago I wrote a post that included a reference to an agile development project gone wrong that ended up looking a lot like a traditional waterfall project with a thin veneer of agile. Requirements were created up front, schedules didn't allow for needed tasks, and months passed between iterations.
One important point that came out of my 2008 interview with Doug Mow, senior VP of marketing for Exigen Services, an application outsourcing provider that uses agile: Governance models will need to change. He told me:
When you take a look at the whole system, you can sign off on the whole system. But what happens when I sign off on it in pieces? What constitutes signed off and accepted? That becomes a slightly different concept than it was previously.