Groupthink: the bane of high performing Agile Teams

What makes an agile team great and why?
After coaching a number of teams in Scrum, we’ve now seen a number that, after a some months now, could be considered high performers. They break-down products relatively easily and they understand not only what rules of Scrum apply when, but most importantly they know why adhering to the rules of Scrum keeps the Team agile. Because we teach Scrum using a psycho-behavioural approach to learning, we know that we’ve achieved our goal in coaching when we observe behaviour in the Team that reflects they’ve reached a level of unconscious competence and that those behaviours are sustainable. But what happens next? What turns a great team into a high performing one? How can they get there and how will we know when they’ve achieved the state of high performance?

To be great, a team has to get from Forming to Performing

Groups go through a number of stages when they first get together [1], and a new Scrum Team is no different:

1. Forming — assembling, organising and defining roles (including leadership).
2. Storming — a psychological battling for whose processes, ideas and ideals will be the basis for the Team’s set of values.
3. Norming — when those values become standardised and reinforced.
4. Performing — when the Team seeks or even expects dissent from team members in order to have continuous improvement.

Storming — Where the fight for ego and group values can go wrong

The Storming stage is one of the most interesting for a new Scrum Team. This is where the values that of the team — those that help the team become self-managing — are decided. This occurs not overtly but covertly and by consensus. The values and behaviours the Team will hold as important will depend on specific individuals influencing others by leveraging their expert and referent power during the Storming stage.
Scrum Coaches, Scrum Masters, Project Managers and Line Managers, having legitimate, reward and coercive power, will find that the behaviours they reward during the Storming stage will become part of the Team’s values. Even the ‘rewarding’ of velocity points to the Team when they meet the Definition of Done is a form of positive reinforcement — as such, it will result in an increase in the behaviours that led to the product being “Done”. The reward will also place value on the skills and practices the Team employed. Strangely, though, this form of reward can have a negative effect on the Team’s behaviour. It suggests (unconsciously) that some skills in the Team are more valuable than others.

Norming — Where established values become the Team’s dogma

I’ve worked on many agile projects as a user-experience (UX) practitioner. In the past, my job was to work one Sprint ahead of the development teams (this is not a practice I use anymore). This pattern, first articulated by Deseree Sy [2], describes a common approach to adapting UX design to work around a team of developers using agile methods. With great humour, the UX Drinking Game on Twitter attempts to capture some of these moments:

… and my favourite …

While these memes are attempts to make light of situations that many people find themselves in when dealing with UX and Agile, it highlights an important and disruptive issue at the heart of some projects: groupthink.
Groupthink is an instinctive conformity amongst teams to reinforce what the group values as defined (often covertly and unconsciously rather than overtly) in the Storming phase. These values and associated behaviours are continually reinforced by the team throughout the Norming phase. So what are these values? Well, it depends on the team.
If we examine a typical Scrum team, it’s not unusual that it is comprised solely of developers. As Ambler and Lines write, “what you typically read about in the agile literature is how a team of developers … build a high-quality working system on an incremental basis [6]”. Such a team’s group values, particularly where skills that contribute toward its success are concerned, are more likely to be described in terms of “how fast 50,000 lines of code can be completed” [7] rather than how effortlessly users can utilise the system. This results in opposing points of view of value that @uxdrink so cleverly pokes fun at — the “in-group” (developers) versus the “out-group” (designers) with values reinforced by groupthink behaviour.

Antecedents of Groupthink

Janis’s [3] work on antecedent conditions for groupthink notes that, where a group has a high level of cohesiveness, structural faults such as insulation of the group and external threats, increase the likelihood of groupthink emerging. Baron [4] adds that social identification also forms part of the antecedents for groupthink. Turner and Pratkanis [5] summarise groupthink as:

“A collective effort directed at warding off potentially negative views of the group”

As these behaviours become entrenched in the Norming stage, they inherently limit the team achieving the Performing stage. This is because, at its heart, Performing is focussed on enabling the group to rise above the issue at hand, produce a smarter solution, learn from it, and improve by challenging its skills and what, therefore, it values.

Symptoms of Groupthink in the Scrum Team

Janis posits three types of symptoms indicative of groupthink [3]:
Type I: Overestimations of the group — its power and morality

1. Illusions of invulnerability creating excessive optimism and encouraging risk taking.
2. Unquestioned belief in the group.

