Different disciplines have different cultures. There can beculture clash. How do you deal with that in an Agile project?

A group of us addressed this question at a Scrum Masterget-together. (We were ChristianSepulveda, Jon Spence, Michele Sliger, Charlie Poole, and me.)

We focused on three more specific problems:

• You need to get past cultural conflicts. (But you don't necessarily need to solve them.)

• People are afraid they'll have to relinquish their disciplinary identities.

• You can lead people to a cross-functional team, but you can't make them collaborate.

We recommend the following at the beginning of the project:

1. Try to get the right people on the team. If it later becomes apparent that you didn't, separate the poison. Offer them additional training away from the team, put them on a special project (again, away from the team), help them find another project where they'd be more comfortable, and - as a last resort - suggest that they look for another position.

2. Have an open forum at the start of the project. Get the issues out in the open.

3. Use the "Word in a hat" game. Each team member writes down a word or phrase that best describes their main concern about the project, folds the paper, and places it in a hat. The phrases should be something like "rigid customers", "bonuses", or "schedule". The Scrum Master pulls the word out of the hat, reads it aloud, and starts a discussion that preserves anonymity.

4. The open forum should result in an internal risk management plan to monitor cross-functional issues the team identified - and then deal with them. This can be simple, like a weekly pizza lunch to review open issues or new ones.

5. The team should have a clear and common goal that all members can clearly articulate. For example: they should be able to recite the purpose of the project to their CEO should they find themselves in the elevator with her. Another idea is Jim Highsmith's "design the box" exercise. In it, the team designs the packaging of the software and puts it in a common area as a constant visual reminder of the project's ultimate goal.

Throughout the project:

1. Monitor issues. Address them in retrospectives.

2. Use "odd pairings". When a task needs doing, have programmers pair with testers, have testers pair with technical writers, have technical writers pair with programmers. This will spread knowledge through the team and cause people to sympathize with people in different roles.

3. Ask "Why?" As team members take on tasks, they should think about how what they're doing helps to achieve the project's goals. By asking "why am I doing this?" the team is less likely to revert to non-agile form or start on wasteful activities.

Clearly, we've only scratched the surface. In particular, I notice that we haven't got anything specific to the problem of people afraid of having to relinquish their disciplinary identities. That's a problem near to my heart, because it's one that comes up a lot with testers.