We generally try to match the skills of a team with the type of work that we're asking that team to do. This can mean that as the nature of work changes, the teams shifts in response. I was recently asked for my views on whether a team could reduce the number of testers they had. I found that I was quite unprepared for the conversation.
How do you know whether you can remove a tester from an agile team?
As with most things, I don't think there are definite rules here. However, having though a lot about how you'd decide whether to remove a tester, I think there's value in a general set of questions to ask. I see five areas to consider: team dynamic, support for quality, context beyond the team, measurement and bias.
The first thing to do is make the question personal. You want to consider the real people who will be impacted by the decision that you're making. There may be multiple faces to removing a tester: think about the team that they leave, the team that they move to, and the experience of the individual themselves.
Team Dynamic
You never remove a tester though, you remove a person and that person is unique.
The first thing to do is make the question personal. You want to consider the real people who will be impacted by the decision that you're making. There may be multiple faces to removing a tester: think about the team that they leave, the team that they move to, and the experience of the individual themselves.
How many testers do you have in the team? Are you removing the only tester?
Are you removing the tester role or testing as an activity? Are there, or will there be, others in the team with testing experience and knowledge, even if not testers? How will other people in the team feel about adopting testing activities? What support will they need?
Are you replacing the tester in the team with another person? What will their role be? How will the change impact specialist ratios within the team?
If the person is being moved to a new team, what opportunities exist for them there? How will their skills and experience match their new environment? What impact do you expect this change to have on the team that they are joining? How will the people in that team have to change their work to accommodate a new team member?
Are you removing the tester role or testing as an activity? Are there, or will there be, others in the team with testing experience and knowledge, even if not testers? How will other people in the team feel about adopting testing activities? What support will they need?
Are you replacing the tester in the team with another person? What will their role be? How will the change impact specialist ratios within the team?
If the person is being moved to a new team, what opportunities exist for them there? How will their skills and experience match their new environment? What impact do you expect this change to have on the team that they are joining? How will the people in that team have to change their work to accommodate a new team member?
Support for Quality
If you remove a piece from a Jenga puzzle, will it fall? The impact depends on what it supports.
The quality of your product doesn't come from testing alone. There are many activities that contribute to creating software that your customers enjoy. It's important to determine the depth and breadth of practices that contribute to quality within the team that you're looking to change.
What level of test automation is available to support the team? Is it widely understood, regularly executed and actively maintained?
What other practices contribute to quality in the team? Pair programming? Code review? Code quality analysis? Continuous integration? Business acceptance? Production monitoring? To what extent are these practices embedded and embraced?
What does the tester do outside of testing? What sort of impact do you expect on the social interactions of the team? Agile rituals? How about depth of product knowledge? Customer focus? These things may not specifically be test activities or skills, but do impact quality of the product.
What other practices contribute to quality in the team? Pair programming? Code review? Code quality analysis? Continuous integration? Business acceptance? Production monitoring? To what extent are these practices embedded and embraced?
What does the tester do outside of testing? What sort of impact do you expect on the social interactions of the team? Agile rituals? How about depth of product knowledge? Customer focus? These things may not specifically be test activities or skills, but do impact quality of the product.
Context beyond the team
It would be interesting to understand their motivation behind asking that question.
The wider context to the change you are making will have significant impact on how people feel about it. You should consider what your underlying reasons are, how people will feel about those reasons, and how far-reaching the implications of your change could be.
What’s the context of the movement being made? In Dynamic Reteaming, Heidi Hefland talks about five different scenarios in which you may want to change a team:
- Company growth
- The nature of the work
- Learning and fulfilment
- Code health
- Liberate people from misery
Is one of these applicable? If not, can you succinctly explain what your reason is? How is this wider context being viewed by the team(s) involved? Are they enthusiastic, cautiously optimistic, or decidedly negative?
What is the composition of surrounding teams? Similar or different? How will that impact the outcome? If I’m part of the only team without a tester, or the only team with a single tester, what impact will that have?
If there are governance processes surrounding release, is the person who approves change to production supportive of the change to the team? Will that person still have confidence in what the team deliver?
Measurement
How do you know what quality is now?
As with any change, it's important to understand how you'll track the impact. Changing the way that a team approach testing could impact both the quality of software they create and how they feel about the work they do, in a positive or negative way.
What metrics help you determine the quality of your product? If quality decreases, how low is acceptable? What is your organisation’s appetite for product risk? How many production bugs can the reputation of your organisation withstand?
What metrics help you determine the health of your team? If productivity or morale decrease, how low is acceptable? What is your organisation’s appetite for people risk? What impact will the change have on happiness and retention of other roles?
What metrics help you determine the health of your team? If productivity or morale decrease, how low is acceptable? What is your organisation’s appetite for people risk? What impact will the change have on happiness and retention of other roles?
Bias
How would someone else answer these questions?
Remember the bias we have that impacts our answers.
The final point to remember is that you don't want to consider these questions alone. A manager who sits outside a team may have quite different answers to a person who works within it. The tester who is being moved will have opinions. Whoever is ultimately responsible for the decision should also think about how other people would respond to the previous prompts.
When I'm asked whether or not we can remove a tester from a team, I often have an immediate and intuitive response that is either positive or negative. Now that I've thought about what contributes to this decision, I will be able to articulate the reasoning behind my instinct. Team dynamic, support for quality, context beyond the team, measurement and bias; five pillars that I'll be using in my next conversation.
When I'm asked whether or not we can remove a tester from a team, I often have an immediate and intuitive response that is either positive or negative. Now that I've thought about what contributes to this decision, I will be able to articulate the reasoning behind my instinct. Team dynamic, support for quality, context beyond the team, measurement and bias; five pillars that I'll be using in my next conversation.
Thanks to Remi Roques, Kathy Barker, David Greenlees and everyone who responded to the initial thread on Twitter for helping to refine my thoughts on this topic.
Thanks for a very insightful article. Since Agile puts so much emphasis on the "team", any change in the team composition needs to weigh the pros & cons and this articles nice sums up that thinking in the context of removing or replacing a tester in an Agile team.
ReplyDeleteWhile i believe in the "everyone should be a tester" philosophy, i strongly believe in a test-first approach to software delivery, so even if testing automation is in place, teams rely on solid testing scenarios supporting all aspects of acceptance criteria, well before development starts. So to me, agile testers have a central place in the process.
ReplyDeleteI advocate BDD as well, and you couldn't have "3 amigos" without testing experts.
At CAST2016 Jesse Alford shared the Pivotal approach, which challenged my views in this area. He spoke about the "3 amigos" as being Engineering, User Experience, and Project Management. This is a model that Pivotal actually use and Jesse, from a testing background, was relatively positive about it. I'd encourage you to watch the recording of his talk, available here: https://www.youtube.com/watch?v=1gLdYF_1NDg
Delete