I consult mainly on Agile software development, with a special focus on how testing fits in. Contact me here: marick@exampler.com
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:
(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.)
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.
