Agile Development Blog

Over the last several months, I led four breakout sessions on Agile quality at our Agile Success Tour and in the process I heard these troubling comments:

“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.”

Agile development advocates that the whole team owns quality, but clearly many teams face barriers to accomplishing that goal. I’ve been thinking about these comments a lot lately, and I think the problem is that basic and predictable human responses are 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 more often when people ask me process questions, I hear 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.

The best model I’ve seen for how to do this is Christopher Avery’s Responsibility Process. The basis of this model is that when problems arise, every individual goes through a very predictable series of thoughts that allow him to cope with what just happened, but also block him from moving into a mindset of 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. Once you move past that story, then you turn the blame to yourself and feel shame. Acting on that shames often leads to feeling 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 into a mindset of learning and acting. Sound familiar?

This same pattern subtly plays itself out every day for you and your team around you, especially with issues of quality. According to the Responsibility Process, there are three keys to taking responsibility: (1) intention, (2) awareness and (3) confront.

To learn more, I encourage you to join me and Christopher Avery for our January 12th On Demand webcast, The Best Kept Secret in Agile Quality, where we will talk about :

• the relationship between quality and ownership
• the difference between accountability and ownership, and how this difference affects quality
• how the Responsibility Process can be used as a framework to continuously improve quality through a focus on people and interactions
• how to apply the Responsibility Process to your development team

I’m really excited about what we’ve put together for this and would love to see all of you attend.[Reserve your spot now by CLICKING HERE]

About the Author: Zach Nies is a golfer, expert on Agile quality and VP of Products at Rally Software Development. Subscribe today to get free updates by email or RSS.

Sarah: “Whoa, whoa, whoa, Walter. Where are you going in such a hurry with that look on your face? You look like you’re chasing that guy who stole Christmas.”
Walter: “Grinch.”

Sarah: “What?”
Walter: “It was the Grinch that stole Christmas.”

Sarah: “Stop changing the subject, Walter! Where are you going?”
Walter: “I’m going to the Frboz 2.0 Project Post Mortem, and it’s gonna be pure hell. It was over 100% late, bad quality, angry customer. It’s a classic. And I wasn’t even on it. I’m supposed to be there to criticize the project leader.”

Sarah: “How did that happen? I thought they went through all of that on 1.0, didn’t they?
Walter: “Yes they did, and they had a post mortem and they made changes and it seems to have made things worse. They blamed a few people and then left them to work on the 2.0 project because they learned something by being blamed, so they were pretty demoralized to start with. The post mortem decided to be more rigorous on signatures, so the Requirements phase took twice as long as planned. Every time they tried to get all 12 people to sign, one of them had a change to make. Same thing happened during System Test. They were supposed to get CTO approval for every push to pre-production, but the CTO was never around and she had to be completely briefed on everything that had happened in that build when they finally found her before she would sign. Everything took ages! In the end, everything they did made things worse. I don’t know what to do. This meeting is going to rip some people up, and for no reason that I can see.”

Sarah: “Hey Walter, I have an idea! What if you tried to get them to look at root causes instead of concentrating on blame for surface symptoms? Maybe they would discover some useful ways to actually improve things. What do you think?”
Walter: “You know, Sarah, it’s crazy enough that it just might work. Remind me of some easy ways to do root cause analysis. I’ll only get maybe one or two chances to make my point.”

Sarah: “Try the 5 Whys. It’s a technique from Lean Manufacturing, but it works really well. Start with a symptom and ask ‘Why is that?’ Then when you get an answer, ask ‘Well, why is that?’ When you get that answer, ask it again. Do it a bunch of times and you’ll eventually drill down to a root cause. Ask ‘Why?’ five times. Get it?
Walter: “OK, let me see if I got it right. I pick a symptom, like ‘requirements not agreed on time’ and ask “Why?”. Then they say ‘…because it was too hard to get all 12 signatures.’ So then I say ‘Why was that?’ And they say ‘…because every time we made a change and went to get the signatures, one of the people would have another change to make.’ So then I ask ‘Well, why did that happen?’ And they say ‘Because everybody kept learning more about what the product should be.’ And on and on until eventually we find out something like ‘Oh. It’s impossible to get all the requirements right up front.’ Or whatever. Then we can figure out how to address that root cause. Is that it?

Sarah: That’s it, you’ve got it.
Walter: Gimme five, Sarah! Thanks for the help!

About the Author: Alan Atlas is a poker player, Certified Scrum Trainer, and Agile Coach at Rally Software Development. Subscribe today to get free updates by email or RSS.