Exploration Through Example

Part of a series on the seven pillars of a good Agile team

In the world of software, there are two competing slogans:

• “Many heads are better than one.”
• “A committee is the only form of life with many heads and no brain.”

In a skilled Agile team, the first slogan wins. It is routine for two or more people to do better work together than any of them could do alone.

Some evidence of collaboration

• Pair programming.

• People frequently wave over other people to ask them questions or to seek help. Especially significant are “cross-disciplinary” conversations where a programmer waves over a tester or a user experience designer waves over a programmer.

• People frequently go to the product owner to ask small questions, rather than bunching questions up into marathon sessions.

• The code isn’t divided into subsystems that “belong” to someone and that other people dare not change.

• There are “big visible charts” or “information radiators” that everyone can easily see, that track data of interest to the team, and that actually get updated on time.

• “The best person for the task” will sometimes not do it—at least not alone. People are accustomed to reaching out past their own specialty.

• The words “That’s none of your business” are neither spoken nor implied. The team errs on the side of visibility.

Earlier this month, I gave a talk at Agile Roots on Artisanal Retro-Futurism crossed with Team-Scale Anarcho-Syndicalism. It was well-received. They’ve now released the video. The talk is about 25 minutes long.

Artisanal Retro-futurism crossed with Team-scale Anarcho-syndicalism seems a hit. I made upward of 400 stickers, and I have only a handful left. There’s been talk on Twitter about other types of Agile conferences, so let me make a rough proposal for a conference that focuses on solidarity and syndicalism and self-help.

There would be four parts to the conference.

• Chronologically first would be presentations from teams (or team representatives) on problems they’re having adopting Agile. The presentations would be in the LAWST structured-conversation style, or something like it. The goal of each conversation would be to give the team ideas about what to do next and how to do it.

  Teams would have to apply in advance to get their problems discussed. They’d also be expected to later provide a case report (or interviews for a case report) on what worked or didn’t.

  Perhaps toward the end of the conference, we should expect recipients of advice to give something like a lightning talk explaining which advice they’ll be taking.

  A semi-related idea: perhaps participation here is a prerequisite for a visit by the ScrumMaster of Last Resort?

• The second set of presentations would be from teams who’re doing well enough but are nevertheless eager to do better. As an “entry fee”, these teams would have to participate in the first sessions (helping people who’re having trouble getting properly started). The format would be the same.

• In the third sequential session, the scope expands to what can we do about the sorry state of things in general—how can we help all those other teams that aren’t at the conference?

• Throughout, there’ll be short demos or lightning talks about Gosh Wow neat things people have tried. (Too much problem-solving can be depressing, so let’s celebrate the neat and the new in true Retro-Futurist style.)

I was asked for more details about the pillar-based retrospectives I mentioned earlier.

Preparation

Have scrap paper or notecards, plus writing instruments.

Execution

The team assembles and sits. They get some paper.

I let a random person pick which pillar to start with. I describe it to them, then tell them to individually rate the whole team against it, on a one-to-five scale, five being the best, then write their rating on some paper. I tell them they can pick a range if they’re not sure which number to pick. (I think that’s what numbers like “3.5″ often mean.)

(In the future, I’ll have the team come to some consensus about what they mean by “one” and “five”. Some people, for example, consider “five” perfection and thus unattainable.)

When they’re ready, they hand the paper to me. While that does make it less obvious which person wrote which number, that’s a minor motivation. I do it more because it gives each person control over how long to think.

Then I plot the values on the spider chart, like this:

Then I invite the team to discuss whatever the spread or values bring to mind. If I see something no one mentions, I bring it up, but the discussion is really in their hands. Their talk may lead to action items, but I don’t force it.

After the discussion of one pillar dies down, I have someone pick the next one. (I think that each time we soon just started going clockwise or anti-clockwise.)

It seems like these retrospectives want to be about an hour long.

Part of a series on the seven pillars of a good Agile team

