Thinking Tools

Extreme Programming is pretty silent on how features (which we call UserStories) are gathered. It only speaks to how those features are scheduled and planned.

This is often considered a hole in the process.

When sitting with a client, figuring out what XP will mean to them and how it maps to their current process, this question often arises.

It could be a prototype, it could be user flowcharts, it could even be an existing system. Whatever it is, it’s essentially outside the scope of ‘XP’ and so people assume that means they won’t be allowed to use them any more.

I beg to differ. The fact that XP doesn’t address these things is because they’re going to be different for each and every organisation, even projects within that organisation. This is good news for you, because it means you can just keep doing what you’re doing if it works for you.

What might change, however, is how much reverence you attach to the artefacts produced by these tools.

Each of the things above, and no doubt may more besides, are “thinking tools” for an XP Customer, just as CRC cards, or BAML and a whiteboard are to the development team, or MS Project is to a Project Manager.

The tools themselves help you organise your thoughts. They help you think about the problem at hand. Who could argue with using a tool that helps you?

There is a problem, however. An MS Project plan or a prototype, unlike a scribble on a whiteboard, carries with it an air of permanence. All the artefacts produced from your thinking tools reflect the your view of the world and your understanding of the problem at the specific point of use.

However, the map is not the territory. The territory can change, and suddenly the map is out of date.

The boxes and arrows are not the design, that’s in the code.

Plans are worthless, Planning is essential.

And the prototype/flowcharts are not the requested feature set… that’s in the code we’ve got now and the User Stories we have written but not yet implemented.

The map only reflects the territory at the time the map was drawn. The design diagram details what the code looked like, or you plans for what it will eventually look like at the time when it was created.

Every iteration, the structure of the code will change and invalidate the diagrams. The customers understanding of what they want and what’s possible will change and invalidate the prototype or the flowcharts.

This is a Good Thing, as it make it much more likely that well end up where we want to, rather than where we thought we’d want to.

So go ahead, make your prototype. Plan your Customer Journeys and Interaction Designs. But don’t spend too much time on them, they’re just a transient tool to help you figure out what the stories are. And don’t be afraid to throw them away, they’re probably worthless after a couple of iterations anyway. You’ll have figured out new cool stuff to build, and new ways to do things.