Unless you’re writing software by and for yourself, you will have to deal with at least one other person somewhere during the process. A grudging détente is not enough; you need to work together effectively. This means forming solid working relationships that are built on honesty, trust, cooperation, openness, and mutual respect.
You can’t force people to do this. The best your agile method can do is support these sorts of relationships. For example, one way to engender healthy interaction is to have people sit together and collaborate in pursuit of common goals.
It’s far easier, unfortunately, to craft your method in a way that discourages healthy relationships. An extreme example (sadly, one that actually happens) is forcing all developer communication with stakeholders to go through business analysts. As another example, a sure way to damage programmer/tester relationships is to require them to communicate solely through the bug-tracking system.
Blame-oriented cultures also sabotage relationships. Get rid of blame by introducing collaboration and avoiding practices that indicate a lack of trust. Rather than forcing stakeholders to sign a requirements document, work together to identify and clarify requirements and review progress iteratively. Rather than telling developers that they can’t produce any bugs and testers that they must find all the bugs, ask developers and testers to work together to ensure that customers don’t find any bugs.
It’s easy—especially for technical people—to get caught up in the details of a particular solution. Encourage cooperation and experimentation while respecting the distinction between ideas and people. Credit isn’t important. Being right isn’t important. Treating your team members with respect and cooperating to produce great software is important.
Although no process can enforce effective relationships, XP does a good job of enabling them. The most obvious example is the use of a cross-functional team in a common workspace. With the weekly iteration demo, teams reach out to stakeholders as well. XP also emphasizes the importance of including real customers in the process.
Everyday practices such as stand-up meetings, collective code ownership, ubiquitous language, the planning game, and pair programming help reinforce the idea that team members work together to achieve common goals.
XP recommends colocated teams for a reason: it’s much easier to communicate and form solid working relationships when you’re all in the same room. Yet some teams can’t or won’t sit together. How do you deal with this challenge?
One of my hobbies is working on a long-term free software project, which consists of a core team of developers located around the globe. We communicate virtually, and this has led to some challenges.
For example, one developer—I’ll call him “Bob”—has an abrupt communication style. This occasionally leads to friction with people who don’t know Bob well and think he’s being rude. In fact, he’s just not a native English speaker and is laconic by nature. This sort of problem seems to occur in all distributed teams; it’s easy to assume the worst about someone’s motivation when you can’t talk face-to-face.
To prevent the problems from escalating, our team decided to meet in person as often as possible—typically three or four times a year. Bob attended a recent gathering, and afterward, team members commented that they understood his communication style much better. They realized it wasn’t personal, but rather an artifact of his culture.
Our team also instituted weekly meetings. They’re virtual meetings, but they help us understand what everyone is working on. The meetings contribute to our cohesiveness and shared direction, and they help curtail unhelpful tangents.
A distributed team—particularly one that’s staffed with part-time volunteers, as ours is—always faces communication challenges, so it’s important to address them and make changes that enable you to work and communicate better.