Exploration Through Example

Various people have spoken approvingly of this sticker on my laptop:

I’ve just ordered a pile of them. I will send you one if you send me your surface mail address. You have to promise to stick it somewhere, not toss it in a drawer or a pile of papers.

Offer good until I get tired of it. I do not guarantee that the stickers peel off well. (The one on my Macbook was tattered after six months of daily travel in my backpack. It came off pretty well, in two big strips, but left some glue behind.)

I’ve also created a new sticker:

This, I think, makes a good personal goal. It’s also the way I describe products developed in an Agile style. I say they start out wrong (or crummy), but get less wrong every iteration. They should stop getting less wrong when it’s no longer worth making them so.

Offer is good on these stickers too, under the same conditions.

(I wanted to write here something witty about the chance of me reusing or selling addresses, but I couldn’t think of anything. I wouldn’t worry about it, were I you.)

The people who run the No Fluff, Just Stuff conferences have a new one called The Agile Experience.

The Pragmatic Studio has a workshop:

The Pragmatic Studio is excited to announce the Agile Developer Studio, designed exclusively to help you and your teams succeed through agility.

In this three day workshop, you’ll learn what being agile is all about, by actually doing it! You’ll also learn how to transition your project or organization from conventional approaches to agile development practices that save time and money.

You’ll be expertly coached by Andy Hunt (of The Pragmatic Programmers) and Venkat Subramaniam, co-authors of “Practices of an Agile Developer”. Drawing from their vast project experience, they’ll help you become a better, more agile, developer.

I don’t have any personal experience with these events, but they’re from reputable people. (Not that any I didn’t mention aren’t!)

Many of the tests that currently use browser-driving tools like Selenium, Watir, or Silk could use different implementation technologies. In the rest of this note, I describe the pros and cons of browser driving, HTTP driving, the Rails variant of HTTP driving, and app-layer driving.
(more…)

I have two ideas for the kind of mini-conferences I’d like to see the Agile Alliance fund.

1. Tests as Communication. I’m not convinced that automated business-facing (acceptance) tests are, in the presence of good programmer testing, all that incredibly useful as tests—as, that is, regression tests, tests that will find bugs created when a programmer changes something here that causes a failure over there. I hope and expect that the programmer tests and exploratory testing would suffice to find enough of those bugs. So the more important purposes of the business-facing tests are (a) to help explain more clearly to the programmer what the product director wants, (b) to give the programmers a tool to structure their work and know when it’s done, (c) to help the product director think through what she wants, and (d) to help people coming upon the project later to understand something about what it’s supposed to do.

   This conference would be about (a), (c), and (d). What makes a test useful as a message from someone today to some later reader? What are the elements of test-writing style?

2. Confessional code. Way back when, I worked on a Lisp virtual machine. I had a policy that no bug would be hard to find the second time. By that, I meant that any time I found a bug hard to diagnose, I’d add code to make the next bug of that sort easy to diagnose. Over time, I produced a system that could answer those two questions parents always fruitlessly ask of children:

   • “All right, who did it?”
   • “What on earth was going through your mind that made you think that was a good idea?”

   The code was confessional, eager to spill its guts.

   In the years since then, I’ve encountered few products so forthright. I think it would be a good thing if more were. I’d like this conference to discuss examples.

These conferences would be run something along the lines of Bret Pettichord’s AWTA and the Kaner/Lawrence/Hendrickson LAWST. In brief: invitation would be based on position papers describing relevant experience or an interesting perspective; presentations would not be timeboxed; presentations would be experience reports; we’d expect the presenter to spend most of her time answering questions about what she did, why it worked (or failed), and in what other situations it might work or fail; and there would be ample time for pair and small group work on the nitty-gritty of actual examples, demos, etc.

As an aspiring internationalist, I’d like to have one conference in North America and one somewhere else (probably Europe).

If you are interested in either of these conferences, please respond in a comment. “Interested” means “I’d gladly give up a weekend to attend this conference” and “I’d willingly pay enough so that the conference could cover modest expenses.”

Thanks.

There’s been some discussion of my proposal to change the Agile Alliance. The proposal will have to be modified, but a lot depends on people’s opinions about the following. Please make your opinion known by voting.

The answer is yes. That’s how I see it.

