Exegesis Saves (Part 3) Beyond the Bromides

Over the last few blog posts, some colleagues and I have been analyzing this sentence:

“In successful agile development teams, every team member takes responsibility for quality.”

Now, in one sense, it’s unfair for me to pick on this sentence, because I’ve taken it out of context. It’s not unique, though; a quick search on Google reveals lots of similar sentences:

“Agile teams work in a more collaborative and open manner which reduces the need for documentation-heavy, bureaucratic approaches. The good news is that they have a greater focus on quality-oriented, disciplined, and value-adding techniques than traditionalists do. However, the challenge is that the separation of work isn’t there any more—everyone on the team is responsible for quality, not just ‘quality practitioners’. This requires you to be willing to work closely with other IT professionals, to transfer your skills and knowledge to them and to pick up new skills and knowledge from them.”

“In Agile software development, the whole team is responsible for quality, but there are many barriers to accomplishing that goal.”

“So what does testing now need to know and do to work effectively within a team to deliver a system using an agile method? The concept of ‘the team being responsible for quality’ i.e. ‘the whole team concept’ and not just the testing team, is a key value of agile methods. Agile methods need the development team writing Unit tests and/or following Test First Design (TDD) practices (don’t confuse TDD as a test activity as in fact it is a mechanism to help with designing the code). The goal here is to get as much feedback on code and build quality as early as possible.””> (site no longer findable on DNS —MB 2017-12-05)

“As we have seen quality is the responsibility of every team member in an agile team, not just the developers. Every team member has a role to play in building quality in.”

“The responsibility for quality was shifted to the whole team. Each of the different roles is responsible for doing some form of testing. Programmers, architects, analysts, and even managers are all intimately involved with testing activities and work closely together to achieve quality goals.”

“In traditional systems, the responsibility for quality is mainly delegated to testing teams that must make sure the code is of high quality. Agile thinking makes quality a collective responsibility of the customer, the developers and the testers all the time from the first, to the last minute of a project. The customer is involved in quality by defining acceptance tests. The developers are involved in quality by helping the customers write the tests, by writing unit tests for all the production code they write and the testers are involved by helping the developers automate acceptance (customer) tests and by extending the suite of automated tests.”

“I’m an advocate of any methodology that empowers engineers to work toward higher standards of software integrity. Agile and test-driven methodologies have found a way to do that by distributing ownership and responsibility for quality. And with so many ways to make static analysis boost the type of automated testing this requires, agile is a better formula for better code that can keep up with shorter scrum cycles and produce frequently “potentially shippable” products.”

“This then leads back to my original question. Who is responsible for quality? The answer is everyone.”

“The corollary to this rule is that testers cannot be responsible for quality; developers must be. The Agile methods put the responsibility for quality precisely where it belongs, with the developers.”

“In a successful team, every member feels responsible for the quality of the product. Responsibility for quality cannot be delegated from one team member to another team member or function. Similarly, every team member must be a customer advocate, considering the eventual usability of the product throughout its development cycle. Quality has to be built into the plans and schedules. Use bug allotments, iterations devoted to fixing bugs, to bring down bug debt. This will reduce velocity which may provide enough slack in future iterations to reduce bug rates.”

So the sentence that I quoted is by no means unique. Here’s the source for it. It’s an article by Lisa Crispin and Janet Gregory. You can read the rest of the article, and make your own decisions about whether the rest of it is helpful. You may decide (and I’d agree with you) that there are several worthy points in the article. You may decide that I’ve been unfair (and I’d agree with you) in excerpting the sentence without the rest of the article, especially considering that until now I’ve ignored the sentence that follows immediately, “This means that although testers bring special expertise and a unique viewpoint to the team, they are not the only ones responsible for testing or for the quality of the product.”

The latter sentence certainly clarifies the former. I would argue (and this is why I brought the whole matter up) that, in context, the second sentence renders the first unnecessary and even a distraction. Please note: my intention was not to critique the article, nor to launch a personal attack on Lisa and Janet. As I’ve said, I have no doubt that Lisa and Janet mean well, and their article contains several worthy points. My goal instead was to test this often-uttered tenet of agile lore. That’s why I didn’t reveal the source of the sentence initially; the article itself is not at issue here.

Yet the sentence, found in so many similar forms, is a bromide. My Oxford Dictionary of English says that a bromide is “a trite statement intended to soothe or placate”. As philosophers might say, the sentence doesn’t do any real explanatory work; it doesn’t make any useful distinctions. Even in context, it’s often unclear as to whether the sentence is intended be descriptive (“this is the way things are”) or normative (“this is the way things should be”).

