Metaphor

One of the great ideas to come out out of XP is that of the metaphor (along with Test-Driven Development of course). I'm shocked that is a constant source of controversy in the XP community and largely ignored because of that. I think the problem might be forcing a metaphor when one is not needed.

My viewpoint is that if a metaphor helps communication with developers and business users then by all means DO IT. But, don't force a round peg in a square hole. I generally strive to understand the business of the application being developed and how to satisfy the goals of my users. Use cases and early domain model sketches are great for this. Generally, if there is some difficult area and a metaphor comes to mind that simplifies the problem for both developers and the users, then I use it. I never try to think up of a metaphor if the problem domain is well understood or waste time trying to force one.

The point of a metaphor is to make what's happening in the business crystal clear to developers. Use a metaphor for the murky waters (only if you can come up with one that makes things simple, otherwise you're making things worse and difficult). Remember the point of being agile is delivering value to your customer. Above all else, you are there to make the life of your user easier and help them achieve their goals quickly and profitably. Be pragmatic! If something is not working for you, try another technique else! Everyone has their own ways of learning the business and goals of the user. My favorite is a sketch of the domain on the left (using the language of the user, it's a high level view and only the objects that match the user's mental model) and a mock-up of the screen on the right. The use cases are written in front and we go through each scenario the customer needs. Be creative. I think metaphor is one of those tricks and it's always good to have a big bag and not just one.