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:- Forming — assembling, organising and defining roles (including leadership).
- Storming — a psychological battling for whose processes, ideas and ideals will be the basis for the Team’s set of values.
- Norming — when those values become standardised and reinforced.
- 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- Illusions of invulnerability creating excessive optimism and encouraging risk taking.
- Unquestioned belief in the group.
- Rationalising warnings that might challenge the group’s assumptions.
- Stereotyping those who are opposed to the group as weak, biased, arrogant, spiteful, or stupid.
- Self-censorship of ideas that deviate from the apparent group consensus.
- Illusions of unanimity among group members, silence is viewed as agreement.
- Direct pressure to conform placed on any member who questions the group, couched in terms of “disloyalty”
- Mind guards — self-appointed members who shield the group from dissenting information.
Preventing Groupthink
Again, Janis’s research points to a number of ways to prevent groupthink that can be easily applied to Scrum Teams [3].- 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.
- The team should be encouraged (positive reinforcement) to examine alternatives to their solutions.
- Team members should be encouraged to discuss the Team’s ideas with trusted people outside of the group.
- The Team should invite outside experts into meetings. Team members should be encouraged to discuss with and question the outside experts.
- 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.
“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.
