Many questions arise when an organization starts the transformation to an Agile environment, some related to the adoption of 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. In this post, I will focus on QA or test managers and describe the transformation from traditional QA manager. 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 really need a QA manager in an Agile project?
- Who is responsible for ownership on 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 for 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 are seeing 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 be able to keep them.
Fact 5: Agile transformation affects all layers of the organization, but the role of managers (and QA managers in particular) is the one affected most.
QA managers pre-Agile
To best provide the answers to the questions above, I’ll start with a quick review on 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…
The traditional manager’s management style is mostly based on the “Command & Control” method, defined, according to the Cambridge Dictionary, as “a situation in which managers tell employees everything that 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 own 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 own departments, groups, and teams that they could manage, depending on the hierarchy of the organization. Roles like a quality director, test group leader, and the 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 helped QA managers do their job:
- There was a dedicated testing phase that started only when the development phase was completed, which reduced the risk of multiple code modifications as occurs in an Agile environment.
- QA managers and their teams received comprehensive requirements documentation (specs, SRS, etc.) that allowed them to see the big picture of the whole project. 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 both the entry and exit criteria for the testing process.
In the pre-Agile era, the ownership on 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 chose how to manage the testing risks based on their own 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. In this part, we 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, back in the old days of the Waterfall development process, QA managers had their own departments, groups, and test teams. 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 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 day-to-day direct management of testers
In an Agile environment, testers are integrated into the Scrum teams, and Scrum teams are self-organized; as such, 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:
How and when are requirements delivered?
Heavy SRS/specs that specify all the project requirements at the beginning of the project
Small user stories that describe a small requirement. Not all stories are written at the beginning
QA managers and their teams create two main documents: Software Test Plan (STP) and Software Test Design (STD), which specify all aspects of the testing project (test environment, test strategy, risks, etc.)
All tests are written at the PBI level, and there is less room (if any) for traditional test documentation.
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 that were 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 to provide 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 in the team) will try to 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 failures of quality 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 any other stakeholder to see the team 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, and there is no need for a QA manager to act as an observer.
New roles for QA managers in the Scrum framework
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 that of 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.
For more information about the role of the product owner:
QA manager -> Scrum development team member
Yes, you will be amazed to know that in many cases QA managers (especially ones who managed small teams in the traditional environment) decide to become one of the members of the development team. This means that they act as equal tester/developer (depending on their technical skills) without any authority on other team members.
For more information about the role of the development team:
QA manager -> Scrum master
This is probably the most common option for QA managers. During an Agile transformation, organizations do not know how to handle this role called SM, 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 to their ego.
For more information about the role of the scrum master:
What other options do QA managers have in an Agile environment?
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 there is no team that 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 test them as a whole using end-to-end testing. This type of team is managed by a QA manager 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 that is responsible for building the automated frameworks that Agile teams use to automate their work and processes.
This role is 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 know how to 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:
Defining the role of the NEW QA manager
As we‘ve seen, the shift from a traditional working environment to Agile will have a major impact on QA managers. QA managers can add real value to the business if they understand that they must change to remain relevant in a world that is completely different from what they used to know.
Therefore, the big question here 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 that allows them to make the personal transformation.
Help build new cross-functional teams
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 that may arise 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 own area of expertise. One team may focus on the user experience of the product (UX), while another team focuses 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 have a major contribution in building these teams due to their vast knowledge in testing and in the personalities of their testers. QA managers will also help testers integrate into their new teams, as well as help them understand their new responsibilities, roles, and boundaries.
Process improvement and optimization
Great QA managers should be able to 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. In fact, I have never seen an organization that stopped continually improving the process. During this time, there are many issues and impediments that will affect the organization’s ability to maximize the advantages of Agile.
QA managers can be the change agents of the organization 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
QA manager should ensure that all Agile teams and especially their testers continue to 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 any authority over the Agile teams and especially not on the testers that may be under their direct management prior to 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 in the past there were two main departments (QA and development) now we have tens and even hundreds of new Agile teams that are self-managed. To allow the business 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.
In an organization of multiple Agile teams, each team is usually focused on their own 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 there is no one who sees the big picture and how all teams’ deliverables are integrated into one complete product.
QA managers (or any other new title) have the capability to perform cross-functional testing (AKA end-to-end testing) to ensure that the integration between teams works well as a whole product.
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
It is hugely important that the business has an authority who can 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 that 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 that was under the direct responsibility of the QA manager 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.
This is where QA managers help the business by defining the quality KPIs and trends among the different teams. Let us review some classic examples:
- The number of bugs and their severity per iteration
- Team velocity compared to team capacity
- How many stories meet the DOD
- Defects found in production/customer environment
- Time to market
- Number of effective meetings
- Defects found due to miscommunication between teams
Quality metrics have another great advantage: they allow the organization to identify the weakest and most problematic areas in the process and make the necessary changes to ensure that they meet the quality standards.
Thanks to Tally Helfgott for proofreading 🙂
Source: ministry of testing
The changing role of QA managers in the Agile environment | SupremeAgile