Team Scrum – Photo credit: Lawrence SInclair
In previous articles on Agile and Tech Comm, I have discussed ways that agile development benefits technical communicators, especially with regard to the concept of scrum. While “basic” scrum has been a huge help to the way we work and puts us more in sync with the rest of our team, adopting the whole team approach to development within scrum has further solidified our role on the team, improved teamwork across the board, and increased our product and documentation quality.
My company has been working in scrum for a few years, and over the course of time, we adopted some practices that weren’t healthy or beneficial. In addition, we had some failures in shipping products when we said we would. These factors pushed us to look at what we were doing that wasn’t working and make some changes.
Silos and Sole Guardians: Our Old Way of Doing Scrum
We were functioning at the most basic level in scrum teams, yet many of our teams had divisions among functional areas. Divisions became silos, and these silos prevented the whole team from seeing the shared vision of what we were building. Often Development met with Product Management early on to get a thorough description of the requirements, or define the user stories first, then bring in Quality Engineering (QE) and Information Development (ID) later. Or, Development looked at their prototypes and QE looked at their test cases, but they didn’t always match up because there weren’t well-defined acceptance criteria for each user story.
As a result of these ever-growing silos, QE began to themselves as the sole guardians of quality. They were the gate the product had to go through to be labeled “ready to ship.” At the same time, documentation was viewed as the sole responsibility of the ID team.
Instead of Development, QE, and ID working together as a team to code, test, and document user stories all within the same sprint, QE and ID tasks often lagged sprints behind the rest of the team. Rather than calling a user story “done,” we tended to call it “done” when Development was done coding, and “done done” after the story had been tested and documented. The “done done” designation sounds silly, but it’s descriptive of how the tasks for user stories were previously viewed – that is, two different stages of “done” were used, which goes against the ideals of an agile team.
We’re Done with Done-Done: Our New Way of Doing Scrum
We went through substantive retraining, and held many conversations with Product Management. We look at our approach to scrum and to tasks with fresh eyes. Now, when we plan a release and populate that backlog, the whole team understands exactly what we are (and are not) building. The entire team accepts responsibility for completing all aspects of each user story, including testing and documentation tasks.
More importantly, the entire team agrees that the user story is not done until it is coded, it is tested, all stop-ship bugs are fixed, and it is documented. This thought process spurs the team to plan for testing and documentation tasks to occur within the same sprint as development tasks, rather than lagging behind. As a result, we now have one definition of “done,” and that means the user story has been coded, tested, and documented. If any of those items aren’t done, the story is considered “not done.” For more information about what “done” means, see “Agile Principle 7: Done Means DONE!” at http://www.allaboutagile.com/agile-principle-7-done-means-done/.
Quality is a Whole Team Responsibility
While there are many benefits to the internal team of using the whole team approach, the most obvious external one is that the quality of the product goes up. The whole team is responsible for fully coding, testing, and documenting each user story before the sprint ends. While QE leads that effort, the entire team works to ensure that it happens.
We found that to achieve our goals for each sprint, we needed to automate as much of the testing as possible. Automated testing is faster, more reliable, and less error-prone. QE works with Development to ensure unit tests are done and improve coverage where there are gaps. QE should also lead the effort in defining and automating acceptance tests, as well as run exploratory tests. In other words, manual testing is not the most agile way to get to a high-quality product. For more information about agile testing and the various types of testing, see Lisa Crispin’s blog at www.lisacrispin.com.
When the whole team takes responsibility for quality, more people with different skill sets and experience levels look at quality issues. Skilled developers can design testable code that makes test automation easier. If you need extra hands towards the end of a project, developers who have finished coding their assigned features can pick up some testing tasks. This approach helps complete testing more quickly, and ensures developers do not get too far ahead of the rest of the team, causing testing and information development to lag behind.
To Be Continued…
Adopting the whole team approach is more than retraining on processes and getting joint commitments. In part two of this article, I’ll explore how functional team members’ roles change in the whole team approach, and how swarming and zero bug tolerance make writers’ lives easier in addition to improving product quality.
References
- “Are You a Whole Team?” http://www.infoq.com/articles/whole-team
- “Play Soccer, not Football: How to Foster a Whole-Team Approach by Thinking in Activities Rather than Roles,” Matt Philip. http://mattphilip.files.wordpress.com/2011/03/play_soccer_not_football-agile-and-beyond.pdf
- Agile Testing: A Practical Guide for Testers and Agile Teams, Lisa Crispin and Janet Gregory.
- Innolution Product Owner Training, Kenny Rubin. http://innolution.com/training/product-owner-training