There’s no need for us to put on airs. Agile work is piecework. We’re like furniture makers who deal with an unending (we hope!) stream of special orders, each one being a fairly small job. Each job has to be worth it for the buyer: she has to consider the finished job worth more than she paid for it.

A team with a proper focus on business value has the right skills to do piecework. It is a reliable, predictable partner for the business.

Some evidence of good focus

• In a given iteration, the team commits to a particular set of stories. It’s surprising when they fail to deliver on that commitment.

• The team’s velocity (amount of work they did per iteration) stays roughly the same from iteration to iteration.

• Individual story estimates tend to be right. (On average it really takes twice as much time to do ‘2′ stories as ‘1′ stories, and that average isn’t achieved because the ‘2′ stories turn out to be size ‘1′ half the time and size ‘3′ the other half.)

• Done means done. After a finished story is accepted by the business, everyone should be surprised and disappointed if it has to be revisited because something that was intended to work doesn’t. (This doesn’t include cases where seeing the finished work made the business change its mind—that counts as a new story.)

• The product could be put before end users at the end of each iteration.

• The team builds only what’s required for each story. (They’ve gotten beyond the need to complete infrastructure before features can be built upon it.)

• Problems (such as wildly broken estimates) are discovered quickly, so that the business has enough time to react.

• In product conversations, you don’t hear people giving more priority to technical desires than to business value.

Part of a series on the seven pillars of a good Agile team

A product is a bundle of services. A team with product sense understands how the product fits into its environment. Team members can talk about who uses the product, why they use it, and how this product fits together with all the other products they use.

The team combines this external view with an internal one. They understand the pieces out of which the product is made. While they may specialize in one piece, they can speak sensibly of others, and they can describe the overarching principles or strategies or biases that shape the whole team’s work.

Just as there are no team members so buried in detail that they don’t see the big picture, there are none that don’t have a hand in the detail. For example, architects write code.

The team understands the history of the product, of its market, of its environment, and of their team. They know why things got to be the way they are.

Some evidence of product sense

• People on the team can convincingly answer the question “why does this work the way it does?” You’ll know you’ve found a team with product sense when you see their answers making use of different sources of information—the outside and the inside, the big principles and the accidents of history.

• The team can help direct the product’s growth because of their knowledge. For example, if a particular feature’s implementation cost is too high, they might suggest an alternative that gives most of the benefit for much less cost. Or they might suggest that the existing product makes particular kinds of features easy to support—maybe the product should grow in that direction?

• People make decisions about design or testing collaboratively, because lots of people have the capacity to make useful suggestions.

• Even changes that involve many parts of the product can be made in small, safe steps.

• Team members would be good at customer support. If the team does second- or third-level support, most anyone on the team can handle most calls.

• If bugs are reported, they’re easy to find. Bug isolation doesn’t depend on knowledge held only by Satish (who is on vacation).

A couple of months ago, Chet Hendrickson, Ron Jeffries, Bob Martin, James Shore, and I met to talk about what abilities are important to an Agile team. We cardstormed ideas, which fell into seven categories:

• Product sense
• Collaboration
• Focus on Business Value
• Supportive Culture
• Confidence
• Technical Excellence
• Self-Improvement

(I’ve added words to a few of the names.)

Three times now, I’ve facilitated a retrospective in which teams rated their abilities in each of the categories, displayed the different ratings on a spider graph, and then discussed the result. I think the results were good enough that I can imagine a team doing it every few months or so.

One difficulty I had with the retrospectives was explaining the categories well. (What does it mean to have “product savvy”?) For my use and yours, I’ll be writing a series of blog posts with the explanations I should have had ready-to-hand.

Important: These essays are my interpretations of the ability clusters. Not only are they infected by my own biases and obsessions, I’ve reclustered the cards slightly. For example, part of the reason “product savvy” was hard to explain is that it overlapped with “Business Value” and “Confidence”. While I’m sure the category boundaries could never be made clear-cut (PDF), I’m trying to sharpen them a bit.

So give credit to all five of us for the good parts, and blame the bad parts on me alone.

(I am also to blame for the “seven pillars” bit.)