To highlight my greatest misgivings about the slogan, let’s restate it, replacing the word “quality” with Jerry Weinberg’s definition of it:

“In successful agile development teams, every team member takes responsibility for value to some person(s).”

Every time I see the whole-team-responsible-for-quality trope, I find myself wondering responsibility to whom, quality according to whom, and what it means to take responsibility. Figuring out what we intend to achieve, and how we are to achieve it, are among the harder problems of software development. (One can see this being played out in the Craftsmanship Skirmishes that are going on as I write.)

Here’s what would make the conversation more meaningful to me. I suggest that we who develop and write about software…

  • Consider quality not as something simple, objective, and abstract, but as something messy, subjective and very human. Quality isn’t a thing, but rather a complex set of relationships between products, people, and systems. As such, quality shouldn’t be swept under the rug of a vague slogan.
  • Remember that there are as many ways to think about quality as there are people to think about them, and that in a software development project, people’s interests will clash from time to time. Those conflicts will require some people to concede certain values in favour of other values. As Jerry Weinberg has pointed out, decisions about quality are political and emotional. Sorting out those conflicts will require us to identify who has the power to make the decision, and to contribute to empowering that person when appropriate. That in turn will require us to develop skill, courage, and confidence, tempered with patience and humility.
  • Apropos of the last point, we must keep in mind that teams are collections—or systems—of individuals. it’s a nice idea to think that the whole team makes decisions collectively, but in reality some person—the product owner—must be granted the ultimate authority to make a decision. If the team is to be successful, there’s an implicit contract: the product owner must enable, trust and empower the members of the team to design and perform their work collaboratively, in the best ways that they know how; and the members of the team must inform, trust and empower the product owner, such that she can make the best decisions possible.
  • Since quality means “value to some person(s)”, be specific about what particular dimension of value we mean, and to whom. For example, in a particular context, if we want “quality” to mean “bug prevention,” let’s say precisely that. Then let’s recognize the ways in which certain approaches towards preventing bugs might represent a threat to someone’s current interests or to their personal safety rules. If, in a particular context, we want quality to mean “problems solved for customers”, let’s say precisely that. Then let’s recognize that there are many approaches to solving problems, and that some problems might be solved by writing less software, not more. If we want “quality” to mean “many features in a product”, let’s say precisely that. Then let’s recognize how “many features” can satisfy some people—while adding complexity, development time, and expense to a product, thereby confusing and annoying other people. In other words, let’s use the word “quality” in a more careful way, which starts with deciding whether we want to use the word at all.
  • Since quality is a complex notion, we must learn not only to declare quality in terms of things that we expect and prescribe. Those things are important, to be sure. Yet we must also prepare to seek the unexpected, to make discoveries, and to respond to change.
  • Rather than striving for influence (which to me has echoes of the quality assurance or quality control mindset), testers in particular must strive to develop understanding and awareness of the system that we’re being asked to test. To me, that’s our principal product: learning about the system and reporting what we’ve learned to help the project community to gain greater understanding of the system, the problems, and the risks.
  • Consider responsibility not in terms of something people take, but as something that people accept, and also as something that people grant, share, and extend to one another. To me, that means contributing to an environment in which everyone is empowered to create and defend the value of each other’s work. That includes offering, asking for and accepting help—and dealing with unpleasant news appropriately, whether we’re delivering it or receiving it.

There have been several pleasures in working through this exercise—most notably the transpection with my colleagues on Twitter and in Skype. But there’s been another: rediscovering and re-reading the Declaration of Interdependence and George Orwell’s Politics and the English Language.

Note that I’m saying that these ideas would make the conversation more meaningful to me. You may have other thoughts, and I’d like to hear them, so I hope you’re willing to share them.

