Exploration Through Example

Jason Gorman wants people to pledge that they care about software and that they’ll act on that caring. An impressive roster of people have signed the pledge. So why do I feel discouraged? It’s because of this:

[I pledge to] Offer moral and practical support to those who care as much as I do to help them do the right thing

What does that mean? How will it play out?
(more…)

Agile Alliance Functional Testing Tools Visioning Workshop
Call for Participation
Dates: October 11 - 12, 2007
Times: 8 AM - 5 PM
Location: Portland, Oregon
Venue: Kennedy School

Description
The primary purpose of this workshop is to discuss cutting-edge advancements in and envision possibilities for the future of automated functional testing tools.

This is a small, peer-driven, invitation-only conference in the tradition of LAWST, AWTA, and the like. The content comes from the participants, and we expect all participants to take an active role. We’re seeking participants who have interest and experience in creating and/or using automated functional testing tools/frameworks on Agile projects.

This workshop is sponsored by the Agile Alliance Functional Testing Tools Program. The mission of this program is to advance the state of the art of automated functional testing tools used by Agile teams to automate customer-facing tests.

There is no cost to participate. Participants will be responsible for their own travel expenses. (However, we do have limited grant money available to be used at the discretion of the organizers to subsidize travel expenses. If you would like to be considered for a travel grant, please include your request, including amount needed, in your Request for Invitation.)
(more…)

A tester is delivered supposedly-finished code that has nothing ready to test:

Half the functionality of a new feature has been introduced - the other half has not yet been completed. However the developers say this is working software because what was handed over works. But it’s no use to a beta customer site - can’t really show it to a user - can’t really test it as there is no flow. It’s a bit like saying a car ‘works’ when it has no back axle but please test away anyway because the front wheels are fine. Is there a definition of ‘working software’ anywhere?

I answer:

My definition: a feature is working if some person somewhere would be willing to pay more for the software with the feature than she would for the software without it.

Another way of putting it: at the end of every iteration, you should be able to sell the software for more money than you could at the beginning.

Sounds like your feature isn’t working.

As Chet Hendrickson pointed out in the thread, the trick is getting good at breaking Grand Ideas down into bite-sized chunks that can be implemented quickly but still do something useful. That can be hard to learn, but I’ve been impressed when I see it done well—impressed enough that I’ve come to the working assumption that it’s always possible. If you can’t see how to do it, that just means you don’t have enough experience and haven’t learned enough tricks of the trade.

Steve Gordon added:

If stories are split architecturally (horizontally), then the “working software” is quite like what you describe. If stories are sliced vertically (i.e., it does work end-to-end, but only for a few scenarios), then it is more useful for testing, feedback, and validating the architecture. Vertical slicing is what is recommended, but developers tend to think in components, so it is much easier for them to split stories into one for each component instead of figuring out which scenario (sometimes, a trivial one) they could actually do end-to-end through all the components within a single iteration.

In my experience, defining small stories is one of the toughest things for the product director to learn. Building an architecturally coherent system in small slices is one of the toughest things for programmers to learn.

As Jeff Patton has pointed out, there are dangers to small slices: it can be tricky to make everything hang together into a coherent, usable system. (See his span planning, for example.) Perhaps incorrectly, I emphasize getting good enough to be dangerous.

I’m going to start copying my replies to questions on agile-testing here.

I am interested in hearing how people that don’t think a Test Strategy should exist go about answering the following questions and when they do it. […]

