Exploration Through Example

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.)

The site is here. I’ve added two new stickers.

I’m thinking of using this site to work on my Ramaze chops. Suggestions for things to add?

Is your young artisanal retro-futurist or team-scale anarcho-syndicalist graduating this year? Stumped for a present? Well, ponder no more, because exampler.com is offering this heirloom-quality 3×5 sticker:

It’s the gift they’ll treasure forever.

And that’s not all!

In honor of this year’s graduates, we’re offering the sticker not for $10, not for $5, but absolutely

FREE!^*

No hidden charges! No shipping and handling fee! No salesman will call! No saleswoman either!

Operators are standing by. Email marick@exampler.com today!^**

^* Recipient must display the sticker in such a place and in such a manner as to prompt passersby to ask questions like “I understand and support team-scale anarcho-syndicalism, but might you explain to me how retro-futurism can be artisanal, please?” Offer good while supplies last.

^** This is a serious offer. You don’t have to be a graduate or know a graduate. Specify if you want one of my other stickers too. I’m out of posters.

Here’s a tidbit I got from either Feyerabend or Lakatos, I forget which.

It’s easy to make fun of the Aristotelian theory of motion. It held that each element seeks its natural place. That desire leads to a downward or upward force (depending on where it is). The speed at which an object moves is proportional to its mass.

What a dummy! Why didn’t Aristotle roll some balls down an inclined plane so that he could see that light objects roll at the same speed as heavy ones? Galileo did. Partly as a result, we now have a completely different theory of motion.

The interesting tidbit is that Aristotle’s theory was broader than Galileo’s. Galileo’s could say nothing about why smoke rises or why plants grow upward, questions Aristotle’s theory covered.

Lakatos tells us that, in science, theories often begin by explaining less than the theory they seek to replace. I think that’s probably true in other fields. Consider testing in Agile projects. There were existing theories of testing. Agile came in with its own theory (test-driven design, broadly construed) that, for example, simply ignored an entire class of bug—the fault of omission—that’s extremely important. The result, in many testers’ view, was like Galileo stubbornly refusing to acknowledge the problem of smoke. Outrageous!

But intellectual structures don’t remain stable. In some cases (like plant growth), a question ends up belonging to an entirely different field of study. For others (perhaps smoke), the upstart theory expands its domain enough to once again be relevant. Or the upstart could fade away. And so on.

It’s not clear how testing in Agile projects will shake out. In recent tweets, Michael Bolton has seemed to call for testing and TDD to go their separate ways. Others, like Elisabeth Hendrickson seem to me to be working to weld the two together more tightly.

I like to think that understanding they’re participating in a recurring historical process would make upstarts less overbearing and those facing upstarts less defensive. I like to think lots of things that have zero evidence behind them.

From June 16 to ??, I’ll be in Portland to work on Travels in Software. If you’re a person I should interview, mail me.

I’m also interested in observing teams who do something well that they’d like to show off. Since I learn best by doing, I’ll pitch in if I’d be useful. I’d be happy to pair with people, following in Corey Haines’ footsteps.

If you’d like to look at my RubyCocoa tests and help me make them more clear, I’d be grateful. And if people would like to have some sort of Barcamp-ish RubyCocoa/MacRuby get-together, I’m up for that too.

I can also give talks if people’d like. I can repeat the talk I’m doing at Agile Roots or the Mountain West RubyConf talk on test-driving GUI code.

In sum: I’m going to Portland to vacuum up knowledge and skills. If I leave some behind, that’s good too.

Interesting survey:

How about you? How long would you have lived in the middle ages? Ignore all the general risks - like typhoid or the plague or cholera - that everyone would have faced in general. Let’s assume you were lucky and missed those. (Unless by some chance you actually DID face one of them in your life.) Also ignore the fact that your deadly injury might have been caused by modern technology, like an auto accident. Just pretend you were trampled by a horse or something. So, given the injuries and illness you’ve faced in your life so far: Did you make it? Would you have survived to your current age?

I would have died at 13 due to a ruptured appendix.

Judy Olson (University of California, Irvine) will be presenting a colloquium entitled “Distance Collaboration: What makes it successful?” on Thursday, May 21st at 4 pm. The colloquium will be held at Frances Searle 2-370.

For more information on the TSB speaker series (and to sign up for announcements), visit http://tsb.northwestern.edu

To add upcoming TSB talks and events to your Google calendar, visit the TSB Colloquium Series Google calendar.

DISTANCE COLLABORATION: WHAT MAKES IT SUCCESSFUL?
Judy Olson

ABSTRACT:
Many organizations, many sciences, and many of us have collaborations with people who are not nearby. We and they use various technologies like shared files, email, blogs, instant messenger…to support their work. Some of these collaborations work; others do not. What makes them succeed? We have collected data from 200 collaboratories, deep data from about 30, plus data from 20 sites in corporations, to determine what makes the collaborations work, what makes them fail. I will review this line of work and describe the factors that are apparently most important in both science and corporate long-distance work. All of us may benefit in learning these factors to ensure that our own distance collaborations succeed.

I’ll be giving a keynote at the Agile Roots conference:

The topic is, unsurprisingly, Artisanal Retro-Futurism ⊗ Team-Scale Anarcho-Syndicalism. Here’s the blurb:

A problem with the word “Agile” is that everyone already thinks they understand it at a gut level. Worse, everyone already thinks they’re agile in spirit. (After all, the thesaurus tells us the alternative is to be clumsy, stiff, slow, and dull.) So it’s too easy for people to feel free to launch into “doing Agile” without ever having a serious conversation about what that actually means.

This problem is easily fixed. We’ll just stop talking about “Agile” and start speaking of “artisanal retro-futurism crossed with team-scale anarcho-syndicalism.” There is, I think, no danger that anyone will reflexively say, “Yes! That’s just what I’ve been wanting to do all along!”

The new name does more than just encourage conversation. It encourages conversation about those very properties of Agile that have become obscure as Agile has been commodified. In this session, I’ll unpack the meanings of the new phrase and encourage you to rediscover what’s been lost.

I hope to have trinkets.