Answer

How to employ Agile values with a Waterfall methodology

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?

    Requires Free Membership to View

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.

This was first published in November 2011

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: