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?
A FEW FACTS ON THE CURRENT SOFTWARE INDUSTRY
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.
QA MANAGERS PRE-AGILE
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:
Controls all major aspects of the project (timelines, pace, task assignments)
A strict hierarchy of authority (the manager at the top of the pyramid)
Micromanagement led by a lack of trust between the manager and his employees
Zero tolerance for mistakes made by his employees
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.
QA MANAGERS POST-AGILE
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.