Agile Zone is brought to you in partnership with:

Alberto has posted 4 posts at DZone. View Full User Profile

Waterfall vs. Agile: QA and Management

  • submit to reddit

We saw in the previous articles the main differences between agile and waterfall. In this last article we are going to take a deeper look focusing on Quality Assurance (QA) and Management.

Read the other parts in DZone's 'Agile vs. Waterfall' series -



There is a complete switch of mentality for QA from Waterfall to Agile. In Agile, QA is expected to be a very proactive part of development. They no longer just certify the functionality of the application based on a contract. They have to be part of the day to day development. They ensure quality at all levels and act as a communication hub between the business, management and developers.

One of the main challenges for a QA team is that the necessary skills required to perform their job effectively becomes exponentially increased. They need to understand the code, write their own automated suite cases, perform exploratory testing and suggest new ideas.

The frontiers of QA, in Agile, are a blur, because they share the same objective as developers and managers- to create the best application for the customer. They don’t care about contract documents. And an important source of misunderstanding for new QA Agile teams transitioning from waterfall, is to find that there aren’t any specifications or guides to tell them how to certify a specific functionality.

When talking about QA in Agile, one of the most common arguments I have heard is that QA is not ready to perform all the activities they are supposed to be performing in agile successfully. While for some people this may seem an issue or a threat, I see it as an opportunity for change.

In my opinion, as more teams adopt Agile and more QA teams become integrated in the development process, QA will evolve into something different. It won’t be a completely different branch of software development anymore. It will become a new specialization of software development, where the most skilled developers will be in charge, getting to a point where QA ideally would drive the development- (QDD).



Because Agile teams are pretty much self managed, Management is probably the part of software development that most enjoys having a fully functional agile team. On the other hand, management usually have a very hard time with teams coming from waterfall as they need a lot of direction and assistance to fully complete the transition from Waterfall to Agile.

Management in agile is all about empowerment, communication and transparency. Controlling is no longer a function of management which is an issue with teams that are mostly composed of junior or unmotivated developers. For these types of groups, probably a controlling strategy would still be more successful.

The other critical responsibility for managers in an agile team, is to remove all the impediments raised by the rest of the team members. They need to make sure that all that is possible is done so that developers, QA and other parts involved in the day to day work of the application don´t have any reason to be less productive.



This is the last of the three series of articles about waterfall vs agile. The first article was an introduction about agile vs waterfall, The second was a deeper look into development and business in agile vs waterfall and this last one was about QA and Management.

Probably the main question after reading these three articles is, “should we then do agile or waterfall?”. That answer depends on a few factors in your project.

Having said all this, the ideal scenario is a project that due to its characteristics is located in the first column (“Do Agile”) of the previous table. Unfortunately most of the projects share mixed characteristics of agile and waterfall so it may be better to take a hybrid approach to software development.


QA.png81.16 KB
Management.png36.92 KB
Summary.png61.8 KB
Published at DZone with permission of its author, Alberto Gutierrez.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Stephane Vaucher replied on Wed, 2010/07/21 - 10:32am

IMO, this article has some good and bad parts.

Good parts, correct about agile empowerment. It is a core principle. There exist waterfall environments that do empower, but it is not a key principle. Also, correct about QA being a bit lost during a transition. However, any paradigm shift will always lead to some level of confusion.

I'm not sure about a few comments. I'm also not sure why Waterfall would "not need testing". The alternative would be to conduct proofs of correctness, but these are way too complex to be used to cover the totality of a large system. My experience with waterfall processes is that a good testing team in a waterfall environment will actually perform some very important tests that a development team has problems doing. For example, there are stress tests and black-box test case generation. These could of course be done in an agile environment, but they require special training and are heavily automated.

Finally there are some inaccuracies. RUP is another process, an iterative one at that. How do you propose managing an iterative process with a waterfall process? If anything, many agile practices can be used in the RUP. Also, CMMI is orthogonal to these development processes.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.