Exploration Through Example

AGILE 2008 CONFERENCE in Toronto, August 4-8, 2008

Anyone who is involved in, or wants to learn more about, agile development is invited to participate in this exciting conference!

Agile2008 conference is run as a program of Agile Alliance. We are scaling up the conference for an ever-increasing and diverse agile community. After the sell-out of Agile2007 we are expanding to a larger venue which can hold an audience of 1600+ attendees!

To facilitate this growth, Agile 2008 has adopted the metaphor of a music festival that provides multiple stages to attract audiences with common interests. The stages within our program are designed and organized by experts (acting as stage producers) who are truly passionate about their particular areas.

(more…)

Jason Gorman

“And that, folks, is how enterprise-scale reuse works. It is, I tell you. It’s true!”

Ben Simo

“We can’t stop the conversation at ‘I just did that and I’m a user.’”

The “no user would do that” retort is the bane of testers. Ben talks well about moving the conversation past that. But a step further: any project I’d want to work on is a learning project, one that wants to be less wrong than yesterday, one that likes finding out about mistakes. Get past this particular conversation: fine. Maybe testers could even train programmers to swallow that particular reflexive retort. But the defensiveness about having partial understanding will still leak out other places.

Now, I once sat down with Elisabeth Hendrickson while she tested an app of mine. I’d built it with TDD to the max: business-facing tests all the way down to unit tests. It took her about ten minutes to find a high-priority bug. I immediately slipped right into the defensive programmer stance. It took me a few minutes to snap out of it. But if we worked together for longer, I’d like to think I’d get past that.

I aspire to be like Mark “capabilities” Miller, a programmer I once worked with. When someone found a bug in his code, he’d write a long email about it, praising the person, attributing all sorts of cleverness to her, and explaining how he’d come to make that mistake.

Bret Pettichord

“People often recommend that you treat a bug as a story. […] I think this approach is incorrect. We’ve found a better way to handle [bugs].”

I want to disagree with Bret, but I haven’t come up with a counterexample that convinces even me.

Milton Mayer

“What happened here was the gradual habituation of the people, little by little, to being governed by surprise; to receiving decisions deliberated in secret; to believing that the situation was so complicated that the government had to act on information which the people could not understand, or so dangerous that, even if the people could not understand it, it could not be released because of national security….

“And one day, too late, your principles, if you were ever sensible of them, all rush in upon you….The world you live in — your nation, your people — is not the world you were born in at all. The forms are all there, all untouched, all reassuring, the houses, the shops, the jobs, the mealtimes, the visits, the concerts, the cinema, the holidays. But the spirit, which you never noticed because you made the lifelong mistake of identifying it with the forms, is changed.”

A transcript of an OOPSLA talk: Table of contents

Here is the table of contents for a set of postings that, together, are a transcript of an OOPSLA talk on Bruno Latour and Actor-Network Theory (ANT). I will add links as I post new entries.

1. Testing as an example: I use Actor-Network theory as a way to get ideas while consulting. Here’s one example.

2. ANT and the building of the social: ANT is about tracing how “actors” (people and things) in a story push on each other. Stable patterns of interaction produce social objects like neighborhoods.

3. Anthrax and standups: ANT analyses often give uncommon weight to inanimate objects. How that gave me an idea to make standups less dull.

4. An ANT reading list.

5. The divide: Early Agile, especially XP, had an ANTian delight in the interplay between the social and tools. That’s being lost. Someone should do something about it.

A transcript of an OOPSLA talk: Table of contents

Shift gears now to the daily standup. There’s a ritual: someone says what she did yesterday, what she plans to do today, and what impediments she sees in the team’s path. Good standups are crisp and motivating. A lot of standups are bad. They have the enervating effect of an hour-plus weekly status meeting, only spread out over a week.

Why is this? And what can be done about it?

To answer, I’ll start with the story of the anthrax bacillus from Latour’s The Pasteurization of France. At one point, there was a disease called “anthrax.” People understood the properties of this disease: they knew what symptoms it had, they knew that people could contract the disease from warm corpses but not from cold or rotten ones, and they knew that some “accursed” fields gave anthrax to any animal that grazed there.

Pasteur wanted to replace anthrax-the-disease with anthrax-a-bacillus. He undertook a fairly systematic programme:

• Early on, he could induce the symptoms of anthrax by extracting icky stuff from a sick animal, diluting it fantastically, and then injecting a tiny bit of the dilute solution into a new animal. However: so? No one sneaks around at night injecting cows in fields.

• So the next step is to induce anthrax by a more natural means. They tried feeding the animals hay laced with anthrax, but that didn’t give them the disease. However, a feed more representative of real life—feed containing prickly nettles—did. So there’s a realistic way animals can get the disease that’s directly traceable to the idea of injection.

