Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick
191.8 167.2 186.2 183.6 184.0 183.2 184.6

Mon, 25 Oct 2004

Help for customers

I'm at OOPSLA. Today, I was at a workshop on the Customer role in Agile projects. A group of us tried to write down problems and solutions we've seen customers having and using. I like the results. Here they are.

Note: I fancied up the problems and solutions with a running narrative. Of the rest of the group, only Jennitta's seen even a fraction of what you see. So what I say may not be an accurate record of what someone meant. But I have deadlines to meet (and miles to go before I sleep), so this is going to go into hardcopy without their review. We may fix it up later.

Nickieben Bourbaki Is a Customer on an Agile Project.
Boy, does he have problems…

Something about the problem
Something about solutions
Nickieben was originally consumed with fear. The project seemed far too much work to complete in the time allowed, and he would be responsible when it failed.
Time was the solution. As iterations delivered visible business value, he showed some of it to his Lords and Masters. They were pleased with the progress, so he grew calmer. As the business environment shifted, they changed the product direction, and Nickieben and the team showed they chould change with it, which further pleased the L&M's.

It would have helped Nickieben a lot if he had had a support group of other Customers who could tell him what being a Customer was like, but he didn't.
Planning meetings lasted way too long. Many people were uninvolved for big chunks, and the meetings seemed to drain the energy out of the whole team.

And, for all that, the resulting estimates were not very good.
Nickieben started having "preplanning" meetings the iteration before. In them, he, a tester, and a programmer would discuss a story, write some test sketches, and make an initial estimate. People came to the planning meeting prepared for a short, focused discussion that informed the rest of the team and asked them to look for errors in the estimate.

Nickieben's since discovered that other teams also do preplanning. The meetings vary in form, membership, the thoroughess of the discussion, etc. For example, one team had some analysts who spent the iteration ahead of the programmers predigesting the requirements, learning how to explain the domain (which was very complex), and writing tests.  Nickieben doesn't think there's one right way to do it, but he does now have a motto: "Meetings must be snappy".
Early on, it seemed that the programmers focused much more on the technical tasks that made up a story than they did on the story itself. It seemed that the tasks were therefore inflated: the programmers did what "a complete implementation of task X" meant, rather than just enough to make the story work.
Nickieben kept harping on the stories as the thing that mattered to him, not tasks. He learned to pare stories down into small "slices" that stretched from the GUI, through the business logic, down to the database. As the programmers got used to making one slice at a time work, they learned that they didn't have to write lots of infrastructure up front.
At first, Nickieben was indecisive about prioritizing stories. He couldn't decide among the different stories that might go into the next iteration.
Short iterations helped after one of the programmers pointed out that any scheduling mistake he made could be corrected in less than two weeks. So the cost of getting something wrong wasn't too big.

He forced himself to prioritize by writing down the cash benefit of each feature. Now he didn't have to decide which of two features was worth more; instead, he independently decided on worth, then used the cash benefit to pick.

He'd started out using a spreadsheet to track the backlog of stories, only writing them on cards when he'd decided on what should go in the iteration. Later, he switched to writing everything on cards. When it came time to thinking about planning, he'd spread the cards out on a table and push them around. Important cards went "up" (farthest from him), and the lesser cards went down. He clumped related cards together, and sometimes a batch of cards made a theme for the iteration. He also found that he could sequence cards so that an iteration's set of stories all supported a particular business process.
Early in the project, Nickieben often found himself frustrated that "finished" stories weren't what he thought he was going to get. It was hard to think of everything he needed to tell the programmers; so much of what he did automatically had to be remembered and put into words. And he'd explain things, and the programmers would think they understood, and he'd think they understood, but it would turn out they hadn't.
He sketched tests up front. Instead of just explaining in words, he found himself writing more and more concrete examples on the whiteboard. Discussing those seemed to prompt him to remember steps or issued he'd otherwise forget.

During the iteration, he also spent more time checking in with the programmers, instead of waiting for them to come to him with questions. He especially spent more time with the "GUI guy", talking about what he wanted the GUI to do, and how it did it, and sketching out examples of usage as tests.
As he moved toward more examples, Nickieben started making the examples too complicated. He produced one example that illustrated all the inherent complexities of its story's bit of the business.
He learned to start with the simplest possible example. Then he added one scenario or business rule at a time. In a way, he used the examples to progressively teach the programmers, and they used them to progressively teach the code.
He was sometimes surprised by the technical implications of his ideas. Once, a simple "let's put a Cancel button on the progress bar" led to all sorts of scary talk about transactions and undoing. He was uncomfortable not knowing whether something would be simple or hard.
For a time, he got the help of an analyst who bridged the business and technical worlds. That person helped him understand how big a decision was. But more: her technical knowledge and experience with similar applications allowed her to suggest considerations he would never have thought of.

