In agile software development, the whole team owns quality; but clearly many teams face barriers to accomplishing that goal. In particular, I repeatedly hear four troubling comments about the state of development teams' testing and quality assurance (QA) efforts.
- "We don't have enough time to test, because the developers give us working builds way too late in the cycle."
- "I wish our quality was better, but it's out of my control to change anything."
- "Poor quality must be our fault as testers, since we are the ones responsible for testing."
- "We should test more, or we should develop slower, or we should specify our requirements better - that should improve quality."
In this tip, I'll address these problems, their causes and some best practices for beating those problems and achieving sterling software quality in agile development.
Humans, not technology, ruin software quality
In my field work, I see basic and predictable human responses getting in the way of achieving higher quality. You can certainly improve quality through changes in process, and many of those changes are at the center of agile adoption. But I often see teams struggling with the human aspects of those process improvements. By paying attention to the ways everyone naturally avoids responsibility, you will be able to move past the barriers that contribute to poor quality.
I've learned a great deal from Christopher Avery's Resposibility Process. Essentially, Avery shows that when problems arise, everyone experiences a predictable series of thoughts that protect them from taking responsibility and block them from learning and improving. It starts with blaming someone or something. When you move past blame, then you justify the event with a story you tell yourself. If that story doesn't fully work, then you turn the blame to yourself and feel shame. Once that shame ...
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
wears off, you will feel a sense of obligation. If the shame and obligation become too unbearable, then you will quit or detach to escape from those feelings. All of these thoughts prevent you from taking responsibility and ultimately moving forward. Sound familiar?
Breaking down blame-game walls
Finger-pointing between the testing team and the development team is the most common blame game played.
- The testing team says, "Our quality around here is bad because the developers give us working builds way too late in the cycle."
- The development team replies, "We have quality issues because the testers aren't doing their jobs."
A typical team structure has the two teams separated by time and space. They are working at different phases of development and in different buildings or countries. Nothing fosters an environment of blame like a wall, or a continent, between people. Having co-located teams is powerful because it is much harder to blame someone if he or she is sitting in the cube right next to you. If distributed development is a fact of life at your company, you can still improve by time by testing inside the iteration.
Another way to reduce blame is to give a team a shared sense of purpose. If the team -- both developers and testers – is working toward a common, shared goal, they will move past blame faster because they are more likely to view each other as part of the same group.
Equal members in the iteration
Once the team moves past blame, then comes the justifying comments. Typically these are comments about things being out of their control.
- A developer may say, "I wish our quality was better, but I can't change anything."
- With distributed teams I often hear, "It's really hard to work effectively with such a distributed team, but that's just the way it's going to be around here."
A retrospective process can be used to break out of this thinking. If you hear someone justify the status quo, address that concept and ask what two things we can do as a team to change it. Remember that responsibility is a personal thing and not something you can impose on others. Asking people what they would like to change can help free them from the status quo thinking and excuses.
The wall that often exists between developers and testers can contribute to justifications. A powerful way to move past this is to have testers and developers be equal members in the iteration. When people have an equal say in the planning and execution of the iteration, their shared intention will help them move past justification.
The five "whys," not the five "whos"
Statements of shame follow after justifying comments. A common thing I hear from testers is, "We have a quality problem, and it must be our fault since we are the ones responsible for quality." This is a mindset where people can easily get stuck. If testers take the shame for quality, it is much easier for everyone else to blame them, too, and avoid taking responsibility themselves.
One way to break the mindset of shame is to conduct a "five whys" session on a quality issue in your next retrospective. In "five whys," you focus on getting to the root cause of an issue by repeatedly asking "why" to drill deeper toward the underlying cause. It's important to note that this is "five whys," NOT "five whos." With each "why," it can be easy to stop at blame or shame and point the finger at a specific person. Five whys is a constructive way to move past the who and focus on the why.
Shared responsibility for quality
Having moved past shame, obligation is next. A team member says, "We have a quality issue here. We should test more, or we should develop slower, or we should specify our requirements better."
Most people confuse obligation with responsibility. It feels like taking an action is the right thing to do and is proof that you aren't avoiding responsibility. The problem is that obligation doesn't involve honestly confronting yourself to see if you're following your intention and going toward what you want, even when that's the difficult path.
If the team agrees that quality is the responsibility of the whole team, obligation can get in the way. With teams where quality is everyone's responsibility, I often see the developers very involved in technically enabling the feedback loops that are fundamental to improving quality. If the testing team is obligated to solely shoulder the entire burden of testing, it prevents others on the team from having the space to take responsibility.
If these concepts resonate with you, I would encourage you to take your new awareness and your intention to deliver great software and confront how you can take responsibility. Many teams struggle with quality and are frustrated that so-called process improvements aren't dramatically improving things. Hopefully these tools will help you move past the barriers many teams face in their own behaviors.
About the author: Zach Nies has 20 years of engineering and product development experience. He has served on standards bodies such as the W3C's HTML working group and currently serves on the board of directors for Agile Denver. He is now Rally Software's vice president of products.
