Problem solve Get help with specific problems with your technologies, process and projects.

How to employ Agile values with a Waterfall methodology

As Agile development has gained in popularity, the traditional methods such as Waterfall sometimes get a bad rap. However, the two methodologies do not have to be mutually exclusive. Read this response for expert Lisa Crispin’s take on integrating Agile values in traditional software development.

Do you think it's possible for a team to be following the Agile values and still be using a traditional methodology, such as Waterfall? Would such a team be considered Agile?

I’m fond of paraphrasing Elisabeth Hendrickson’s definition of Agile, as I find it the most accurate. Agile development means delivering business value frequently, at least once per quarter, at a sustainable pace.

I’m kind of sad that “Waterfall” has come to be a synonym for “completely dysfunctional software development.” Waterfall is simply a set of clearly defined phases for software development, with “gates” in between each phase that determine if the project is able to move on to the next phase.

In the early 90s, I worked for a software company which followed a Waterfall process. However, our culture was focused on quality. All roles, including programmers, testers, analysts, product managers, training specialists and technical writers collaborated throughout the product life cycle. Programmers did code reviews, and automated unit tests with close to 100% coverage. Testers automated GUI-level regression tests. We had plenty of time for exploratory testing. We used many of the practices you see in Agile teams today, such as continuous integration and automated deployment. On rare occasions, we came in to work on a Saturday (along with all the managers up to the vice-president), but we never had to engage in a “Death March.”

As a result, the code we released to production had few defects, and our customers were happy. However, we only released to production once or twice a year. And though people in different roles collaborated, we still stuck to our roles. I wouldn’t say we took a true whole-team approach to quality. Still, for the context of that time and industry, what we did worked, we didn’t need to also be Agile.

I had a different experience when I worked in a software development organization that said they wanted to be Agile, and released to production every two weeks. There were no automated unit tests, and no sustainable pace; Programmers routinely worked 60 to 80 hours per week.

My test team used Agile values and principles effectively, doing a good job of exploratory testing and automating GUI regression tests, and writing customer-facing tests that programmers could use to help drive development. However, we couldn’t “test quality in” to the code. The software routinely failed, and a “hero culture” predominated – the lucky developer who found the bug that had brought down production was rewarded. The best developers burned out, mounting technical debt dragged down the development team, and the company eventually failed. Frequent releases without quality and sustainable pace does not equate to Agile.

If you work in a traditional phased-and-gated development environment, don’t worry so much about whether you meet the definition of Agile, but do let Agile values and principles guide you, and use Agile practices where they fit. Experiment with different ways to improve how you work and reduce technical debt. Continual improvement is a goal all software teams should embrace.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.