A hallmark of Agile development is the “whole-team” approach. On Agile teams, it’s not only testers or a QA team who feel responsible for quality. Every team member, including
To paraphrase Elisabeth Hendrickson’s definition, Agile development is delivering business value frequently, at a sustainable pace, while adapting to changing business needs. This is the job of the whole team, not just testers or designated QA professionals. Tests drive coding from the unit level on up, and testing helps the team learn how the application should work, or when we’re “done” with a particular user story. And, again quoting Elisabeth, testing isn’t a phase. It’s an integral part of software development, just as important as coding.
Agile project teams
Each Agile team must possess all the skills needed to produce high-quality code that provides the required features. While this often means including specialists on a cross-functional team, such as expert testers, it doesn’t limit particular tasks to designated team members. Any task may be taken on by any team member or pair of team members. The whole team takes responsibility for all testing activities, such as automating tests and doing manual exploratory testing. As a result, the whole team thinks constantly about designing code that makes these tasks easier to complete. They work together to keep technical debt at a manageable level.
The whole-team approach requires constant collaboration. Testers work together with programmers, customers and other team specialists, not only for testing tasks, but activities such as building infrastructure and designing code for testability. Anyone may ask for, and receive, help at any time. Team members have a range of skill sets and experience, and apply these to solve challenges such as how to elicit examples of desired system behavior from customers and turn those into tests. Diverse viewpoints mean better tests and better quality.
You don’t have to work on an Agile project to collaborate with people in different roles. When I worked as a tester on traditional phased-and-gated projects, I used my own initiative to get myself invited to requirements and design meetings. I developed personal relationships with programmers to start testing long before the “coding” phase was over. But, as Janet Gregory and I point out in our book Agile Testing: A Practical Guide for Testers and Agile Teams, there is a difference between having team members “representing” their functions in a cross-functional team, and becoming true team members of the team for as long as the team exists.
Agile teams vary in structure according to the size and nature of their projects. Large companies with several large concurrent projects may choose a matrix-type structure, where people from different functional areas form a virtual team but still report officially to their individual departments. Some people with unique, specialized skills, such as security experts, might need to be shared among several teams.
In my experience, having a permanent cross-functional team is preferable to a matrix organization. Learning to truly work together as a team takes years. If projects are short and teams are constantly changing, it’ll take a few iterations in each new project for members of the new project team to get used to working with each other. As we say in Agile Testing, “The best teams are those that have learned to work together and have developed trust with one another.”
Challenges in the mainstream
Early Extreme Programming (XP) teams were generally small and co-located. The principles and values of XP, as well as the physical workplace layout they encouraged, helped my first XP team to proactively adopt a whole-team approach. Working in an open team room with pairing stations made it seem natural for me to pair with a programmer writing unit tests. When I needed help automating GUI tests, a programmer was always on hand. We learned together that customers own external software quality, and helped them capture their quality criteria as tests.
As Agile has grown into the mainstream and larger companies adopted it, the old role silos – development team, QA team, analyst team – are often replaced by Scrum team silos. This causes new problems: each team is re-inventing the wheel, not sharing knowledge and expertise. A whole-team approach to quality within one team is good, but the commitment to quality has to extend throughout the company. Coordination practices such as a daily Scrum of Scrums to address impediments help. Communities of practice (CoP) for each role help drive inter-team communication. For example, everyone interested in testing can share techniques and ideas through a testing CoP. If one team implements successful automated CI, they can demonstrate that to all the other teams.
Large teams, especially where members are distributed geographically, bring a new dimension to the whole-team approach. Building trust among dispersed team members takes creativity and true commitment. We have to work harder to bridge the gaps, taking advantage of technology that keeps us connected by video, wikis and screen sharing.
Regardless of challenges, the whole-team approach has proven time and time again to provide organizational benefits. In part two of this series, I give specific real-life examples of how my team has benefited from the use of the whole-team approach and explain why this approach will prove valuable both to your organization and to your customers.
This was first published in September 2011