Ever wonder why there are so few failed bridge-construction projects when most software is developed using a similar process? Conventional wisdom would dictate that building bridges would be harder than building Web sites. In this day and age, when you can probably count your company's truly successful IT projects on one hand, engineering's tried-and-true waterfall process just might not be ideal for software development.
When I think of software development project management pains, these symptoms top my list of significant failure indicators:
Still true today, and as described in Frederick P. Brooks' The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (Addison-Wesley, 1995), large-scale software development projects executed with a waterfall approach are rarely successfully implemented on time or on budget in such a way that the spirit of the solution is realized. This has increased the popularity of alternative approaches such as eXtreme Programming, Unified Process, Feature-Driven Development, SCRUM, and others. Contrary to the waterfall approach, these methodologies strive for increased agility by breaking a large project down into smaller repeated iterations of the development life cycle. Iterative approaches combat the shortcomings listed previously with:
For all the advantages of using an alternative approach, however, many organizations are resisting changing their deficient existing processes. The primary concerns that keep organizations from embracing these new methodologies are:
I believe that for most organizations looking to use alternative methodologies, a controlled evolution is the best mechanism for a transition to an agile methodology. To alleviate some of the short-term issues with the waterfall methodology and to assist in a migration toward an agile approach, I recommend:
If you build systems that, like bridges, have only one primary purpose or feature, the waterfall methodology should be fine. But if you're looking to make your systems do things that bridges can't, like increase feature sets every six to eight weeks and cost less to maintain over time, it's time to upgrade your methodology.
Robert Northrop [[email protected]] is a director of design and development with Tallan, a professional services company specializing in developing custom technology solutions for its clients.