Hi Chris. It was great to have you in Beijing and you provided us with awesome Certified Scrum Master and Certified Scrum Product Owner trainings. We are having internal discussions about the role of quality engineers in scrum. Should they be on the scrum teams? Do we need quality engineers if we are doing scrum? If we have them, who should manage them? Should we move them around from team to team?
Have Quality Engineers on the Scrum Team
Scrum is based around cross-functional teams. This means we want each team to have all of the skill areas necessary to take a deliverable from concept to delivery. For software products, this usually means we need people skilled in design, architecture, various types of coding, as well as testing. It is too much to expect every team member to be highly skilled in all areas; instead we have specialists on the team, each of whom has a core competency in one (or sometimes more) of the skills we need to get the work done. While these people are specialists, we also want them to be flexible enough to do work outside their area of specialty. Sometimes a C++ developer will write test automation. Sometimes a tester will do requirements analysis, and so on. We often call these people “generalizing specialists.”
So is quality engineering needed? For most of the scrum teams I’ve worked with, the answer is yes, we need to have quality engineers on the scrum team. They bring special skills and a quality-centric view to the work. Are they the only ones who can do testing? No, when the team needs more testing than our QE specialists can do, other team members will help out. Is testing the only thing our quality engineers will do? No, it is likely the team will need them to make other kinds of contributions from time-to-time. Remember, for every scrum team member, their main goal is the same: deliver the stories that the team committed to this sprint!
Who Should Manage the Quality Engineers on a Scrum Team?
So now that we’ve decided we probably want quality engineers on the scrum team, who should they report to? It’s probably best that they report to someone who is, or was, a quality engineer. Think about what we want a manager to do. We want the manager to help the employee grow so their contribution to the company continues to increase. We also want the manager to be the employees’ go-to person for all human resource issues such as: performance review, vacation approval, and career growth. Who better understands how to be a great quality engineer than someone who is themselves a great quality engineer? Another benefit of having the quality engineers managed by other quality engineers is that the manager becomes someone who can coordinate QE practices across scrum teams. There are many decisions to make regarding what tools we will use, and what practices we want to adopt across the organization. To best make these decisions, we want our QE people to regularly discuss these areas and make coordinated decisions. A manager is a logical person to make all of this happen.
The quality engineers across the organization will want to spend time with each other, so that they can coordinate the various ways that quality engineering work is being done. In these bigger gatherings of QE people, they can make decisions about what tools, techniques, and practices to adopt and standardize on. They can learn from each-others’ experiences and evolve the way quality engineering is being practiced. So we want to have quality engineers on the scrum team, and we want them to have time to meet and work together outside of the team, in order to coordinate and improve how they work.
It can be very useful for individual skill and career growth, to have people report to managers who have the same skill set. Thus, quality engineers will be managed by quality engineers. Java developers will be managed by someone who knows Java development well, and so on. This sets up a bit of a matrix situation. The manager is responsible for helping their direct reports improve their skills and grow, as well as typical administrative task such as approving vacation requests. The team’s product owner, however, sets the business direction and decides the order of the stories the team will be asked to deliver.
Avoid Moving Quality Engineers Between Teams
In general, we find that having stable teams, where the same team members stay on the team for long periods of time, seems to work best. This may seem a little counter-intuitive at first. Traditional project management has included the practice of moving people with the right skills to whatever project needed those skills at the moment. If we were machines, this would work great. But we are not machines. We are teams of human beings, and it takes significant time working together for a team to start to gel, and become high-performing. One popular model for how this happens is the Tuckman model which states that teams go through four distinct phases over time: forming, storming, norming, and finally, performing. It turns out that within some reasonable bounds, a team that has been together and made the journey to high-performing will produce more value than a team of experts who have just been pulled together. For this reason, we generally want to keep the same people together as a team for as long as we can.
What are your experiences and opinions on incorporating quality engineering in scrum? Leave a comment and share!