Type II: Closed-mindedness

1. Rationalising warnings that might challenge the group’s assumptions.
2. Stereotyping those who are opposed to the group as weak, biased, arrogant, spiteful, or stupid.

Type III: Pressures toward uniformity

1. Self-censorship of ideas that deviate from the apparent group consensus.
2. Illusions of unanimity among group members, silence is viewed as agreement.
3. Direct pressure to conform placed on any member who questions the group, couched in terms of “disloyalty”
4. Mind guards — self-appointed members who shield the group from dissenting information.

Ultimately, these symptoms highlight issues with the Team’s values that prevent it from achieving the Performing stage. Overall, these symptoms will prevent the Team from accepting alternative perspectives and solutions that are generated from outside the Team, especially where those solutions challenge the things the Team values, even when they contribute to smarter ways of working or improvements to the Team’s products.

Preventing Groupthink

Again, Janis’s research points to a number of ways to prevent groupthink that can be easily applied to Scrum Teams [3].

1. The project’s leaders should assign each member the task of “critical evaluator”. This gives permission from outside the team for each member to freely air objections and doubts.
2. The team should be encouraged (positive reinforcement) to examine alternatives to their solutions.
3. Team members should be encouraged to discuss the Team’s ideas with trusted people outside of the group.
4. The Team should invite outside experts into meetings. Team members should be encouraged to discuss with and question the outside experts.
5. At least one member of the Team should be assigned the role of Devil’s advocate, but this should be a different person for each meeting.

The New New Product Development Game also hints at remedies for groupthink, describing mechanisms from case studies [8] that push a team towards Performing (or transcendence as they describe it). On reporting on Fuji-Xerox’s experience, they highlight that selecting a diverse team is crucial. It’s once they start interacting that cross-fertilisation occurs, which, in turn, drives more innovative solutions that would not have otherwise been possible with a homogeneous skill-pool.

“When all the team members are located in one large room, someone’s information becomes yours, without even trying. You then start thinking in terms of what’s best or second best for the group at large and not only about where you stand. If everyone understands the other person’s position, then each of us is more willing to give in, or at least to try to talk to each other. Initiatives emerge as a result.” —Fuji-Xerox [8]

It’s the cross-fertilisation that is the key output from a multidisciplinary team. It not only represents different ideas and perspectives for solutions, but also serves to reinforce acceptance of the heterogeneous values and skills that generated them.

Conclusions

The blogosphere is replete with articles on high performing Scrum teams. These articles describe teams that break-down complexity with ease, have high velocity, and do continuous integration. Importantly, when they choose an agile method like Scrum they stick to its rules rather than diluting its strengths through a pick and choose approach. But the psychology of group dynamics tells us that there’s more to a high performing team than just these behaviours. It also goes beyond what they do to tell us why they are successful so we can watch out for the factors that keep us from success. A high performing team must work beyond its own limitations and values to a point where threat to its values provides an opportunity to grow over reinforcing the status quo. If your team is choosing to protect itself over seeking to be challenged and grow, it might be time to remove that groupthink.
M
– – – –
1. Tuckman, B. (1965). Developmental sequence in small groups. Psychological Bulletin 63 (6): 384:99.
2. Sy, D. (2007). Adapting Usability Investigations for Agile User-Centred Design. Journal of Usability Studies, Volume 2, Issue 3, pp. 112-132
3. Janis, I. L. (1972). Victims of Groupthink: a Psychological Study of Foreign-Policy Decisions and Fiascoes. Boston: Houghton Mifflin. ISBN 0-395-14002-1.
4.  Baron, R. (2005)  So right it’s wrong: Groupthink and the ubiquitous nature of polarised group decision making. Advances in Experimental Social Psychology 37, 35.
5.  Turner, M., & Pratkanis, A. (1991) A Social Identity Maintenance Model of Groupthink. Organisational Behaviour and Human Decision Processes, 73(2/3), 210.
6. Ambler, S. W. & Lines, M. (2012) Disciplined Agile Delivery (DAD): A Practitioner’s Guide to Agile Software Delivery in the Enterprise. IBM Press, ISBN: 0132810131.
7. Linders, B. (2012) Evidence of Success of Agile Projects. Online at: www.infoq.com/news/2012/11/success-agile-projects
8. Takeuchi, H. & Nonaka, I (1986). The New New Product Development Game. Harvard Business Review.