• What about the slaughterhouse workers and the safe corpses? Well, it turns out that anthrax forms spores to ride out harsh environments: like the cold, nasty environment of a dead animal. That’s a plausible explanation for what renderers know. One more bit of anthrax-the-disease can be explained in terms of anthrax-the-bacillus.

• There’s even a reason for accursed fields. Suppose someone buries an animal dead of anthrax. You’ve basically buried a whole pile of spores. In dirt. That contains earthworms. One of the things that earthworms do is turn dirt over, moving dirt from down below to the surface. As a side-effect, they steadily replenish the surface with spores. Result: an accursed field, perhaps accursed well after the last person’s forgotten anything was buried there.

• And, finally, you can do more with the bacillus than you can with the disease. In particular, you can make a vaccine.

At some point, anthrax-the-disease can be understood in terms of anthrax-the-bacillus. Roles switch: now if you want to say something about the disease, you have to be prepared to trace that statement back to the bacillus.

In the jargon, the bacillus has become an obligatory point of passage.

One of the things we’ve done in Agile is to make the frequent creation of running, tested, potentially shippable software into an obligatory point of passage. Teams that don’t produce potentially shippable software at the end of each iteration are likely in trouble. Moreover, team members ought to be able to trace what they’re doing to the goals of the release; if not, they ought to be prepared to question what they’re doing.

In order to understand and pace the work of the release, it’s convenient to break it down into smaller pieces, individual stories. The stories are also individual points of passage, just littler ones.

Dull standups often make no reference to visible stories. Either people don’t have a wall with stories on it, they don’t do the standup in front of that wall, or they don’t gesture at the wall while speaking. In ANTian terms, they’re demonstrating that the stories aren’t really obligatory points of passage. What to do about that?

Another trick of ANT’s is not to bother making a distinction between humans and other kinds of actors. So, when Kent Beck writes, in the introduction to Smalltalk Best-Practice Patterns, “If you’re programming along, and all of a sudden your program gets balky, makes things hard for you, it’s talking,” an ANT analysis wouldn’t report that with a side-comment like “Of course, programs don’t really get balky.” Lots of programmers talk as if code can push back, so why not take them at their word and see what comes of that?

A while back, I was thinking along these lines when I realized that if the stories are so important to the project, they ought to be the ones speaking in the standup. I imagined a story card saying, “Brian’s going to keep working on me today, but he’s having trouble. He could use the help of someone who knows Hibernate.”

Now, I never had the nerve to actually suggest that team members ought to hold the story cards like little mouths, open and close them, and pretend it was the stories talking, but while I was preparing for this talk, I had another thought. Yes, the stories can’t talk, but there’s no reason not to structure the standup around them. Instead of going around the people, you can step through all the stories in play. For each, someone can say what happened to that story yesterday, what’s to be done on it today, and whether there are any risks to its completion.

I plan to recommend that clients give this a try. At least, it will cut out conversational deadeners like “I paired with Dawn and Karl, so I did the same thing they did” and “I can’t remember what I did.” [I’m also pleased that two people said they’d try it on their teams when they got home.]

So, there: another example of using a weirdo theory from sociologist to give myself ideas.

Story board from arbdesign.dk, woman with fish from Willem Velthoven.

From November 30 through December 2, I’ll be at the free Simple Design and Test Conference in Pennsylvania. I’m going to try to spend some time this month thinking of something fun and enlightening and experiential to do. Here’s the official blurb:

After the great response from the last year’s, first Simple Design and Testing Conference [SDTConf] in WestChester, PA, we are planning to organize another conference this year.

Dates: Nov 30th - Dec 2nd
Venue: Penn State University York, PA.
Target Audience: Developers, Designers, Architects, DBAs and Testers
Conference fee: Free.

SDTConf is focused on providing Agile practitioners a platform to meet face-to-face and discuss/demonstrate simple design & testing principles/approaches. The conference will use Open Spaces to structure conversation, improve understanding, facilitate brainstorming and help innovate.

This conference is not just limited to discussions; we are also planning an exclusive track for hands-on-sessions. This session will give practitioners a platform to work on some of key design and testing issues.

