top of page

The changing role of QA managers in the Agile environment | David Tzemach

Updated: Mar 2, 2022

Many questions arise when an organization starts the transformation to an Agile environment, some related to adopting the new Agile culture and some related to the dramatically changing organizational structure.

One area that creates confusion among managers is, of course, what is going to be their new role once the organization becomes Agile. This post will focus on QA or test managers and describe the transformation from traditional QA managers. I’ll discuss new opportunities in the Agile environment while reviewing some of the most commonly asked questions, such as:

  • What is the role of the QA manager in an Agile environment?

  • Do we need a QA manager in an Agile project?

  • Who is responsible for ownership of quality?


Before we start, I want to mention a few major facts that will help you understand the context of this post.

  • Fact 1: The current challenges in the software industry are different from a few years ago. Just think about the new platforms that did not exist 10-15 years ago, such as web, cloud, and mobile.

  • Fact 2: Agile frameworks are here to stay; we see more and more companies worldwide making the transition to Agile development processes (such as Scrum and Kanban).

  • Fact 3: The current software industry pushes organizations to their limits, and as a result, organizations must deliver quality products fast and early to stay relevant.

  • Fact 4: Employees’ welfare is critical to the organization’s success. Organizations that treat their employees as resources will not keep them.

  • Fact 5: Agile transformation affects all layers of the organization, but the role of managers (and QA managers in particular) is most affected.


To best provide the answers to the questions above, I’ll start with a quick review of what it meant to be a QA manager in the pre-Agile world. I will review the QA manager’s role in traditional software development while focusing on the Waterfall methodology created in the early 70s.

The management style was different…

According to the Cambridge Dictionary, the traditional manager’s management style is mostly based on the “Command & Control” method, defined as “a situation in which managers tell employees everything they should do, rather than allowing them to decide some things for themselves.

Here are five primary characteristics of this kind of manager:

  1. Controls all major aspects of the project (timelines, pace, task assignments)

  2. A strict hierarchy of authority (the manager at the top of the pyramid)

  3. Micromanagement led by a lack of trust between the manager and his employees

  4. Zero tolerance for mistakes made by his employees

  5. Commands must be followed, or discipline is applied

The interaction between the manager and his employees is based on five phases:

Phase 1: Identification of the organizational “needs” (budget, resources, and requirements)

Phase 2: Providing employee demands, expectations, and goals

Phase 3: Employees follow the manager’s instructions without question

Phase 4: Monitoring employee progress of task completion

Phase 5: Comparing employees’ deliverables to the preliminary goals

The outcomes of “Command & Control”:

  • Employees are treated as resources and not as human beings who have their dreams and personal goals

  • There is less room for an employee’s creativity and innovation (how can there be, as the manager provides all the instructions)

  • The manager is at the center of the team (team empowerment is less important)

  • The manager’s success is more important than the success of the team

  • Employees are unmotivated

  • Employees are less involved in high-level decision processes

More opportunities as managers

QA managers had their departments, groups, and teams that they could manage, depending on their hierarchy. Roles like a quality director, test group leader, and test team leader were very common in traditional software development processes.

In addition, in the Waterfall model, testers worked together on the same team (usually at a separate physical location from the development team), which meant that QA managers managed only testers (there were no programmers on their teams).

Testing projects were challenging but had some major advantages

Most of the QA managers who have ever worked in the Waterfall SDLC are familiar with the different challenges, disadvantages, and deficiencies of this model. However, compared to an Agile SDLC, the Waterfall model has some major advantages that help QA managers do their job:

  • A dedicated testing phase started only when the development phase was completed, which reduced the risk of multiple code modifications in an Agile environment.

  • QA managers and their teams received comprehensive requirements documentation (specs, SRS, etc.) to see the whole project's big picture. In Agile development, one does not use large comprehensive docs.

  • QA managers and their teams had more time to prepare comprehensive test documentation (STP, STD, and STR), which are less relevant to Agile software development.

  • QA managers had the chance to determine the entry and exit criteria for the testing process.

Quality ownership

In the pre-Agile era, the ownership of quality was the responsibility of QA managers. As a result, they had more power to affect the different quality aspects of the project. Let’s see some classic examples:

  • QA managers had the power to determine the defect life cycle (DLC)

  • QA managers established the quality metrics used to track different quality aspects and progress

  • QA managers choose how to manage the testing risks based on their knowledge and experience.

  • QA managers controlled how to split and prioritize the work among their testers.

  • QA managers decided on the test coverage for the different areas of the product.


After we looked at the world of QA managers pre-Agile, it is time to see how Agile development methodologies changed the roles and core responsibilities of QA managers. This part will review the main reasons QA managers often feel confused about their future once the organization starts an Agile transformation.

There is no such thing as test departments.

As we saw earlier, QA managers had their departments, groups, and test teams back in the old days of the Waterfall development process. When the organization transitions to an Agile environment, there is no such thing as a pure testing department where testers, managed by a QA manager, sit together, usually at a different physical location from the development team.

Let us examine the most common Agile framework: Scrum. The Scrum framework describes three main roles: Scrum Master (SM), product owner (PO) and Scrum development team. The Scrum team is self-organized (does not need managers to tell it what to do) and is composed of different engineers such as programmers, DBA, designers, and testers.

In summary:

  • In Agile, testers and programmers work together on the same team.

  • The Scrum framework does not define the role of a QA manager.

  • QA managers do not manage teams in an Agile environment.

  • There is no day-to-day management of testers (testers are integrated into the new scrum teams).

No direct day-to-day management of testers

In an Agile environment, testers are integrated into the Scrum teams. Scrum teams are self-organized; there is no need for a QA manager to manage the testers as in the traditional working environment.

Another important aspect in this regard is that the Scrum teams should be able to determine what and how to test each PBI, and therefore there is no need for a QA manager to tell them what to do during the testing effort.

There is less room for comprehensive documentation 

In an Agile environment, there is less room for comprehensive documentation, as described in the following table:

Quality is everyone’s responsibility

As we saw earlier, in the pre-Agile world, QA managers mainly held the accountability on quality. As the leaders of the test departments, QA managers were known as the main focal point for all quality issues found during the SDLC and for defects found in customer environments. In Agile, QA managers are not the quality officers anymore. Scrum teams are now accountable for the quality of their deliverables as a group and not as individuals.

Let’s take one classic example of a defect found in a production environment. In a traditional SDLC,` the QA manager was the one responsible for providing answers on why his team failed to find this issue and what mitigation plan he has to ensure that similar defects will not occur. Now, in an Agile environment, a similar issue is handled differently. Once the defect is discovered, the entire Scrum team (or specific people) will understand what was missed during the iteration and how similar cases can be avoided.

This is why QA managers do not belong to Scrum teams and cannot be team members with this title. I saw many teams use this role in their team to try to keep some old habits. The direct result was that the QA managers—as team members—held the responsibility for quality failures instead of letting the team take responsibility and grow from it.

Progress and monitoring

In Agile teams, there is no need for a QA manager to monitor the testing progress. The Agile framework allows the organization and other stakeholders to see the team's progress using visual boards, backlogs, and burn-down charts.

QA managers lost their ability to see the big picture of the testing project as they did in a traditional testing project. Scrum teams are now accountable for communicating and reporting their progress, providing their estimations as a mandatory part of the Agile methodology. There is no need for a QA manager to act as an observer.


In Scrum, the leading Agile framework, there are three main roles, with no room for managers: development team, Scrum Master, and product owner. The Scrum team is self-managed and cross-functional, so they can take responsibility for all aspects of the project, including delivering high-quality products. This eliminates the need for a traditional QA/Test manager. However, all three of the roles specified by the Scrum framework are available to QA managers.

QA manager -> product owner

The first option, which is less common, is QA managers who become the team’s product owner. This new role is completely different from what they did as QA managers. Although it is less common, I’ve met QA managers who become very efficient POs and some who failed miserably.

QA manager -> Scrum development team member

Yes, you will be amazed to know that QA managers (especially ones who managed small teams in the traditional environment) decide to become one of the development team members in many cases. This means they act as equal testers/developers (depending on their technical skills) without authority over other team members.

QA manager -> Scrum master

This is probably the most common option for QA managers. Organizations do not know how to handle SM during an Agile transformation, but because this role is a valid option for a QA manager, why not keep things calm and let the QA managers do it. This allows QA managers to take a real and active part in the transformation with minimal impact on their ego.


While there are three main roles that QA managers can take in the Scrum framework, that may not be an option for some who want to keep their ability to influence more, as they did in the traditional world.

Based on my experience, I will share some other options that I see in organizations without determining if they’re right or wrong. Remember that every organization has its own needs and what fits one organization may not be suitable for another.

Integration team manager

Organizations have multiple Agile teams, each responsible for specific features. The problem here is that no team can see the big picture of the whole product.

The solution is to create an integration team that will get the deliverables of all the Scrum teams and tests them as a whole using end-to-end testing. A QA manager manages this type of team as in the traditional working environment.

Automation team manager

Depending on the technical skills of the QA manager, in some cases, they become the manager of the team responsible for building the automated frameworks that Agile teams use to automate their work and processes.

Quality Consultants

This role may be titled differently from one organization to another. The common names for this role are a technical leader and quality architect. In this role, QA managers use their vast experience in the quality field to help the new Agile teams handle all quality issues as external consultants.

QA managers in an Agile team

This is the worst thing that can happen to the organization, the team and the QA manager, but it still occurs when the organization does not handle the transformation process. The organization will want to ensure that the product quality is not affected once the test department is broken down and integrated into small Agile teams.

As a result, they will want to keep their ability to affect the team by keeping the QA managers in the new Agile teams. This is a major point, so I want to add another factor to the equation, and that is the organization and team maturity in Agile, AKA “Scrum Level,” as described in this simple flow chart:


As we‘ve seen, the shift from a traditional working environment to an Agile will significantly impact QA managers. QA managers can add real value to the business if they understand that they must change to remain relevant in a completely different world from what they used to know.

Therefore, the big question remains: What can QA managers do in an Agile environment. I will review some of the ways QA managers can add value to the business if they have the personality to make the personal transformation.

Help build new cross-functional team.s

Self-organized Agile teams are the center of the Agile concept, but this does not guarantee that they have the necessary technical skills to handle the challenges during a development project.

To ensure that Agile teams perform at the highest level, the organization must ensure that they build their Agile teams with the necessary expertise that will allow them to handle all the different challenges of a development project.

However, this is not an easy task at all. We need to remember that each Agile team has its area of expertise. One team may focus on the product's user experience (UX), while another team may focus on the performance and functional aspects of the software. Therefore, each team should be built with people who have the relevant knowledge and skills that will allow the team to meet the project goals.

QA managers can contribute to building these teams due to their vast knowledge in testing and the personalities of their testers. QA managers will also help testers integrate into their new team and help them understand their new responsibilities, roles, and boundaries.

Process improvement and optimization

Great QA managers should allow the organization to maximize the benefits of Agile. Based on their experience and knowledge, QA managers should monitor the Agile processes and strive towards improving them.

For example, QA managers could:

  • Participate in technical meetings to see how to reduce risks

  • Help the team create functional user stories

  • Work with the PO to define DOD criteria

  • Create and implement quality standards

  • Offer suggestions that will lead to a robust development process

  • Implement new test/development practices to improve testing/coding standards

QA managers as transformation leaders

QA managers can become the leaders of or the biggest impediments to an Agile transition. An Agile transition may take several months or even years to complete. I have never seen an organization that stopped continually improving the process. During this time, many issues and impediments will affect the organization’s ability to maximize the advantages of Agile.

QA managers can be the organization's change agents by removing impediments that prevent the teams from reaching their full potential. In addition to facilitating a Scrum implementation within the organization and training their team on Scrum practices, they can:

  • Help teams acquire resources (hardware/software)

  • Remove impediments that are beyond the ability of the team

  • Create a safe environment that will increase confidence among the team

  • Motivate employees by identifying their unique motivation triggers

  • Make room for failure and use it as a growth engine for the team

  • Promote continuous improvement

Promote testers’ professional development

Managers should ensure that all Agile teams, especially their testers, grow as quality owners. By being the quality expert, the classic work of a QA manager is to ensure that testers continue to learn and develop even when divided among the different teams.

QA managers should provide technical lessons about quality practices, support testers in times of crises, mentor testers on how to perform their jobs in a new environment and ensure that they do not lose their identity.

Lay the ground rules for testing cross-organization

QA managers do not have authority over the Agile teams, especially not on the testers under their direct management before shifting to Agile. QA managers will have to learn to let Agile teams grow in their path to becoming self-organized, independent and strong teams.

However, this is not anarchy; if there were two main departments (QA and development), we would have tens and even hundreds of new Agile self-managed Agile teams. To ensure that all the teams are keeping to the same quality standards as they do in the traditional environment, there must be clear guidelines and ground rules that all teams must follow.

This is where the QA manager can help and use his experience, knowledge and technical excellence to set specific quality guidelines. The guidelines may include what testing methods the teams should use, testing tools, automation strategies, testing standards and the overall test methodologies to apply.

Cross-functional testing

In multiple Agile teams, each team is usually focused on its feature without knowing what other teams are doing. This means that each Agile team will develop, test and deliver an incremental working functionality at the end of each iteration.

The approach that each Agile team is responsible for a specific part of the project has many advantages but still one major problem. The problem arises when no one sees the big picture and all teams’ deliverables are integrated into one complete product.

QA managers (or any other new title) can perform cross-functional testing (AKA end-to-end testing) to ensure that the integration between teams works as expected.

In addition, QA managers can provide insights into the overall product quality based on their test results and this is one major responsibility.

The authority for all quality issues - The business must have the authority to quickly resolve all quality issues that may arise during the Agile development process. QA managers are the best candidates to take this role and act as the quality focal point of the organization. As part of this role, QA managers will hold the following responsibilities:

  • Act as the point of contact for all quality issues

  • Mitigate quality issues that arise during retrospectives

  • Mitigate all quality issues that arise from lack of communication

  • Provide quick feedback on the quality of the team deliverables

  • Resolve conflicts related to the defect life cycle (DLC)

  • Create learning sessions on technical gaps

Set the quality metrics

One thing that is very common among organizations that started an Agile transformation is the fear of downgrading the quality of their deliverables. This is a very logical fear because the quality ownership under the QA manager's direct responsibility is now spread among the multiple Agile teams.

To overcome this fear, the organization should ensure that it has the right quality KPIs, which will provide the crucial ability to measure the major quality aspects of an Agile working environment.