Question

Does anyone have a good team building exercise to help bring together disparate teams like the QA/Development teams?

I am the companies “agile coach” (as much as I hate that term), I am the one that is tasked with making our company more agile and bring on more agile tasks/techniques.

That being said, I am trying to mend gaps between the two teams and am trying to come up with good team building exercises as the QA/Dev teams should be treated as one team and needs to communicate more.

Any ideas would be greatly appreciated of things that have worked for you

Answer 1

In my experience, the key to improving interoperability between teams is to break down the ‘us and them’ mentality. It’s amazing how even in an organisation where everyone gets on, there’s this natural tendency to stereotype other teams, assume they’re just ‘difficult’, and retreat into the team’s own walled garden.

To apply this to teambuilding exercises, the main thing is to split the participants into small groups (4-6 people), and crucially, ensure the groups are well-mixed. Make sure people are split up from those they normally work best with. The aim is to increase the interaction between people who don’t normally communicate as much, and give them an environment where they can build experience working together.

Jim Holmes’ opinion is a common one among pragmatic engineers, and I have had the same point of view in the past. Most of these things are doomed to fail because of poor management not addressing the core issues, or because the participants are completely sceptical and want the exercise to fail (because they’ve been so useless in the past).

It wasn’t until I attended a genuinely useful week-long(!) team-building project that I understood the potential for these types of exercises. The top things that made that course stand out were:

1. Get buy-in from the participants. If you want people to take your exercise seriously and make a real effort, then you have to address the scepticism up front. Tell them what you expect to achieve, why you want it (how it will improve their lives) and ask for their buy-in up-front. And take responsibility – tell them you genuinely believe this is useful, and be prepared to receive hostility and negative feedback if it falls short.
2. Make the difficulty level sufficient. If your audience are all PhDs or experienced software architects, then don’t treat them like children. Make the exercises interesting, complex, and difficult. For example, we were thrown straight in the deep end, teamed with people we’d never met, given a crisis scenario to manage, handed a huge stack of background info, and told we had 10 minutes to prepare. It was a nightmare (and we didn’t do very well)! If you make the problems simpler, then reduce the available time, drastically. The exercises should be hard, and the group should fail some of them, early on, to bring home to them, hard, their dismal lack of teamworking ability.
3. Identify clearly what you’re trying to achieve. Sticking people in a room and telling them to ‘work in a team’ won’t work. Have clear aims and explain how people are going to be better off at the end of this. Make sure those goals are tracked. If the participants don’t feel they got much out at the end of the course, then find out why – and take that feedback seriously.
4. Help participants introspect how they work and interact with each other. A big part of team issues is not understanding how other people work. For smart people, this is often perceived as irrelevant – “I don’t care how they work, I can just do what needs to be done myself” is a common point of view. This is why the problem has to be too difficult/too much work/take too long for any single person to complete. Respecting other’s strengths and mediating their weaknesses is a critical feature of successful team-members.
5. Have detailed feedback. After each exercise, make sure the team reflects on their performance. You should offer constructive criticism, but much better is to get the team to understand and identify their own limitations. Once they have an idea of how they can improve, jump straight into the next exercise. For example, in one team, we had the problem that everyone talked but no one really listened. Having failed several challenges due to this dysfunctional communication, we instituted a simple communication protocol – only one person was allowed to talk at a time. Although obvious, it was amazing to see how much this improved our performance on subsequent exercises!