Agile Development Blog

Don't let this be your user!

Recently, my Rally colleagues Ben Carey and Ryan Martens delivered a great webinar about testing and quality.  What particularly struck me about the session was how Ben set up why we should, at a very personal level, care about testing and quality.

Enter Amy and her daughter Morgan.

As Ben told the story, Amy was a back office admin in a physician’s office. It was her responsibility to get billing out to insurance companies for the practice, and on one particular day, things were not going well.

She kept getting cryptic error messages. The batch just wouldn’t go through. Stress mounted. To add to Amy’s distress, it was nearing time for her to pick up her daughter Morgan at school. Morgan had just started school. Only 4 weeks in, Morgan was suffering some separation anxiety. Amy felt the urgency to be there for Morgan as soon as school let out. And yet, she was stuck at her desk dealing with these insurance issues.

Why should Ben be talking about Amy and Morgan in a webinar about testing and quality? Because Amy was Ben’s customer. Ben was on-site to see how his software was supporting the practice. And so, he personally felt Amy’s mounting stress in using the software HIS team had delivered and HER doctor’s office had paid for. When Amy started to cry, it was all over for Ben. He had to do something.

What does Amy and Morgan’s story tell all of us?

1. Users deserve better than this.

2. On an Agile team, quality is everyone’s job!

We often think of testing as an issue for the tester role alone.  But this stance sets a number of bad dynamics in motion:

• When we don’t fix defects, we declare doneness by “hiding” defects in a defect backlog
• Hidden defects accumulate into hidden technical debt
• Technical debt slows down our ability to deliver subsequent releases
• An ever-increasing defect backlog can be demoralizing for the entire team
• Engineering resents the business when being forced to deliver features when the engineers know defects exist
• Business resents engineering for not being better and faster at building features
• Testers resent testing left until the end because it puts business, engineering, and testing in a tight spot

So here is a thought: quality is not just an engineering issue; it is a systemic issue. That is, it is driven from the top down in a business not from within one part of the organization. A business policy about quality impacts our users by directly impacting their quality of life. Amy’s stress about picking up Morgan from school could be traced back to a testing and quality policy in engineering that was driven by a policy in the business: get features out.

As you adopt Agile, work vigorously to create rigor in your testing and quality goals. Why? Because your policy can hit hard in ways you don’t currently track. Pay attention to more than just the internal cost of technical debt. Let’s pay attention to the quality of life of our users.

The next time you are logging a defect versus fixing it, don’t forget about your Amy and Morgan.

About the Author: Jean Tabaka is a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by email or RSS.