Fit has some problems:

• Tables turn out to be the exactly right language for only a restricted set of problems. Other problems can be squeezed into that format, but awkwardly. For those people who get new ideas while explaining things in writing, the awkwardness gets in the way of those ideas.

• Everyone hates editing HTML. That's true even if you're editing it with Word or Open Office. I don't think either one of them is all that great about handling tables, and HTML tables are noticeably more painful than native document format tables.

• Programmers don't like using Fit because they have to leave their programming environment. It's also arguably harder to write support code for Fit than for JUnit (though I'm not convinced).

Maybe I'm groping toward a solution.

Here is a Fit table that talks about a data conversion that's driven by a configuration file:

That looks reasonably attractive. You'd be appalled if you knew how much time I spent on it.

Here is the same test in a different format:

That's an OmniGraffle file. I think it required less fiddling to create. Updating seems to be easier. I think it would be more useful as documentation than the previous test would.

What I've done behind the scenes is extend my existing Graffle parser to handle files like this. I still use the Fit engine behind the scenes, as you can see from the output:

Not so nice to read, but how many product directors really look at test output?

Now the question is: how could this use JUnit as the test execution engine instead of Fit?

Then the question after that is whether I could use a less obscure app than OmniGraffle to generate the tests. Anything that puts out XML should be roughly the same difficulty.

Here are three sites that use pictures to show what Agile artifacts and physical environments look like.

BillWake
Rachel Davies
William Pietri

Two interviews with me recently went online. The first, at On Ruby, is about Ruby, amazingly enough. Also about Everyday Scripting with Ruby. The second is from Dr. Dobb's and is mainly about testing in Agile projects. A lot of overlap with this blog.

While I'm talking about metaphors...

A very long time ago, I learned to fence. What you see above is a lunge. A lunge moves you from a defensive posture to an attacking one—you're trying to stab the other person. But notice that the figure is balanced. Its center of gravity is between its feet, and it could remain in that position without tipping either forward or back.

If its opponent counters the attack and launches a counterattack, it could recover backward by pushing off the front leg, snapping the back arm up, and reassuming the original en garde position:

But suppose the opponent retreats away from the attack. Then our lunging figure can recover forward: keeping the center of gravity as is, pull the back leg in and curl the back arm. Now it's ready to keep pressing the attack: it can lunge again or move forward in a more guarded way.

The important thing here is that—despite the failure of the original attack—the manner in which it moved forward allows it to keep moving forward.

Software teams often seem to be unable to recover forward. If they make a wrong decision, they land off balance:

The can scramble awkwardly backward (svn revert), leaving them worse off than before:

Or they can bull forward along a path they would not have chosen, had they known then what they know now, jabbing repeatedly and getting more and more off balance:

What they're unable to do is make use of where they are to take what now appears to be the best path:

For those of us who are merely mortal, it seems the best way to be able to recover forward is to practice the right stance. Get yourself into lots of situations where you end up going down the wrong path. Instead of reverting backward to a known stable state of code, add and rearrange code to move forward.

A good way to get yourself into those situations is by only writing the code that's needed for the small feature you're working on right now. Then some later small feature will make you recover forward—and learn about how your stance is imbalanced.

Some people believe you can recover forward from pretty muchanything. (RonJeffries' ExtremeProgramming Adventures in C# demonstrates recovering forward froma design that doesn't support undo to one that does.) Others don't. Idon't know what my opinion is, but I believe most people could recoverforward a lot more than they think they can, if they practice.

The trick is persuading them to practice.

Credits: I learned to move forward instead of revert from Zhon Johansen. The first photo is from Dr. Stephan Dann and is licensed under the Creative Commons Attribution-ShareAlike 2.0 license. The second photo is from http://www.tcnj.edu/~fencing/glossary.htm; there's no copyright notice, but it looks to be from an old fencing book.

At SDTconf, there was a session onhow to improve skills. It is too easy for people to come into a jobnot knowing enough and then get stuck at that level. Perhaps theydeserve being stuck; perhaps they should be studying on theirown. Nevertheless, they aren't, and their lack of skill sometimes(often?) preventsreally successful Agile projects from forming.

What to do, given that your typical 2-3 day course delivers some knowledge and some motivation, but not skill?

Chet Hendrickson had an idea. This is how I remember it:

• Find a deserving charity that needs software. Some stable organization (such as the Agile Alliance) offers to build it for them. The charity has to promise to be involved: onsite customer, for example. The project would have to be located where the charity is.

• The project would be started and anchored by people who really know Agile.

• Corporations, especially big ones, contribute to charities. Sometimes they contribute the time of some of their people. We'd be asking them to contribute two weeks of the time of software people to our project.

• Those people join the project at staggered one week intervals (so that each week has some "old timers" and some new people).

• They learn by doing.

I'd like to be involved in this, but I don't see myself starting it up.

Descriptions of standups usually include the three questions, the last of which is something like "Are there any impediments in your way?" Listening to a standup a couple of days ago, I realized I've been hearing a pattern for years without paying attention:

"... No impediments."
"... No impediments."
"... Haven't heard back from X about the schema."
"... No impediments."
"... My new machine is still in limbo somewhere."
"... No impediments."

I realized that "impediment" was being interpreted as something outside the team. But the metaphor of "impediment in your way" doesn't really work. The thing that's most often in my way is me: I don't know something, I'm thrashing around compulsively, etc.

I wonder if the word "impediment" is making people less likely to say what really needs to be said: "I can't do this alone. I need help."

(Random tip: when working with teams new to standups, I often take the most looked-up-to person aside and urge her to be the one to ask for help, hoping that will give other, less confident people the courage to be vulnerable.)

It seems to me that standups are often about what people did and are doing. They're like little slices of people's lives. Shouldn't they be more about the stories from this iteration? About how stories are progressing toward becoming complete?

Holding standups in front of a story wall helps. People tend to gesture at the stories while they speak, making them the focus of attention.

I was wondering today what it would be like if people pretended it were the stories themselves speaking:

Convert font changes into table cells (as interpreted by Dawn): Brian and Dawn worked on me all day yesterday. They plan to work more today. One of them should probably swap out, since they're getting stale.

Ajaxy update of main page (as interpreted by Chet): I'm done, coded and tested. I'mmoving over to the Finished swim lane. [It uses Chet to move it over.]

That's too silly, except maybe for teams neophilic enough not to need it. I don't think I have the nerve to recommend it.

... I told her there was hope for the Big Apple yet.

"It all depends on our ability to devise a set of robust arguments favoring either scientific materialism or theistic revelation and then commmunicating the salient points to the Martians in their nonlinguistic language, which was apparently deciphered several years ago by a paranoid schizophrenic named Annie Porlock," I told Valerie.

"That's not a sentence you hear every day," she replied.

—James Morrow, in The Cat's Pajamas and Other Stories, "The War of the Worldviews"