Team building, unfortunately, does not do anything constructive or long-lasting toward high-performance. In fact, it can often cause further harm to the larger system as it sub-optimises locally what needs to be transitioned systemically.
Traditional Kumbaya Team Fluffies
Scrum Masters and Agile Coaches are often criticised for their disregard for the hardlined expectations of the business when focusing on the requisite harmony they believe a team should always have. This might stem from the belief that Scrum Masters should protect and serve the team – and naturally, with the appropriate level of passion and commitment, the Scrum Master will seek things that bring an easy working environment, harmonious relations and democracy that honour individuality.
Scrum Masters tend to then refer to tools that help each individual understand their strengths, their personality, or their preferred way of being, and spend some time with the team to create awareness on the diversity present between them. This is followed by instructions from each individual on how to communicate and how not to communicate with them, and we all then assume that the team will work nicely together. The further assumption is that because this is done, and because they work nicely together, they will perform better.
The actual facts of the matter is that less than 10% of the items identified across thousands of teams that did “team-day” like this, actually get acted on in the next year. And, there is NO correlation between this awareness of individual preference in the team and actual team productivity, in fact, the research suggests that the niceties get in the way of Agility and Resilience in the team. Simply, because they never learn to debate[1], disagree, get to ideas that no one had when walking into the room, and then commit to something new. And, thanks to this nicety limitation, they avoid outside conflict, and generally don’t serve their stakeholder needs very well.
They are also not oriented to be sensitised to their stakeholder needs, or the needs of the system they belong to because their team was launched with an inwards focus and often assumptions are that in Scrum, the Product Owner deals with stakeholders, and the Scrum Master keeps everyone else away so the team can focus[2]. The team actually learn patterns of behaviour that work AGAINST the system and their stakeholders to avoid the areas that challenge their inability to be Resilient, to debate etc.
EPIC FAIL on the behalf of well-to-do Agilists.
Enter Systemic Coaching!
[1] Lencioni, P. (2002). The five dysfunctions of a team: a leadership fable. Jossey-Bass
[2] Broza, G. (2012). The human side of agile: How to help your team deliver. 3PVantage
