Waterfall vs. Agile (Part 3): QA and Management

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.

QA

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).

Management

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.

Summary

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, as we've discussed, depends on the project at hand.