The agile whole team approach transforms the roles of the agile team
In part one of this article, I discussed how my organization changed the way we practiced scrum and why to make quality a whole team responsibility. Now, we’ll take a look at how to make quality a whole team responsibility—through changes in team members’ roles, swarming, and zero bug tolerance.
Changes in Roles
When moving to the whole team approach, functional teams must look beyond the core set of duties they have had in the past. Development will not just code anymore; QE will not just test that code anymore; and Information Development will not just document that code anymore.
Development team members can expand their role to do some or all of the following:
- Work with the team to define acceptance tests for the feature they are building.
- Include QE and Information Development estimates in user story and task estimates.
- Consistently write and execute unit tests for all code they write.
- Work directly with testers to fix bugs as soon as possible, whenever possible.
- Work directly with testers to set up automated tests.
- Volunteer to run test cases.
- Perform usability tests.
- Set up virtual environments for Information Development.
- Write the first draft of documentation for the user story.
- Participate in backlog grooming (adding, removing, or modifying user stories as necessary, prioritizing user stories, and providing estimates for user stories in the backlog).
In addition to expanding the task they take on, the Development team should strive to manage their current tasks more effectively. In particular, Development should not start on the next sprint’s user stories if this sprint’s user stories are not done.
QE team members can expand their role to do some or all of the following:
- Define acceptance tests that are from the customer viewpoint, then help guide Development with those tests.
- Include QE estimates in user story and task estimates.
- Ensure the code design and relevant APIs support automated testing.
- Ensure the team is doing the right kind of testing and working to eliminate manual testing.
- Work with Development to resolve issues immediately.
- Perform usability tests.
- Set up virtual environments for Information Development.
- Write the first draft of documentation for the user story.
- Participate in backlog grooming.
As part of their commitment to existing tasks, QE should not try to push the testing of a user story into the next sprint.
ID team members can expand their role to do some or all of the following:
- Assist in the definition of acceptance criteria that fully define the function you plan to document.
- Include Info Dev estimates in user story and task estimates.
- Plan work to get documentation done by the end of each sprint.
- Define dependencies with milestone dates in user stories as needed.
- Perform UI reviews and usability tests.
- Volunteer to run test cases.
- Participate in backlog grooming.
Sometimes, QE and ID team members are shared between projects. Therefore, sometimes the right thing to do is work on another project when you finish sprint work for one project.
Swarming
To make the whole team approach successful, QE and ID team members need to have the right support and training to adapt to the fast pace of agile development. Collaborating closely with other team members might require those team members to acquire new skills, and it’s important to give them time to do so. One way to accomplish this is by swarming.
Swarming involves the whole team working on a problem or user story together before moving onto another story. Rather than having team members work on pieces of multiple user stories, focusing the team on one or two user stories at a time fully completes more stories. Oleksi Derkatch, a software developer that often blogs about agile practices, states, “It’s better to have 80% of the features 100% done, instead of having 100% of the features 80% done.”
Feature testing, regression testing, and documentation must occur throughout the sprint, not just at the end of the sprint, and swarming supports this continuous process. If your team has a testing or documentation crunch at the end of the sprint, you are doing something wrong – find out what it is and fix it for future sprints. Some possible reasons for a crunch like this include the following:
- You have not automated your testing.
- There was not enough information given to the QE and ID team members early.
- Coding was scheduled until the very last day of the sprint.
- There were last-minute scope cuts that had to be handled in the documentation.
Zero Bug Tolerance
The goal of each agile sprint is to have potentially shippable product at the end of that sprint. If a piece of the product is potentially shippable, it has to be coded, tested, and documented. Therefore, all stop-ship bugs must be resolved during that sprint. In addition, you should resolve any real bugs during the sprint that you can. Otherwise, the user story is not done. Each time bugs or unresolved documentation escape from the sprint, technical debt increases. Ignoring bugs when they happen and fixing them later is much more expensive, requires much more work, and is very frustrating.
When fixing bugs during a sprint, use a lightweight process that focuses on communication. You should test code as it’s being built, perhaps even building your test suite while the developer is building the code. If you find a bug while testing, communicate the bug directly to the developer immediately. Ideally you should discuss it face-to-face. But if you are not located in the same office, use an Instant Messenger application or the phone to contact them right away. The goal is to immediately fix the problem without the need for a formal bug report. Write the bug report only if the bug must escape the sprint. Using this lightweight process gets team members talking with each other, rather than communicating through a bug tracking tool. If a stop-ship bug escapes the sprint, then the user story is not complete.
Zero bug tolerance factors into overall quality (credit to Andy Glover)
Zero bug tolerance does not mean you will fix all of your technical debt at once, just that you won’t be adding more technical debt. Refactoring, or improving the internal structure of an existing program’s source code, will help you address the debt over time.
Handling bugs this way not only improves the quality of the product you are shipping (or “potentially shipping”), it also cuts down the need for additional documentation. If you are allowing bugs to escape sprints, often those bugs must be documented as known issues in release notes. If there are fewer known issues, there is less documentation.
Conclusion
Holding the whole team responsible for product quality improves teamwork, increases quality, and reduces documentation. Closing communication gaps and fostering that shared commitment on the team pays off in a big way for the team, the product, and the users.
References
- “How Swarming Helps Agile Teams to Deliver,” Ben Linders. http://www.infoq.com/news/2013/02/swarming-agile-teams-deliver
- “Swarming,” Oleksi Derkatch. Developers Anonymous blog. http://oleksiderkatch.blogspot.nl/2011/03/swarming.html
- Guide to Agile Practices, Agile Alliance. http://guide.agilealliance.org/
- “The Whole Team Approach to Software Quality,” Ed Spire. https://dl.dropboxusercontent.com/u/55047326/WHOLE%20team%20approach%20to%20quality.pptx
- “The Whole Team Approach in Practice,” Lisa Crispin. http://lisacrispin.com/2011/04/26/the-whole-team-approach-in-practice/
