Back to Waterfall Isn’t QUITE the Right Answer

This content is syndicated from by Ron Jeffries. To view the original post in full, click here.

An odd article by Trent Nix  on “LearnTFS” purports to debunk Agile by moving closer to waterfall. Interesting, but not quite right.

Trent Nix, in this article, suggests that you can make an Agilist “squirm” by asking where “your QA process” fits into Agile.  After the obligatory snide commentary about the “Agile miracle”, the article addresses a common issue that arises when you’re doing Agile, and proposes a common inadequate solution. Here’s my reply:

The author  has identified a real issue. So far, so good. Many teams trying Agile do encounter the test crunch/chaos at the end of the iteration. Some do go to a follow-on testing phase in the next iteration.

Bug reports later are not better than bug reports sooner.

It turns out that doing the testing later is not a very good “solution” to the concern. The reason is that while developers are working on D, E, and F, the testers are finding defects in A, B, and C. These defects come bounding back in, fouling up the current iteration and the next ones.

The author’s curative  suggestion is that you should “subtract time from your iterations for bug fixes”. Certainly, if you’re fixing defects, it will take time. The problem is that this time is not able to be planned. Yesterday’s weather doesn’t work.

Time lost fixing defects is still lost, even if you account for it.

More important, fixing defects is rework. You are doing work over. This means that your estimates of how long it took to do the thing were wrong, often very substantially wrong.

Rework breaks Agile.

The result of this is that you lose the most important benefit of Agile, which is the ability to predict future delivery based on the completion of “done” software. It is the flow of “done” software that enables management by scope rather than by  pressure.

Move testing upstream, not downstream.

Therefore, moving back toward waterfall is not the best next step, even if, as the author suggests, you shorten your iteration. A better thing is for developers and tester to learn to work together to get all the planned features fully done in a single iteration. This is neither simplistic nor easy. It requires great skill to determine as many checks for the software before the iteration starts, and to automate enough of these to let the developers run them as they develop, not just at the very end.

Examples clarify requirements and reduce defects.

When developers have well-crafted examples before they start, especially when they are available in some simple automated tool, they are smart enough to run them all before passing the software off to anyone else. If the software is then passed to testers, those testers can run the automated checks quickly if they care to, but are able to spend their valuable time looking for something interesting, rather than manually checking basic results.

Desire for stabilization iterations tells us we’re not good enough yet.

Another idea that our author supports is the notion of having one or more “stabilization” iterations. If these are needed, they are evidence that the work was not done at the time it was declared done. This violates the fundamental principle of Agile. Stabilization iterations are evidence of trouble, not a good idea.

Integration and regression testing are almost always needed. The construction of these automated checks is very valuable in making this testing smooth, rapid, and repeatable. Quite commonly they can remove or at least reduce the need for “stabilization iterations”, another idea that Trent supports.

Strong testing skills are very important to the team.
Rote testing, not so much.

All of this work is best done with good testing skills on the team. The trick is not to move the testers downstream: the author got that exactly wrong. The trick is to move them upstream, where they help the Product Owner describe what is needed in terms of clear automated examples. Their skills in identifying details and edge cases then inform the team the first time they work on the story, not just when they work on the bug reports.

Good teams do this. So can you.

The best Agile teams can produce software that is essentially defect-free in a single iteration. They can keep the whole system integrated all the time, fully tested all the time. Trent Nix has identified a common problem. Unfortunately, he has not proposed the best known solutions.

Good questions are a good start. It’s worth noting that people have been very successful doing Agile for about fifteen years now, and that there are good answers out there. So don’t just stop at the questions and then drop back into your old ways.

Leave a Reply

What is 6 + 5 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”