Do you think it's possible for a team to be following the Agile values and still be using a traditional methodology,...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
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.
Related Q&A from Lisa Crispin
Agile leader Lisa Crispin explains a more organic, more Agile approach to test reporting.continue reading
When it comes to Agile planning, average time over many iterations is a more important metric than individual story estimates.continue reading
Most inexperienced Scrum teams overcommit on what they will deliver, and when. Agile leader Lisa Crispin says that does more harm than good.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.