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:
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.
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.
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.
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.
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!
Honestly? I'm -1 on nearly all "team building" exercises because they're contrived cr@p. Mend those gaps with daily coordination that lead to real work getting done. Tout your successes and highlight your progress -- even small wins. Don't overdo that praise because obsequious flattery fails, always.
Your problem is that QA and Dev are separated teams. If you want strong cohesion, close collaboration, team spirit, etc, put QA guys and Dev guys into a same team, include QA in the development process.
Your problem is an organizational problem (that you've likely inherited from an outdated organizational model) and that you won't solve with an exercise. The solution is to change the organization.
Do the developers use any TDD practices? If there is a big difference in the quality of tests from each, then bringing in some TDD may help some.
We've done a mini-Olympics at a bar near work as a team building exercise that has mediocre success. Trying to bring in more socialization than what there is naturally can be a recipe for disaster, which seems to be a commmon theme.
Having QA and Dev take lunch together can help in some areas as long as it isn't forced. Having to do things out of obligation rather than desire can set things up for failure.
发布评论
评论（4）
根据我的经验，提高团队之间互操作性的关键是打破“我们和他们”的心态。令人惊讶的是，即使在一个每个人都相处融洽的组织中，也会自然而然地倾向于对其他团队抱有刻板印象，认为他们只是“困难”，然后退回到团队自己的围墙花园中。
要将其应用到团队建设练习中，主要是将参与者分成小组（4-6人），最重要的是，确保小组混合良好。确保将人们与通常合作得最好的人分开。其目的是增加通常不常交流的人们之间的互动，并为他们提供一个可以积累共同工作经验的环境。
Jim Holmes 的观点是务实的工程师中的普遍观点，我过去也有过同样的观点。大多数这些事情注定会失败，因为管理不善，没有解决核心问题，或者因为参与者完全怀疑并希望练习失败（因为他们过去是如此无用）。
直到我参加了一个真正有用的为期一周（！）的团队建设项目，我才了解了此类练习的潜力。该课程脱颖而出的最重要因素是：
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，因为它们都是人为的cr@p。通过日常协调来弥补这些差距，从而完成真正的工作。宣扬你的成功并强调你的进步——即使是微小的胜利。不要过度赞美，因为谄媚的奉承总是失败的。
Honestly? I'm -1 on nearly all "team building" exercises because they're contrived cr@p. Mend those gaps with daily coordination that lead to real work getting done. Tout your successes and highlight your progress -- even small wins. Don't overdo that praise because obsequious flattery fails, always.
您的问题是 QA 和开发是独立的团队。如果您想要强大的凝聚力、密切的协作、团队精神等，请将 QA 人员和开发人员放入同一个团队，并将 QA 纳入开发过程。
您的问题是一个组织问题（您可能从过时的组织模型继承了该问题）并且无法通过练习来解决。解决方案是改变组织。
Your problem is that QA and Dev are separated teams. If you want strong cohesion, close collaboration, team spirit, etc, put QA guys and Dev guys into a same team, include QA in the development process.
Your problem is an organizational problem (that you've likely inherited from an outdated organizational model) and that you won't solve with an exercise. The solution is to change the organization.
开发人员是否使用任何 TDD 实践？如果每个测试的质量存在很大差异，那么引入一些 TDD 可能会有所帮助。
我们在工作地点附近的一家酒吧举办了一场迷你奥运会，作为团队建设活动，但效果平平。试图引入比自然更多的社交可能会导致灾难，这似乎是一个常见的主题。
只要不是被迫的，让 QA 和开发人员一起吃午餐在某些方面会有所帮助。出于义务而不是出于欲望而做事可能会导致失败。
Do the developers use any TDD practices? If there is a big difference in the quality of tests from each, then bringing in some TDD may help some.
We've done a mini-Olympics at a bar near work as a team building exercise that has mediocre success. Trying to bring in more socialization than what there is naturally can be a recipe for disaster, which seems to be a commmon theme.
Having QA and Dev take lunch together can help in some areas as long as it isn't forced. Having to do things out of obligation rather than desire can set things up for failure.