Who Owns Quality?
On request from Adam Goucher – another excerpt from How We Test Software at Microsoft. BTW – Adam wrote a review of HWTSAM here – although Linda Wilkinson beat him to the clever title.
This is from a section on quality in chapter 16. It’s something I believe strongly in and would love to hear your comments.
Many years ago when I would ask the question, “who owns quality,” the answer would nearly always be “The test team owns quality.” Today, when I ask this question, the answer is customarily “Everyone owns quality.” While this may be a better answer to some, W. Mark Manduke of SEI has written: “When quality is declared to be everyone’s responsibility, no one is truly designated to be responsible for it, and quality issues fade into the chaos of the crisis du jour.” He concluded that “…when management truly commits to a quality culture, everyone will, indeed, be responsible for quality.”[1] A system where everyone truly owns quality requires a culture of quality. Without such a culture, all teams will make sacrifices against quality. Development teams may skip code reviews to save time, program management may cut corners on a specification, or fudge a definition of “done”, and test teams may change their goals on test pass or coverage rates deep in the product cycle. Despite many efforts to put quality assurance processes into place, it is a common practice among engineering teams to make exceptions in quality practices to meet deadlines or other goals. While it’s certainly important to be flexible in order to meet ship dates or other deadlines, quality often suffers because of a lack of a true quality owner.
Entire test teams may own facets of quality assurance, but they are rarely in the best position to champion or influence the adoption of a quality culture. Senior managers could be the quality champion, but their focus is justly on the business of managing the team, shipping the product, and running a successful business. While they may have quality goals in mind, they are rarely the champion for a culture of quality. Management leadership teams (typically the organization leaders of Development, Test, and Program Management) bear the weight of quality ownership for most teams. These leaders own and drive the engineering processes for the team, and are in the prime organizational position for evaluating, assessing, and implementing quality based engineering practices. Unfortunately, it seems that quality software and quality software engineering practices are rarely their chief concerns throughout any product engineering cycle.
Senior management support for a quality culture isn’t entirely enough. In a quality culture, every employee can have an impact on quality. Many of the most important quality improvements in manufacturing have come from suggestions by the workers. In the auto industry, for example, the average Japanese autoworker provides 28 suggestions per year, and 80% of those suggestions are implemented[2].
Ideally within Microsoft engineers from all disciplines are making suggestions to improve quality. Where a team does not have a culture of quality, the suggestions are few and precious few of those suggestions are implemented. Cultural apathy for quality will then lead to other challenges with passion and commitment among team members.
[1] STQE Magazine. Nov/Dec 2003 (Vol. 5, Issue 6)
[2] The Visionary Leader, Wall, Solum, and Sobul
Comments
- Anonymous
September 21, 2009
Along the lines of "every employee can have an impact on quality," what are your thoughts on developers or testers starting grassroots movements to bring about quality improvements when management doesn't implement their suggestions?Lately, I've encountered several developers, testers, and lower-level project managers trying to do this. Their reasoning is something like, "Management doesn't buy into our idea right now, but if we implement it, when they see the results, they'll be won over."Don't get me wrong, I absolutely hope these people will succeed. But I worry that they will have trouble bringing their improvements about if management hasn't bought into them. Or, that management probably doesn't care about the sorts of results the changes will produce if that management isn't interested from the outset. Or worse yet, since management isn't aware of the changes underway, they may try to introduce other changes that run counter to those the developers and testers are trying to bring about. - Anonymous
September 21, 2009
This is a great question. I have been part of several grass roots quality efforts throughout my career. In just about every case, our plan was to show success to management and get them to buy in. In many cases, I was successful. I'm a big fan of "pilot programs" to prove that something will work.However - in the end, quality is a management issue. Without a management team that is fully supports quality, and believes in making investments to achieve higher quality (i.e. taking time to get things right the first time), these grass roots efforts won't add up to much in the end.I think I just repeated what you wrote, but I guess I wanted to reply to say that I appreciate the comment and tell you that your thoughts are (imo) right on the money.