Speak in tongues - or get a translator

Developers tend to share a quite exact vocabulary and a desire for logical argument, something they rarely have in common with customers. On an XP team, where both have to work together, this can lead to misunderstandings. The way to overcome this is to use a translator: someone the business trusts to explain what the development team "needs to do" in the business terms they are more used to. Often these business terms are purely cost / benefit, such as "invest in testing now to avoid paying for defects later". The corollary of this is that in an introducing-XP-by-stealth situation you need to be prepared to explain what you intend to do (or have done!) in business terms, not in technical ones.

A rose by any other name?

I recently discovered that Professional chewing gum exists. I don't claim to understand the product marketing - but it made me think about the branding of XP in the agile community. In the beginning there was 'vanilla' XP, then Industrial XP came along, and now we have Enterprise XP. What next?! It's obvious that there is lots of interest in XP but just as obvious that for some people XP really is, erm, too extreme for their organisational culture.

A perspective on coaching and teambuilding

Regardless of the fact that I disagree with Jim Highsmith about whether project managers can coach I do like his perspective on coaching and team building:
The four main building blocks are...
1. Focusing the team on delivering results
2. Molding a group of individuals into a team
3. Developing individuals' contributions
4. Providing the team with required resources

Well ok, perhaps not the last item. A coach should raise a flag when they think that a team is missing some resources, but they may not be the best placed person to secure those resources.

Project managers as coaches?

In a recent Cutter newsletter, Jim Highsmith floats the idea of using project managers as coaches: Although I think there are several tasks for the project manager during the execution of an iteration cycle, one of the most important ones is coaching and team building. Teams have two broad categories of skills -- technical and behavioral; that is, the abilities to accomplish the technical work and the abilities to work well together as a team. Often the team's technical abilities outstrip its teamwork abilities. The project manager can contribute to members' learning the latter.

It is an admirable objective but I think that few project managers actually have the teamwork (or communication) skills required to achieve it. In an early blog post I set out how I see the difference in roles between a project manager, technical lead and coach, and I still think that the split makes sense. (Except in a small team of course where several roles need to be undertaken by a single person). Mostly this is about keeping the coach's focus on longer-term team and process improvement independent of the manager's focus on shorter-term software delivery, but there is also an overlap with the principles of the power of three pattern.

The power of three

Sometimes two people together are unable to reach concensus on a decision they have to make. This can be because one side - or both - misinterprets the extent to which the other is able to compromise. (That's able to compromise as opposed to prepared to compromise!). Rather than leaving them to struggle a coach can intervene to restore balance to the situation. By introducing a neutral third person some of the personal tension in the situation is defused, and if that person acts as a facilitator and asks effective questions then it can be a tremendously productive tactic.