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 Tabakais a wine enthusiast, author and Agile Fellow at Rally Software Development. Subscribe today to get free updates by emailor RSS.
Ryan and I have been talking about quality and faster as necessary components of an Agile organization for awhile. A non-Agile view of a successful organization would have us believe that pushing more and more features into a release and to the market necessitates a loss, or at least reduction or great variance, in quality. In an Agile organization, the thinking is quite the opposite.
Curiously, when we speak of quality and faster inside Rally or with clients, we talk about each being indispensable to the other.
For a traditional, non-Agile case study, let’s look at the RCA case study Ralph Aguayo brings up in his book “Dr. Deming: The American Who Taught the Japanese About Quality.” At its height, RCA’s business model focused on getting as many televisions into the hands of consumers as possible. (Did your family have an RCA T.V. when you were growing up? Mine did!) Quality was secondary to the savings RCA could make from cheap components and speed of product to market. Cheap and fast meant greater profits. Well, as it turned out, no…
Nipper on RCA's first color tv set - the CT 100
Unfortunately for RCA, their model began to crumble when television sets started being returned due to defects, lots of them all still in the warranty period. The cost of attending to these faulty sets ended up being as much as 25% more than the cost of manufacturing the existing set.
Do you have a similar situation in your software product delivery? Are you trying to get profits by pushing features out with “defective parts” because they are “cheaper”?
And to throw another wrench into the works, are you taking so long to get these feature sets pushed out that you have too much of a delay in your feedback to find either the defects or the value of the features you pushed? In other words, is your emphasis on speed, at the expense of quality, coupled with very large feature-rich releases, exactly the wrong way to create greater value and fewer defects?
In an Agile organization, the entire organization concentrates on value delivery and quick feedback on that value.
That is, “are we delivering the right features to the market?” In turn, a real Agile organization understands, “there ain’t no such thing as a free lunch,” and they do increase throughput without the traditional expense of decreasing quality. Defects held in check through a “stop the line” mentality free-up the organization to always respond to value feedback information faster. Think about RCA. If your scarce resources are tied up in managing defects and “returns,” they can’t be working on new feature sets. Or the feature sets delivered are being pushed on defects not yet resolved.
And so, the notion of “quality and faster” is not so counterintuitive as we may have once thought.
We need faster and faster feedback loops in time-to-market in order to continuously improve our ability to deliver quality (defect-free and valuable) features back to the market. Symmetrically, we need higher and higher quality features that are not defect-ridden or dubious in value in order to respond ever faster and more innovatively to the market.
RallyDev.com
#3 in our list of the 
