RallyDev.com
Wed 6 Jan 2010
How to Stop the Quality Killing Blame Game
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.
[...] This post was mentioned on Twitter by Max Chiu , alohafromSF. alohafromSF said: How to Stop the Quality Killing Blame Game http://ff.im/-dSdSC [...]
Hi,
First of all Thanks very much for your useful post.I would like to introduce another good
blog which is having free software testing ebooks and technical content, Have a look.
http://qualitypoint.blogspot.com/2009/12/released-two-ebooks-for-learning.html
This is a subject close to my heart. But I do think the problem lies not only with individuals when it comes to the ‘blame game’, but with organisations as a whole. I’ve worked in far too many places where the change management process seemed more a tool with which to identify and blame individuals, rather than one to understand how as a whole the organisation can improve or avoid making the same mistake again. Indeed managers often unintentionally reinforce this by noting to the team that change management records WHO made the change.
First, thanks Zach for your leadership in addressing this issue and inviting me to the webinar. I look forward to it.
Second, to Phil’s point, I agree that eventually quality is an issue of organizational culture, and I’ll share one such organizational case study on the webinar (in case it gets cut due to time, I’ll offer it as a follow up download). That said, there are plenty of things that individuals, teams, and team leaders can do to increase the sense of ownership for quality. I no longer buy the “I got put on a bad team” (”…work in a bad culture”) excuse from otherwise resourceful individuals. Yes, my position on this sounds a little extreme unless you think about the long-term consequences of opting in to a “bad team” or “less-than-quality culture.”
On the webinar I’ll offer some things that every individual and every leader can do to take ownership not only for the quality of software but for the quality of your experience as well.
I think all of you are right. from my own experience as a software proffisional and leader quality is something you have to build in your mindset, attitude, the way of thinking, implementing and doing things. Comprimises are easier when you do not feel ownership and can always say “that is what I was asked to do, everything else will cost you much more”. I think ownership is the key for taking responsibility and then acting => better quality.
I would love to attend the webcast, but unfortunatly Tuesday 19:00 Norwegian time is allready booked for christmas ball.
Regards
Hussam