Online registrations [http://www.sdtconf.com/reg.htm] are open now. If you plan to attend this conference, please register ASAP, as we have only 115 seats left.

We are also looking for sponsors, who can sponsor in kind. Ex: Conference T-Shirts, Food, Stationary, etc

Please feel free to forward this announcement to anyone interested.

Look forward to see you there.

Naresh Jain
http://agilefaqs.com
http://agileIndia.org
http://www.sdtconf.com

I’m going to be producing another poster. Current draft:

Do the words “work with ease” get the message across? Or can they be interpreted as “kick back and work as little as possible”? Or as “work should be easy”, which is not quite the same thing?

If they don’t, what few words might? (Keep in mind the space constraints of the poster.)

I’m also considering turning this (and perhaps the other) into a T-shirt. That would allow room for a longer slogan, perhaps “reach for a tool, and it is there” or (more obscurely) “My tools are ready-to-hand“. Suggestions?

(Unrelated questions: If you want to deal easily with print shops, is Illustrator + eps files really the only game in town?)

Complete table of contents

At OOPSLA in Montreal, I gave an invited talk on Actor-Network Theory (ANT), a style of observation and description that’s most associated with the French philosopher/sociologist Bruno Latour. I told some stories about how I use ANT in my work. I also said some hotheaded things about its relevance for some problems I see with Agile. Because blog posts should be short, I’m going to blog this talk in pieces. Here’s the first.

(This first bit is something of a retread for those who’ve been reading my blog since 2003.)

I’m a consultant. I drop into projects for about a week. I work with the people on the project—pairing, testing, whatever. Along the way, I’m supposed to notice things they don’t see and make suggestions they haven’t already tried, all with the aim of helping them get better at building software.

A tough job: projects are complicated, with lots of moving parts. It’s terribly easy as a consultant to see only the things you’re used to seeing. Worse: it’s easy to see things that aren’t there, just because they’re the things you’re best at seeing.

So a consultant needs mental tricks to kick himself out of ruts and habits. I use ANT as such a trick.

An example: the role of testing in Agile projects

One thing ANT people do is pay attention to things and how they move around.

In the mid-to-late 70’s, Bruno Latour—a philosopher who knew little English and less biochemistry—arrived at the Salk Institute in San Diego, California. Not only did he know little about the content of the work they did there, he deliberately tried to forget what he did know. He wanted to be like an anthropologist visiting some completely foreign tribe with a completely different culture.

As you might expect, some of his observations were odd. For example, he saw that there was one place in the laboratory where, at periodic intervals, bound sheaves of paper called “journals” were delivered.

At other places, people called “technicians” tended expensive and balky machines whose purpose seemed to be to make marks on paper (line drawings, blotchy pictures, lists of numbers, and the like). These two sets of paper were delivered to a third place, the “offices” of the “scientists”. The scientists put the two types of paper—journals and “experimental results”—next to each other and compared them. As (and after) doing so, they would write things on new pieces of paper, which they would deliver to a place inhabited by “typists”, who would “type them up” (put them in a tidier form), then send them out the door to “publishers” who would, in due course, bind them up together with other “papers” and deliver the resulting journals to… still more laboratories.

To Latour, it seemed the laboratory was a factory for turning paper into more paper.

Now, Karl Popper, likely the most influential philosopher of science, would describe all of what Latour saw as an epiphenomenon, not what science is really about. What science is really about is this:

1. A theoretician comes up with a theory. Oddly, the examples always seem to use really great theoreticians, the ones you’ve all heard of.

2. Someone—maybe the great theoretician, maybe someone else—makes predictions from that theory: in situation X, the world should do thing Y.

3. An experimenter—who you quite often won’t have heard of—will create situation X and observe whether the world does thing Y.

4. If the world does not, the great theoretician has to discard the theory and try again.

5. If the world does do Y, that does not confirm the theory. No number of confirmed predictions logically proves that a theory is true. If, however, the theory passes a sufficient number of challenging tests, scientists are justified in accepting it and using it in their own work.

Popper’s opinion matters to me because some software testers make explicit analogies between Popper’s view of science and testing:

1. The programmer is like a theoretician, proposing a theory like “for any input X typed into this text box, the program will calculate f(X).”

2. The tester turns that into a prediction. “So the program should calculate f(X) if the input is one of those things we call a SQL injection attack.”

3. The tester sets up the experiment, tries a SQL injection attack.

4. If the program doesn’t work as predicted, the programmer has to go back and try again. The tester gets a little thrill, because it really is fun to break programs.

5. If the program passes the test, it may still not be correct—no number of passed tests suffices to prove the program is bug-free. But if it passes a sufficient number of challenging tests, managers are justified in releasing it into the world.

The problem is the effect on an Agile team. At the time I was thinking about this (around 2002), there was lots of tension between testers and Agile proponents. Unwise things were said on both sides. Against that backdrop, the testers’ normal drive-by defacements of the programmers’ programs—and the programmers’ egos—wasn’t contributing to the unity of effort I believe is so important on Agile teams. One could say the programmers should be more egoless, but I’m more inclined to work with the grain of human nature than against it.

Popperian science seemed to be the wrong metaphor. (Besides, having read people like Feyerabend and Lakatos, I was pretty skeptical that Popperian science had anything much to do with how real scientists came to accept theories.)

At some point, a detail of Latour’s book describing his Salk experience (Laboratory Life, with Steven Woolgar) came to me. During the process of turning paper into more paper, scientists would hand out “drafts” to other scientists. They’d then get together to discuss the drafts. The conversation would have this tone:

There’s a good chance that Morin is going to be one of the reviewers of this, and you know how she is about antibiotic treatment. If you want this to get past her, you’ll need to strengthen this justification here.

or

I can help you with SAS, make the statistical analysis more solid.

or

If you included the results of assay X, more people would be interested. I can lend you my technician.

The effect is one of people anticipating what dangers the paper will face when it ventures into the world, and making suggestions about how it might be muscled up to survive them. Although I don’t think I realized it at the time, this is the style of paper reviewing that Richard P. Gabriel had imported from the creative writing community into the design patterns community. (See his Writers’ Workshops and the Work of Making Things.)

This, I realized, was a way of having testers’ skills contribute both to the product and also to the team’s feeling of unity of effort. So I began using this new metaphor in my consulting. The particular suggestions I make depend on the team. I might nudge the testers into the role of supporting the (typically overworked) product owner. They could help her talk more more precisely and comprehensively about what she wants. They could then turn that clearer description into tests that programmers could use in the familiar test-first way. Or I might nudge them into the role of teaching the programmers about the domain, one test at a time. (This affects the kinds of tests you write and the order in which you use them.) And so on.

I think this style of thinking about testing is now pretty common in the Agile world. It probably would have happened without me—I’m by no means the only person to think along those lines. That’s not the point: the point is that I probably would not have thought of it had I not absorbed a bit of Latour’s way of looking at things.

When the hell are personal computer software makers going to let us recover from crashes as well as Emacs has done for well over twenty years? Most of a day’s work lost, and it is not my fault, because it’s not my job to develop the right reflexes for your stupid program!

At the functional testing tools workshop, Ward Cunningham devised a scheme. John Dunham, Adam Geras, Naresh Jain, and I elaborated on it. Before I explain the scheme, I have to reveal the context, which is different kinds of tests with different audiences and affordances:

As when I first encountered wikis, I missed the point of Ward’s newest thing. I didn’t think swimlane tests had anything to do with what I’m interested in: the use of tests and examples as tools for thinking about a piece of what the product owner wants with results that help the programmers. With swimlane tests, the product owner is going to be mostly reactive, saying “these test results are not what I had in mind”.

What I missed is that Ward’s focus wasn’t on driving programming but on making the system more visible to its users. They were written for the Eclipse Foundation. It wants to be maximally transparent, and the swimlane tests are documentation to help the users understand how the Foundation’s process works along with assurance that it really does work as documented.

What Ward noticed is that his output might fit together nicely with my input. Like this:

Here, the product owner begins with an executable graphical example of what she wants. The programmers produce code from it. As a user runs that code, she can at any moment get a bundle of pictures that she can point at during a conversation with the producer and other users. That might lead to some new driving examples .

The point of all of this? It’s a socio-technical trick that might entice users to collaborate in application development the way wikis entice readers to collaborate in the creation of, say, an encyclopedia. It’s a way to make it easier for markets to really be conversations. John Dunham dubbed this “crowdware”.

It won’t be quite as smooth as editing a wiki. First, as Naresh pointed out, the users will be pointing at pictures of a tool in use, and they will likely talk about the product at that level of detail. To produce useful driving examples (and software!), talk will have to be shifted to a discussion of activities to be performed and even goals to be accomplished. The history of software design has shown that we humans aren’t fantastically good at that. Adding more unskilled people to the mix just seems like a recipe for disasterware.

Wikis seemed crazy too, though, so what the heck.

Laurent Bossavit and I are working on a site. Once it reaches the minimal features release, I’ll add some crowdware features.

I realized at the functional test workshop that, to some extent, the six years of Agile have replaced development teams whining about incomplete requirements with development teams whining about the lack of a product owner’s time.

Really: is that progress?

Well, yes. At least we’re not still whining about changing requirements.

Nevertheless, this flash made me think about that old XP metaphor of the Customer driving the project like a person driving a car. When you drive, you don’t think about the steering wheel, you simply think about turning the car, and it turns. The steering wheel, the philosopher Heidegger said, is ready-to-hand. But when the power steering goes out, suddenly the steering wheel is in your face. What was once a simple reflex is now a conscious act. The steering is present-to-hand.

A tool being present-to-hand can be good or bad, but it’s always disconcerting.

Think of it: to the product owner, the team is always present-to-hand. She must attend to them. It’s not like driving at all.

Directing a product team must be something like my telling my 12-year-old to clean his room. When I do that, he goes off, comes back, and reports that he’s done. When I look at his room, I see 18 different things that are still lying on the floor. I have to painstakingly tell him 18 different things to pick up. Were it not for my steely determination to raise presentable human beings, I’d just do it myself.

That feeling is what it must be like to be a product owner.