There is a great thread on the XP list right now discussing Metaphors in the context of XP. Metaphors are basically a common language of how a system works, ideally based on domain terms. However, I found the following post by Kent Beck to be particularly enlightning:
Teams work more effectively when members have personal perspectives on a shared understanding of the system and the problems it addresses. When I want to gauge a team’s shared understanding, I ask members individually to explain their system to me using four objects. If everyone comes up with similar objects, they share a metaphor. Wildly divergent objects suggest the team could benefit from working on shared understanding.
It really is amazing how much having a clear language between customers and developers (and even managers) impacts a project. One of the first things I do is have our customers explain how they define specific terms. Or, have them explain to me what they think our terms mean. For example, we ran into a recent situation where we told the customer we would deploy a sample report with test data so they could practice integrating it with their systems. They then proceeded to call us back and tell us that things were horribly bad because the data didn’t change when they tried other requests.
We found out that the problem was in the lack of definition of the term “deploy” and “sample report”. But because we thought we were clear enough, and felt like they understood it well enough (without actually asking them), it led to miscommunication.
On the flip side, we worked on a project several years ago where we defined very clearly the domain terms between the customer and the developers. The project couldn’t have gone any smoother – their expectations from us where clear, and we delivered the expected features on time.