What makes a team really "Agile"? To me, an agile team is one that follows the simple 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 it’s frameworks (Scrum, EP, Lean Etc.), it’s still not a religion that the team should follow blindly.
An Agile team should have the power to learn new things. They should combine artifacts that work great in other frameworks, innovate new development techniques and find the balance between an Agile Spirit and what is more practical that works for them.
There is one thing an Agile team must follow and that is the simple mission that the customer is the most important stakeholder. Therefore the team should always focus on making on delivering the best possible product that meets the customer’s requirements.
From my experience, if a team focuses on this single mission. It will formulate a team that will deliver the best quality product. In addition, the team will become disciplined (work as a single unit), always search for new learning materials to help them succeed with the project goals. Most importantly it would allow them to share their knowledge, experience, and skills with each other.
In conclusion, the most successful projects are those who focus on customer requirement, have a team of great people who worked together without any ego and senior management allow the team to maximize both their technical and personal abilities.
AND WHAT ABOUT THE QUALITY OWNER?
Starting from the end, there is a reason I wrote this long introduction. If you focused on it, it should be clear to you why there is not "Quality" officer in a Scrum team. This is because it goes against the whole idea of collaborative work. Quality is a state of mind, it starts from the very basic phases which involve all team members. If done correctly, the quality ownership jointly shared among all team members and not only the tester.
From my personal point of view, the Agile tester is just a new role name created to allow a more efficient transformation from traditional methodologies. Think about a company that worked in waterfall SDLC. The company had 100 pure testers in a single department, now the organization decided to start transitioning to Agile SDLC. This results in massive concerns rising from this department (You will see it in any transitions) about what their role will be in the new Scrum teams.
One option is to release all testers that are not suitable to work in this methodology (Believe me that if it was simple, you will saw it more often). This is least preferred option by most organizations. The second option, often used, is to "Sell" these kind of employees as "Agile Tester", "Quality Champion", Quality enforcer etc. (Ask yourself are there new names for other crucial roles such as "Agile Developer", "Agile DBA" or any other names that may sound better but just the same).
Let us be clear, the set of skills and personality that make someone great as a Tester within an Agile team is almost the same as those used in other SDLC methodologies. The main difference is that in an Agile team, the Tester is part of a wider team that includes also developers, analysts, DBA's and sometimes even other testers.
In addition, the Agile tester should not see himself as the team quality officer and this takes the responsibility for all quality related issues (It is a catastrophe ready to happen).
Throughout my career, I have seen many failed teams seeking to “protect” customers from "terrible" team members who do not know enough about quality. From an Agile perspective, this is the last thing you want to hear from one of your team members.
A true tester in an Agile team (If it easier for you, call it an agile tester (AT)…) is a person who has the knowledge and experience to know that quality is related to all aspects of the project. Part of this includes full stakeholders involvement. If there are missing quality aspects, it’s become his responsibility to gather and share information about the missing quality artifacts. As part of this process, the AT can do it with the other team members or/and the product owner. The AT can also act as a bridge to other quality issues that may affect other teams.
Testers in Agile teams, as well as other team members who have the right skills and mindset, are continually looking for new ways for the team to do a better job of producing high-quality software. The main point here is to know that any team member can do it, this function/responsibility is not solely owned by the agile "Tester". It should be the effort of the entire team.
To conclude: the best Agile groups were built by developers, without any pure testers who had the current state of mind and understanding of the importance of quality.
TESTERS IN AGILE TEAMS, WHAT’S NEXT?
As I described at the beginning of this article, testers in Agile teams are just another team member who contributes to the main goal. Testers are not quality officers and are not solely responsible for the quality deliverables. The bottom line is Agile teams should include personnel 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 handle only testing issues. This would be a Hugh mistake for both them and 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 (as long as they have the necessary skills, experience, and knowledge).
Agile teams can benefit from their testers (again, only if they have what it really takes to be part of the team) in many different areas such as:
- Testers can provide some great insights into what it takes to improve the quality of the product.
- Testers can help to define the "Definition of Done (DoD)" of user stories.
- Testers can add creativity and new ideas to perform a robust testing process.
- Testers can help the team to design, Write and execute both manual and automated tests.
- Testers can help the team to understand the testing scope of PBi's to provide better time estimations.
- Testers can participate at all levels of the project and add their vision about the project requirements, Design and testability.
- Testers have an instinct and wide understanding of where and how the software might fail. Therefore, can assist the team developers to write a better code.
- Testers can help other team members to write tests in different testing layers (Unit, Component, integration, and system).
- Testers should have a wide perspective and vision about the product, as such, they can assist the team and the PO to create more elegant solutions.
- Testers can do test reviews for other team members to ensure good coverage and testability.
Comments
Post a Comment