Waterfall and Agile


Over the last several weeks, we’ve examined the underlying principles of both agile and waterfall development. We discussed the waterfall methodology of development, and how it relates to PMBOK, as well as our three articles on requirements analysis. And more recently, we have discussed the history and founding principles of agile development.

Looking both across the Internet and through our own articles, it often feels as though agile is presented as an alternative to the more traditional waterfall method. The implication is that waterfall is the old way, agile is the new way, and never the twain shall meet.

But perhaps the more appropriate way to phrase it is that agile evolved from waterfall. We talked last week about the genesis of the Agile Manifesto. What those 12 programmers sought wasn’t to throw out the “old” ways of development – simply to refine them.

The initial group that convened, in the words of the Jim Highsmith, were “sympathetic to the need for an alternative to documentation driven, heavyweight software development processes.” No wonder we tend to phrase it as an alternative, right?

But that sense of “anti-waterfall” you get from time to time when reading or discussing agile doesn’t do enough credit to either approach. Agile was created to streamline the process laid out by waterfall – to involve the customer more, to reduce documentation, and of course to speed up development.

But why try to explain it further when Jim Highsmith already explained it:

“The Agile movement is not anti-methodology; in fact, many of us want to restore credibility to the word methodology. We want to restore a balance. We embrace modeling, but not in order to file some diagram in a dusty corporate repository. We embrace documentation, but not hundreds of pages of never-maintained and rarely-used tomes. We plan, but recognize the limits of planning in a turbulent environment.”