• Number of testers required—including what skills they need (i.e. (Performance, Security, Domain Knowledge, Technical Knowledge) and where they will come from (current employee’s, contractors etc)

• Environments, especially for new projects. What is going to be needed, how much will it cost, when will it be required. (Some hardware can take 6-8 weeks to source)

• Data—what data will be used, where will it come from, privacy concerns

• External/Dependant requirements—for example will real users be involved in UAT/Usability Testing? When will they be involved? (If it is “general” public this needs time to organise, if they are in another country/offsite do you want someone to be there to monitor/oversee what they are doing). Is a usability lab going to be used? Does the product need to be benchmarked by an external company? When? etc.

• Software/Tools—if anything needs to be purchased this should be highlighted.

(more…)

Jason Gorman:

Contrary to - well - pretty much the entire software industry, I don’t believe that a software architect is someone who designs software. I believe that a software architect is someone who recognises a good software design when he sees one.

A Rails homage to the “I’m a Mac” commercials (via /\ndy)

The Wall Street Journal published an editorial containing this graph:

In what possible universe could you honestly fit that curve to that data? Who could, without shame, publish a curve that goes around the bulk of the data? One that goes through an obvious outlier? (Tukey’s brilliant and eccentric Exploratory Data Analysis counsels us to understand outliers before worrying about the “central tendency”. I wonder if the anonymous editorialist wondered what might be special about Norway? Perhaps a particular natural resource, drilled from under the ocean? If only there were a tool one could use to find information about that resource’s contribution to Norway’s GDP or any special tax rate applied to it!)

But, self-doubting liberal that I am, I can’t only conclude that unsigned Wall Street Journal editorials are written by people whose preferences and loyalties have made them—to use the precise academic terminology—bullshitters, people to whom the truth is completely irrelevant. I have to wonder to what degree I do the same thing, to what degree my own comfort and self-interest has led me to push back against the whole post-Agile thing, despite my respect for Jonathan Kohl and Jason Gorman.

Fortunately, I have morphing software to play with, so I can cut self-reflection short.

Hat tip to Economist’s View

Confused of Calcutta writes about risk and Agile:

Once you switch focus from content to process, agile techniques don’t stand a chance. Agile in a “content” perspective leads to the Baconian “A man that starts with doubts shall end in certainties”; agile in a “process” perspective leads to the other Baconian statement “A man that starts with certainties shall end in doubts”. These two positions are polar opposites.

As Douglas and Wildawsky stated, people act as if they know the risks they face despite not knowing them; they then disparage people who act to discover and potentially mitigate hitherto unknown risks. The Emperor’s New Clothes.

More later.

I’ll be looking for what’s coming. This reminds me of one of my themes about Agile: that it’s about acting to change the context more than it is about adapting to a context. What Mr. Rangaswami brings to my mind is the degree to which that context is always unknown.

Carnival of the Agilists is a useful multi-person roundup of Agile news. You can subscribe here. More here.

Nominations for the Agile Alliance’s Gordon Pask Award are now open. The award has changed this year from a cash grant to travel sponsorship. Here’s the description:

The Gordon Pask Award recognizes two people whose recent contributions to Agile Practice make them, in the opinion of the Award Committee, people others in the field should emulate. In order that people might emulate them, the Agile Alliance will fund each recipient’s travel to two different suitable conferences on two different continents. In order to grow the next generation of Agile thought leaders, the Award is given to people who aren’t already routinely invited to conferences, presumably because their reputation is not yet widespread.

We on the committee are less interested in funding great speakers than we are in funding people who have something to say that people need to hear. Or, perhaps better, have something to show that people need to see. Or something they do that people should do with them. We don’t even require that Pask award winners give formal presentations at conferences; it’s enough to mingle.

Please send nominations to pask-nominations@agilealliance.org.

Summary: I wrote a workbook to help people learn test-driven design. Want to try it out?
(more…)

The OOPSLA conference, originally about object-oriented programming, was the seedbed for a lot of the early conversations about Agile. It’s fallen on hard times these past several years. Now that object-oriented programming is ubiquitous; the easy patterns have been mined and the next step beyond pattern catalogs faltered; and Agile has gone off into its own conferences, OOPSLA has struggled to avoid just being the place where (1) academics go to present papers on making Java fast and (2) old comrades go for the yearly reunion.

That said, the Onward! track and the workshops remain happening places. You can say pretty edgy things—I still remember fondly the time one person said of my position paper that he’d shown it to his wife (a physician) and her opinion was that if I actually believed that, I was clinically insane. (Sadly, I don’t remember what position paper that was. Maybe I should be alarmed that it doesn’t stand out.) Even better: people will actually talk to you about your edgy ideas, help you refine them, help you make them useful. That happened to me a fair amount, so I’m grateful.

So I’d give OOPSLA a look. For exampe, here is a workshop about Agile methods in new contexts.