Killing "Quality"

So, a guy walks into a bar...

No, just kidding. But seriously though...

You walk into a bar and order a "low quality" beer (tough economy these days). What does this mean to you? That it'll come out with a bug swimming in it? That it will be served heated up? That it will be skunked? Glass only half full?

No, of course not. You'd be appalled, outraged. Have every right to ask for your money back. This place has acted in bad faith, they've acted unacceptably. You leave angered and vow to never return.

Your wife wants you to drop $600 on a new Louis Vuitton bag (you gotta buy cheap beer and she' still asking for Louis?!?), because it's a "top quality" product. Does she describe it this way because she knows it has less likelihood of falling apart the minute she gets it, or its colors smearing, or it having holes in the bottom? Again, no. These things are assumed to be absent. In the rare case you do happen to find anything like this, you are sure to invoke "return to sender, no questions asked".

I could continue on this way throughout various types of products, but I suppose you get the point.

Well, this ain't the case with our industry (Software Development). So I ask ye: WTF, man?

We use the word "quality" as an indicator of both "value" and/or "defect" presence, interchangeably.

When someone says "high quality" they could very well be talking about the absence of defects or they could be talking about the presence of value. And by software standards, neither would be an inappropriate use of the word.

Not so in the bar, not with your beer. Why then for us? Again I ask, WTF?

I know, I know. Some of you are sitting there saying (correctly), "hey, wait, agile pays attention to customer feedback to iterate towards a higher quality solution. We're talking about 'value presence' there." Or maybe your saying, "Our company's website says 'highest quality product in the industry!'. That's talking about 'value presence' too! That's what we mean when we say 'quality'."

Well, maybe so (and good for you, seriously). But I bet many of you still call your testers "the QA folk". "QA", as in Quality Assurance, as in "Those who ensure quality". But really, is their (primary) function that of ensuring 'value presence', or of ensuring 'defect absence'? Look, don't get me wrong, on a healthy agile team these wicked cool cats ARE involved in 'ensuring high value', but at the end of the day that isn't why you're calling them "QA'ers".

I've seen my share of "quality review" meetings, or fancy charts of "quality metrics", or annual budgets that talk of "quality goals" ... where in each of these cases, "quality" is talking about DEFECTS.

When was the last time someone described the benefits of TDD without mentioning, excitedly, "increased quality"? (And, yes indeed, I am certainly just as guilty as the next guy.)

So, why do I care? Why the rant?

Because, it's an indication of the generally absurdly high level of tolerance our industry has for defects.

That we describe defect density with the same word that we use to describe product "value" (to our customer/consumer) is gross.

Heck, I'd go as far as to say its a part of the reason that we have such a generally high tolerance in the first place. It's confusing and it is misleading. It's too easy to masquerade our defect problems as a "quality improvement initiative" or some other politically wimpy label.

When our customers get a bunch of "bugs in their beer" why aren't they appalled and outraged? Why aren't we? Why don't they storm out and vow to never come back? Why is it so damn okay to have defective software? For the third time, WTF?

Don't get me wrong, I'm not saying we should have an absolute "zero defect, period" attitude, that's simply unrealistic considering what we do. But we should have a low enough tolerance for defects that it makes no sense for us to use the word "quality" when talking about them.

"Quality" should be used as a measure of functional/aesthetic utility to our consumer, and not as a measure of defects. Really, it should just be assumed that defects are generally absent. This should just be implied in what it means to be a Professional.

So:

I hereby propose we as software professionals and businessmen stop using the word "quality" to mean a "measure of defects".

Well then, what word will we use? I polled Twitterverse with this question and received lots of great responses, but the group's choice as winner, courtesy of one Brian "Big Ball Of Mud" Foote, is this:
Shittiness.

Software with minimal defects has a "low degree of shittiness"; lots of defects means it has a "high degree of shittiness".

Of all the tweep responses though, overall my very favorite was from Lisa Crispin who said, "I have never liked measuring defects so it's hard to think about what to call it."

Nice, now that actually says it all. Something tells me that Lisa's company does not simply think of their testers as "the QA folk". There is hope!

Wringing Necks

Re: Title. Sorry, its Friday the 13th, couldn't resist!

Anyhoo...I was checking out this InfoQ post which asks the question of whether you need a single person as your "Product Owner" or it can be many. I have my opinions about the answer to that particular question, but I'll save that for another post. It's the undercurrent of that question I want to discuss now.

"One neck to wring". "One throat to choke." I've heard this and similar statements for years in reference to Product Owners (in Scrum terms that is; in XP, we may say Customer). In other words, there are people who make the statement that part of the Product Owner's role is to be the "one throat to choke", the "one neck to wring".

My take on this is similar to my feeling on the "Chickens & Pigs" thing: me don't like it, and here's a quick run-through of why.

This euphemism, at its heart, is a statement of accountability. It basically implies that the Product Owner is accountable for the outcome of your agile project, for its successes and/or for its failures. Beh, hogwash.

Let's backtrack a tad (just can't help myself ;-). I'm a believer that there exists at least these two primary degrees of agile teams:

• Agile Team v1.0: practices have been installed and people are following their agile methods generally as the book tells them. They are following the mechanics, that is, but that's all. What's missing? Well, a real team. Agile Team 1.0 may not be a bad thing, it's likely to be a much better thing than to have no agile at all, but it's not the hyper-productive thing your executives were clamoring for.
• Agile Team v2.0: as with v1.0, the team is following the practices, but this team is a real team. In other words, the team is truly "self-organizing" and empowered. This team understands and manages the interpersonal aspects of good teamwork. This team truly understands that at root of success are people, and the interactions between them. This is the team that execs bought into [noun] "Agile" for; this team kicks ass.
  

Said another way, in Lencioni terms, the members of Agile Team 2.0 trust one another, engage in unfiltered conflict around ideas, commit to decisions and plans of actions, hold one another accountable for acting on those decisions, and focus on the achievement of collective results. Agile Team 1.0, on the other hand, does not do all of this.

Highlight: "...hold one another accountable...". There ya have it, Agile Team 2.0 is a team that shares its 'Accountability'. Each member is accountable; the developers, the testers, the CM folks, etc..., and finally, yes, the Product Owner (Customer) too. No "one neck", no "one throat", everyone.

Bottom line, if any one person holds the accountability for success/failure on your agile project, particularly if that one person is your Product Owner, you've got more to learn about how to be [adjective] agile, about how to be a team.

The good news is that you're not the best you can be, you've got room for some big improvement, how lucky!

Where'd Jeff Probst go? (aka, Kicking someone off the island)

Yesterday I spent the better part of my morning reading through the 130 or so messages in the Scrum Dev Yahoo group's "Rotten Apple In Scrum Team" discussion, then I posted this "newsy" summary of the discussion on InfoQ.

In a nutshell, Marko told the group of a guy on his team he sees as a drastic "under-performer", or as he put it originally a "rotten apple", and asked for advice as to what to do with him. Read the InfoQ post to get a deeper sense for how people responded, but the gist of most of the advice was for Marko to take an open-minded and objective stab at finding out (and/or helping the team find out) what's really driving this person's performance, or, rather, lack thereof. And then to help him out.

"Try 'Beginners Mind'"..."take queue from Linda Rising"..."pair up with the guy"..."be nice, be helpful, be supportive"...and so on and so on. Hear this clearly (before I get to my real point of this post): I generally agree wholeheartedly with all the advice presented.

Now though, all that Dr. Jeckyll buildup for the Mr. Hyde thought: 130+ replies and not one mention of "kicking someone off the island"?

[...and the crowd gasps in horror...]

I've seen, and I'm sure you have too, a team who had an individual who truly did bring the team down. Typically not because they couldn't program quite as fast, or weren't quite as smart, or weren't quite as good in front of customers, or anything skill/experience/productivity-related like that. Rather, simply because they had a negative attitude, because they didn't play nicely or just plain didn't care.

[*Note: For what's worth, I do not think this applies to Marko's guy, but the discussion got me thinking anyway.]

One seriously under appreciated technique that I stress should be considered for these true "rotten apples" is to get them off your team, kick 'em off the damn island. No one says you have to fire them, just get them out of the way somehow.

Forget tools, intelligence, certifications, experience for a moment. The degree with which having a good team (in the "synergy" sense that is) contributes to good results (and, hell, a good time) is amazing; having a great team, well that's just indescribably astounding, magical even. Conversely, the degree with which having a bad team atmosphere can lead to serious bed-shatting, well, that's also quite amazing as well.

So if you've got someone who after the Prime Directive and the Beginner's Mind and the Pairing has still got that sour-puss face and, more importantly, is still killing your team's ju-ju, then by all means call the spade a spade, cut your losses, and remove them. Be as graceful as you like, but please, as Bo used to say, just do it.

Again I stress, I'm about as "glass half full" as they come - I'm not trying to encourage a general exclusive, head-chopping, "only the best" attitude. 95 times out of 100 your man intends the best and just needs a little love, and by all means you outta be doing your damnedest to facilitate that happening. My point is that for those other 5, stop being so P.C. and get the bad apple out of your basket. Your team's ju-ju will thank you for it.

** Update: Thanks to Esther Derby for shouting out about her related and more concretely useful post from some time ago echoing the same sentiment.