I used to play a game with my daughter when she was around eight. I’d ask her to define a peanut butter sandwich. She’d say something like “bread with peanut butter on it.” I’d say, “So if I take a slice of bread and put a jar of peanut butter on it, that’s a peanut butter sandwich?” She’d say, “No, it’s a piece of bread with peanut butter spread on it.” And I’d say, “So if I spread peanut butter on both sides of a piece of bread, that’s a peanut butter sandwich?”

This game can go on for a long time.

I was of course trying to teach her that there is no such thing as an unambiguous requirement. Ambiguity is a three-way relationship between a reader, her conception of the writer, and the text.

“Her conception of the writer”: to some people, a peanut butter sandwich has two slices of bread. The raw statement “get me a peanut butter sandwich” is ambiguous until you know which kind of person uttered the statement.

A lot of knowledge of the writer/utterer is not conscious, because conscious thought is inefficient. We spend a lot of time just knowing that other people know that we know what they want. When Sophie asks for a peanut butter sandwich, I short-circuit any consideration of what a peanut butter sandwich really is by knowing what she wants and knowing what past actions have caused her to be satisfied.

That’s part of the reason why requirements are most efficiently transmitted face-to-face.

UPDATE: Joseph Bergin contributes a requirement that depends critically on shared background knowledge and a willingness to overrule the literal meaning:

I believe I heard this story from Ken Schwaber. I’m not sure.

Once there was a team who wanted a bullpen environment, but the Furniture Police wouldn’t let them tear down the cubicles. That was an impediment to the team. The ScrumMaster came in over a weekend with tools, took down the cubicles, and made a bullpen. On Monday, he or she said that if the cubicles came back, they would have to fire her. Impediment removed.

Back in the day, I was heavily associated with the context-driven school of testing. I still honor it, but I do assert that Agile is importantly different. It is context-driving, not context-driven.

That is, probably the key question in the context-driven school is “given my context, what’s the best thing to do?” (See the two-project example at the link above.)

The question in Agile is much more “given my context, what should I change about it to allow me to work more as I please?”

Obviously there’s overlap, blah, blah, blah. But the different emphasis leads to different actions leads to different projects. At least in my case.

UPDATE: Since I link to this post occasionally, here’s an email I sent once that adds a bit to it:

I’ve come to think of Agile as /context-driving/ rather than /context-driven/. This comes up in the perennial debate about whether there should be 100% test automation. A lot of that debate is tedious and silly, but there’s an important facet that too often goes unmentioned. Programmers have reasons for wanting 100% test automation, important among them that programming is less stressful with test support. It is a fact in many projects and code bases that some proportion of tests programmers would like to have automated are not worth automating by any dispassionate standard. The historical context-driven-testing answer to that problem is to accept it and find the best possible blend of automated and manual testing (and to make sure that both are done well). The programmers’ context-*driving* answer is to change the context so that the economics change to make 100% automation economical.

Now, that attempt to change the context could work, or it could not. As it turns out, it’s worked surprisingly well across a broad range of problems, which makes me want to continue pushing in that direction, rather than growing up and admitting some things are impossible.

Rachel Davies recently needed to step down as chair of the board of the Agile Alliance. I’d proposed the following in response to my disquiet over the state of Agile as it moves into the mainstream, so someone suggested I run for chair on a platform of carrying it through. I did, and I was elected. I’ll be chair until August, and I take it as my responsibility to bring some derivative of this to a vote of the membership. We’ll be working on this proposal at the Agile Software Development forum. Help out, please.
(more…)

One of the hard things about teaching people Agile is helping them understand that the product starts out crummy—barely functional, probably looking really crude—and then keeps getting better and better each iteration. That stops when you reach the release date, or when you decide that all the remaining ways you can see to make it better aren’t worth the expense.

Stories, metaphors, declamations—they all help, some, but I think what I need most is a video like one of those time-lapse movies of a flower opening or a butterfly emerging from a chrysalis. I started making one by taking short quicktime snapshots of a product at the end of each iteration, but let it slide.

This last consulting visit, I was working with a product owner, and I realized that the famous 15 minutes to a weblog Rails video is like what I’m looking for. There’s a lot of commentary interesting only to a programmer, and it never does get a flashy UI, but there’s also visible growth.

The rest of the post gives a timeline so that you can skip around.
(more…)