8 replies to “Exegesis Saves (Part 3) Beyond the Bromides”

  1. […] This post was mentioned on Twitter by Michael Bolton, Albert Gareev. Albert Gareev said: RT @michaelbolton Published: Exegesis Saves (Part 3) Beyond the Bromides #testing #softwaretesting #qa #agile […]

  2. Nice… I do agree with you. We use the word quality very loosely to describe what we mean by meeting or exceeding customer’s expectations (value to some person). I would like to use more descriptive words but it is not always feasible in a general context. When we are in a project, we should define what we expect – not only what is important to the product owner, but to all the stakeholders involved. We need to identify our neighbours as Jonathan Rasmusson in ‘Agile Samurai’ talks about, and discover what is important to them.

    If we, as a team take responsibilty for understanding some of those quality attributes, we stand a lot better chance of meeting them… and yes, we definitely need to leave time to “seek the unexpected, to make discoveries, and to respond to change.”

    Michael replies: Thank you, Janet. I’m glad you’ve taken this exercise in the spirit in which I intended it. My appreciation to you for that; I regret that it would have been easy for you to take it a different way.

  3. I agree and would like to add another point:

    ..we who develop and write about software should keep clear of oversimplification and over-generalization.
    Even though that sentence is both, it still is a good slogan or a title, thus needing a chapter of explanations (of what is quality, etc).

  4. After recently re-reading Fred Brooks’ “No Silver Bullet” (1986), I was reminded of something he said:

    “For the truth is, the clients do not know what they want. They usually do not know what questions must be answered, and they almost never have thought of the problem in the detail that must be specified.”

    Even, if things have improved these days, the idea that a subjective description (quality) is used as though it is a universal constant is widespread.

    I recently bemoaned this use of a subjective value as though it was some commonly-understood measure in my “‘Quality’ no more” piece.

    I think we need more exercises and pieces like this to chart the “there be dragons”-type areas of communication within software development, and especially software testing.

  5. I must admit something, Michael (and Janet and Lisa.) When I read the article, which generally I thought was pretty decent and had good points to consider, on coming to the sentence in question, much of what I tweeted in the “testing challenge” were my mental responses – even with the full article as my context.

    I gleefully admit that my experience with Agile has been somewhat limited. (One team that followed a variant of Scrum without calling it Scrum or Agile – intentionally; One team that said it was Agile, doing Scrum, that was painfully Non-Agile.)

    Having said that, much of what gets written about “what makes Agile teams successful” could equally be applied to the incredibly successful waterfall teams I’ve worked on. During my stint as Project Manager and BA, I did everything I could to foster those ideas (communicate, communicate and communicate meaningfully.) At the same time, I’ve seen plenty of trainwreck projects in Agile and “traditional” environments – even when the participants attempted to do things “right.”

    I sense a blog-post coming when I get to a point in the project where I can write it.

    thanks for fostering the discussion Michael. I have much to think on, as usual with your exercises.

  6. I generally feel exasperated when I read Agile people opining about testing and quality, given that I find so little evidence of any particular interest they have in mastering the skills of testing and quality analysis.

    But, the issue here is not what the authors said or didn’t say. The issue, I think, is that consumers of technical articles and opinions ought to practice their skills of thinking critically about these things. The three posts you have written are an example of such critical thinking. It’s not nitpicking– or if it is, that’s beside the point. We must all have the ability to nitpick, when that is required for understanding.

    — james

  7. I have a different interpretation.

    While you have made good points about the meaning/definition of quality – I think that applies to all software teams. I think the definitions of success apply to both agile and non-agile teams. There could be different meanings of agile – but I think that may not impact this statement. I think the loaded phrase is “every team member…..”. Not to mince words, I think the essence of this statement is that every team member should test. Which brings up the question “can developers test”? If the answer is yes, that implies that traditional testers are dispensable. There are two ways to interpret that:
    1. Only hire developers (or mostly developers). I think many agile teams (and some non-agile teams) do that. I don’t agree that with this approach.
    2. Use a combination of dev and test and train dev on how to test.

    Brian Marick has made an eloquent argument on whether developers can test:

    If I were designing an agile team, I view the statement in your blog as a vision statment for a feature. The detailed design is given in the last part of the link to Brian M.’s blog (titled Staffing).

    I would staff an agile team with 3 clones of Ron Jefferies, 1 of Brian Marick and 2 of testers (similar to those who contributed to this blog). I would send them all to a 10 day rapid testing training. In 6 mos. the whole team would take responsibility and contribute equally to quality (whatever the meaning of quality).

    Note that I could use the same team for a non-agile project. The team and I will continue to agonize about the definitions of success, agile and quailty.

    Would be good to test the detailed design of the team (as described by Brian Marick) 🙂

  8. To Clarify my previous comment:

    I meant that the original sentence “In successful agile devel…” – is a oversimplification and over-generalization. A good slogan or a title, needing a chapter of explanations (of what is quality, etc).

    The presentation of idea matters almost as much as the idea itself. Or you’ll just look stupid 🙂


Leave a Comment