He also enlisted the programmers for lightweight training. He had short conversations about what they had to do to implement a story. (Some of the programmers were much better at this explaining than others.) Over time, those short conversations added up to a decent enough high-level understanding of the system.

The programmers also got better at coping with change. As they worked more with the system, it got more pliable, so the "internal bigness" of the change more often - but not always! - corresponded to its "external bigness." Programmers also learned more about the business domain, so they could say, "Are you going to need X, Y, or Z? Cause if you do, it would probably be better to schedule those things early."

Eventually, the team didn't need the analyst any more. All of them were analysts, a little.
There was a time when Nickieben felt cleanup was taking over control of the project. Parts of the system were old legacy code. When he started giving stories for that, it seemed like every story led to some technical task that was more than an iteration long. Everything seemed to lead to a huge refactoring.
Nickieben learned how to write stories in small slices, about one day's work or so each. And the programmers learned how to do the big refactoring one slice at a time, such that each story led to somewhat better code and enough stories would lead to really good code.
They also made information radiators to track "technical debt". Sometimes the programmers couldn't see a way to make an improvement in the time they had - even with their greater experience, it seemed like the refactoring had to be a big chunk. Whenever a programmer left the code worse than she thought she should, she wrote it up on a card and put it on the Refactoring Board. At some point, Nickieben would start getting nervous that the messiness would start slowing the team down, so he would sanction some specific cleanup time. Nevertheless, they tried to tie each refactoring to something useful, like a small feature of a bug fix.

The programmers' editor also let them visually track the number of "todo" items they'd left in the code, which was another stimulus to clean up.
In the end, Nickieben's project was a big success. The date did slip a bit, and the Lords and Masters didn't get everything they'd wanted from the release. But they'd changed business direction right in the middle, and the team had coped well and still produced a solid, salable product. Looking back, Nickieben is amazed at the difference between him then and him now. He'd started out floundering, practically on the edge of a nervous breakdown. While he still wouldn't call his job easy, he knows he can do it. The only problem is that he knows there are people just like he was nine months ago. And just like he had no support group, they still don't. So they get to learn it all again, the painful way.
Maybe this page will help.
One last thing: Nickieben has to serve multiple masters: there are different interest groups who care about what the product does. There are two different classes of users, one very demanding buyer, operations, customer support, and so on. He has a lawyer friend who says it's common knowledge among lawyers that someone trying to represent multiple interest groups usually gets trapped by one or two and under-represents the others. Nickieben worries that he's doing that. He isn't really sure what to do about it. He thinks that linking each interest group to a persona (as used in some styles of user-centered design) might help. He imagines putting big pictures of the personas up in the bullpen would keep them in his (and everyone's mind).

But he wishes he had better ideas.

Jennitta Andrea,  Richard P. Gabriel,  Brian Marick, and Geoff Sobering

Update: Nickieben Bourbaki is a composite of various customers we've known, a pseudonym that marks this as a collective effort, and the regular pseudonym of one of us (but I'm not telling who).

## Posted at 17:38 in category /agile [permalink] [top]

About Brian Marick
I consult mainly on Agile software development, with a special focus on how testing fits in.

Contact me here: marick@exampler.com.




Agile Testing Directions
Tests and examples
Technology-facing programmer support
Business-facing team support
Business-facing product critiques
Technology-facing product critiques
Testers on agile projects

Permalink to this list


Working your way out of the automated GUI testing tarpit
  1. Three ways of writing the same test
  2. A test should deduce its setup path
  3. Convert the suite one failure at a time
  4. You should be able to get to any page in one step
  5. Extract fast tests about single pages
  6. Link checking without clicking on links
  7. Workflow tests remain GUI tests
Permalink to this list


Design-Driven Test-Driven Design
Creating a test
Making it (barely) run
Views and presenters appear
Hooking up the real GUI


Popular Articles
A roadmap for testing on an agile project: When consulting on testing in Agile projects, I like to call this plan "what I'm biased toward."

Tacit knowledge: Experts often have no theory of their work. They simply perform skillfully.

Process and personality: Every article on methodology implicitly begins "Let's talk about me."


Related Weblogs

Wayne Allen
James Bach
Laurent Bossavit
William Caputo
Mike Clark
Rachel Davies
Esther Derby
Michael Feathers
Developer Testing
Chad Fowler
Martin Fowler
Alan Francis
Elisabeth Hendrickson
Grig Gheorghiu
Andy Hunt
Ben Hyde
Ron Jeffries
Jonathan Kohl
Dave Liebreich
Jeff Patton
Bret Pettichord
Hiring Johanna Rothman
Managing Johanna Rothman
Kevin Rutherford
Christian Sepulveda
James Shore
Jeff Sutherland
Pragmatic Dave Thomas
Glenn Vanderburg
Greg Vaughn
Eugene Wallingford
Jim Weirich


Where to Find Me

Software Practice Advancement


All of 2006
All of 2005
All of 2004
All of 2003



Agile Alliance Logo