Reasons Agile Teams Do Not Use Testers as Quality Officers | David Tzemach
What makes a team really Agile? To me, an Agile team is one that follows the values and principles of the Agile Manifesto but knows how to take them a step further. Although the Agile Manifesto created the foundations of all its frameworks (Scrum, Kanban, etc.), it is still not a religion that the team should follow blindly.
An Agile team should learn new things. They should combine artifacts that work well in other frameworks, invent new development techniques and find the balance between the Agile spirit and what is practical for them.
There is one thing an Agile team must follow, which is that the customer is the most important stakeholder. Therefore, the team should always focus on delivering the best possible product that meets the customer’s requirements.
In my experience, if a team focuses on this single mission it will deliver the best quality product. In addition, the team will become disciplined (work as a single unit) and always search for new knowledge to help them succeed with the project goals. Most importantly, it allows them to share their knowledge, experience, and skills with each other.
The most successful projects are those which focus on customer requirements, have a team of great people who work together without any ego, and senior management allows the team to maximize both their technical and personal abilities.
From this, it should be clear why there is no single quality officer in an Agile team. This is because it goes against the whole idea of collaborative work. Quality is a state of mind. It starts from the basic phases, which involve all team members. If done correctly, quality ownership is jointly shared among all team members and not possessed by a single person.
To be clear, the set of skills and personalities that make someone a great tester within an Agile team is almost the same as those used in traditional environments. The main difference is that in an Agile team, the tester is part of the wider team that includes developers, analysts, DBAs, etc.
Agile testers should not see themselves as team quality officer because they are not. In fact, when this happens and a tester claims this title, it usually leads to one or more of these issues:
It is a slippery slope for many arguments and personal issues between team members and the last thing we want to see in an Agile team based on trust, collaboration, and respect.
The tester doesn't really understand their role in the team and takes ownership of an area that they cannot really manage, without sharing it with the rest of the team.
The tester doesn’t understand what it means to be part of an Agile team based on the values of collaboration and shared responsibilities.
It is the first sign of the creation of mini-waterfalls within the sprints, where the rest of the team reduces their responsibility for testing expecting that the tester will do it all.
No matter how good and experienced the tester really is, they cannot monitor and track all the work done in a sprint that may involve the development of multiple features at once.
It preserves the old testing mindset that does not allow the team to embrace the core concepts of Agile testing that are so crucial for their long-term success.
Bear in mind that testers in Agile teams are just other team member who contributes to the main goal. Testers are not quality officers and are not solely responsible for the quality of deliverables. The bottom line is that Agile teams should include people who have the relevant skills and knowledge to meet the overall goal of the project as well as quality objectives.
Testers in Agile teams, like their Agile teammates, enjoy acquiring new knowledge and skills that allow them to undertake new challenges from project to project or even from sprint to sprint. Testers should not limit themselves to only handling testing issues.
This would be a real mistake both for them and for the team. Testers must view themselves as equal to any other team member that can address any kind of issue that might arise during the project (if they have the necessary skills, experience, and knowledge).
Agile teams can benefit from their testers in many different areas:
Testers add creativity and new ideas for a robust testing process.
Testers can help define the Definition of Done (DoD) of user stories.
Testers have an instinct and a wide understanding of where and how the software might fail. Therefore, they can help the team developers write better code.
Testers should have a wide perspective of the product. As such, they can help the team and the PO create solutions that are more elegant.
Testers can participate at all levels of the project and add their vision about project requirements, design, and testability.
Testers can help the team understand the testing scope of backlog items to provide better time estimations.
Testers can do test reviews for other team members to ensure good coverage and testability.