Beginning the move to one team - step four
Some might argue that the concept of metaphor should come earlier, but we recommend introducing this towards the end of this stage, since this is the first time we draw in the customer/business. Metaphor is a common language about the system between customers and developers. This may not seem important, but take the example of an Exoftware government client: the development team routinely referred to the business (that is the people who were defining the system requirements) as customers. However to the business, "customer" referred to the end consumer. This caused confusion as well as frustration amongst both the developers and "business".

Metaphor is more than a common language -- it's also about context and understanding at a high level what the system is about. Here we're able to take steps towards really communicating with our business partners and sharing a common goal. 3Q uses something called the Adaptor Tree Hierarchy which gives a broad system overview in a language that is agreed with the customer/business. For example:

ThreeQData

• todaysDate
• marriage
  • spouse
  • economicindicators
  • client
    • lossofincomestory
      • annualincome
      • coveramortisationeroision
      • ...
    • managedfundstory
    • pensionstory

Each part of the tree expands out into more detail, can be changed easily, and provides a good view of the system as well as a common language for the whole team.

Critical success factors

• Stick with it -- metaphor only works if you are going to stick with it. It will become part of everyday language, but it takes time
• Get the basics down first â€" work on getting the basic framework of the metaphor down, learn it and use it then build from there.
• Get help -- get as many relevant business/customer people involved in building the metaphor -- it's vital to get people involved early and up front.

The team practices of Agile aim to help the team focus on working together, and to understand the shared practices and goals. While some of the practices such as coding standards can be done in isolation, these team practices work best if built upon solid developer practices such as test-code refactor and pair programming.

The next part in this series will look at how the developer team will now begin to form "one team" with customers/business.

Brian Swan is an Agile mentor with Exoftware. He has extensive experience in technical and management aspects of Agile, and has successfully led a variety of teams transitioning to Agile, as well as trained developers and managers in Agile thinking and practice. His work with Exoftware and Agile has taken him to a variety of companies, where he has consistently and positively impacted development teams. Brian's previous experience includes lecturing at Napier University in software development and human and computer interaction. Brian can be contacted by email.