Agile Transformation: How You Can Organize Your QA Teams Accordingly

This article is part of a series of 3 articles on agile transformation in QA teams, find the second part here and the third part here.

Agile is a rapidly growing methodology, and while it often only applies to some of the internal teams, agile practices actually impact the company as a whole. On an individual level, many roles and responsibilities within the organization will experience change as well. So the big question is, what is the role of the QA department in an agile organization?

The purpose of this series of 3 blog articles is to help your QA department deal with the most common challenges and difficulties often arising during an agile transformation, like:

• Members of the QA department are integrated into development teams
• Overall product quality still needs to be ensured while members are spread among several teams
• No exhaustive specifications which can be used to derive test plan
• No stabilization phase at the end of the project or before major releases
• Validation and regression testing need to be implemented during each iteration, during a tight window of just a few weeks or days
• No clearly defined releases thanks to Continuous Delivery
• With the addition of DevOps mindset and practices, developers have direct control over the production environment
• The QA department is no longer responsible of what is deployed in production

In this first article, I will uncover the differences between a waterfall approach to QA (in which testing and QA are isolated from the rest) VS. an agile approach through which QA and testing activities are no longer isolated from other teams.

How agile methodologies enable high product quality

The practice of QA is rooted in the traditional Waterfall testing methodology. Under this practice, the software development process is separated into three distinct phases: design, development, and testing. As a result, companies tended to assign people to particular activities to maximize efficiency. This spurred the creation of the QA department -- one that leads the testing activities after development and before deployment in production

Also read: "Agile Transformation in your QA Team, Part. 2: Learn to Work Differently"

What are the consequences of isolating test and QA activities from other activities?

This Waterfall approach to testing focuses on the project above all else. Things like cost, deadlines, and scope of the testing are top priorities, while the product quality is more of a byproduct than a goal. In this case, the role of the QA department naturally revolves around compliance verification with project specifications. This is a very simplistic overview of the QA department’s contribution and, more generally, of what quality means.

Ironically, this mode of operation isn’t really effective. It designates expert employees and departments by fields of expertise, which is perceived as a sign of performance, quality, and cost reduction. However, perception is not the reality in this case. Experts are clearly more effective than non-experts on select topics, but it is not the individual performance that should be measured, but the effectiveness of the system as a whole.

Overall, organizations that isolate activities have the following shortcomings:

• Teams do not benefit from collective intelligence. On the contrary, teams waste a lot of time redoing the same work rather than collaborating with each other.
• There is a significant lack of communication and the cost of transfer of information is high between experts and their teams, resulting in frequent miscommunications.
• Since everyone is working on small parts of many projects in parallel, the level of productivity collapses and team members then also tend to miss the bigger picture and to forget about essential issues.

This is the essence of the growth in agile over the past decade. Although expertise is important, it must be integrated in a fundamentally different way, keeping in mind the purpose of the organization. In other words, organizations should no longer focus on individual productivity, but on adding value as a whole.

An organization where QA and testing are no longer isolated: Agile and multidisciplinary teams

Agile promotes a product-focused approach through multidisciplinary teams capable of building an end-to-end product increment. This concept is often referred to as “Feature Teams.”

When transitioning to agile, departments like QA begin to take on a completely different shape. Feature teams not only alter the structure of teams, but the mindset as well. Where success was previously achieved by meeting deadlines, budget, and scope, agile pushes teams to focus on the needs of the end user -- and more broadly, on the profitability of the company.

Being part of an agile team: an incredible opportunity for the QA Team

In this context, the very notion of quality is changing. Quality goes far beyond meeting project specifications to focus on what really matters:

• Reducing operational costs by focusing only on relevant test cases
• Providing a highly qualitative user experience
• Meeting the real needs of users
• Being profitable, making the product successful
• Continuously improving the ways the team works, which will strengthen the points mentioned above

Therefore, this organizational change should not be considered a problem, but an opportunity for the QA department to lead the change toward product quality. The QA department can, and must, be integral to an agile transformation.

Now that we’ve highlighted the main differences between a traditional and an agile approach to QA, let’s take a closer look at how to execute the transition in the most effective way possible in my second article.