This is the second post in a series of blogs on groups and Scrum. In the first post we defined what a group is, why people join groups and what it takes to make them a team. Establishing the stage of being a team, or nowadays in most organizations, being a Scrum team comes with some challenges. How to get this team constantly improving themselves? The Scrum Framework believes it is that important to continually improve that there is even an entire event devoted to this.
Setting the stage
When I was preparing for my training course in getting the most value out of your retrospectives, I stumbled across something very interesting that opened my eyes. When talking about Sprint Retrospectives there is one book you cannot ignore. Agile Retrospectives? Making Good Teams Great by Esther Derby and Diana Larsen [Link].
Their book resolves around a model for running effective retrospectives. This model, or framework for retrospectives consists of five stage
- Set the stage
- Gather Data
- Generate Insights
- Decide what to do
- Close the retrospective
A very powerful framework from my perspectives that have helped me run plenty of very effective retrospectives. But I always missed the rationale behind these stages. Only after I started reading some old study books on social psychology, it struck me that this framework makes perfect sense. Here’s why…
Group decision making
There is no better feeling than being part of a group that is able (or at least feel they are) to solve every problem that is thrown at them. Our society now is so complex that one individual can no longer possess all the knowledge, he cannot oversee the entire picture. The necessity to organize ourselves in groups has never been higher. Scrum tries to achieve that as well. Assemble a group a individuals who together are able to win the game. To solve any problem thrown at them by the product owner. This also means that we as a group have to make decisions together as well…and that is not that easy!
Benefits of decision making in groups
Despite it’s not easy there are some major benefits for teams to make their own decision. First, the information and knowledge present in a group is more complete than in smaller groups. Two heads are better than one! However, this is should automatically the case (more on this in my next blog on knowledge sharing!)
Second, when a group comes to a decision they tend to accept the solution more often than when an individual makes a decision for the group. The last thing is hard especially nowadays where the hierarchical structure in organizations are under pressure because those lower in the hierarchy are no longer uneducated individuals but high skilled and knowledgeable. So they are less willing to blindly follow their leader (into the abyss).
This is why the book of John Kotter; ‘Our iceberg is melting’ [Link] so popular. You have to go through great lengths to convince a group to take over your point of view. Wouldn’t it be easier to let the group themselves decide? Just give them some boundaries and they will solve the puzzle.
Third, and last, benefit of group decision making is that it increases the sense of legitimacy of the group. Making a decision as a groups gives them the confirmation that they are in fact a group! However, where there are benefits there are definitely some disadvantages to group decision making.
Groupthink and Groupshift
One of the most straight forward and most visible downside to group decision making is that is takes a lot more time. We all have been in those endless meetings where discussions go on and on for…well it feels like hours sometimes. In a Scrum Team, the Scrum Master plays a big role in facilitating the Scrum Events in such a way that they are as efficient and effective as possible.
Also when making a decision as a group, questions may arise who is responsible for the outcome of this decision. Should one person be accountable or is the entire group accountable. This is a thin line. You see this happening is sports very clearly. If a team is winning, the team is celebrated for this but when results get bad we try to shift the blame to an individual (usually the coach). In organizations you see that when a manager is held accountable he is almost obligated to take the decisions as well. This has become part of our DNA so much that we are having trouble letting this go. And when you start adopting Scrum you immediately get in trouble. I believe that if a group makes a decision, they should be accountable as a group as well. Delivering in small increments limits the impact of decisions made by a group and therefore makes this discussion less relevant.
The biggest disadvantage of group decision making is that it nourishes conformism. So people in a group tend to match their attitudes, beliefs and behavior to group norms. Two interesting sociological phenomena arise here; groupthink and groupshift
Groupthink is the phenomena where groups pressure leads to conformism so any critical, unpopular or minority interest will not be taken into consideration by a group in their decision making process. So what recently happened in a Development Team was that during a sprint planning meeting an ops-engineer made a very good point related to the monitoring of the item under discussion. However, since the rest of the team didn’t had any feeling regarding that topic the comment from the engineer was put aside and never came up again. Groupthink, a minority interest wasn’t taken into consideration by the team.
Groupshift is where members of the group exaggerated their initial toward a more extreme position. So risk averse individuals will propose an even more risk averse approach and the opposite happens with risk seeking individuals. In group decision making this will lead to decisions being made that are more extreme. So when in a group, individuals are far more willing to make riskier decisions. Shared risk makes the individual risks less.
Why we do retrospectives?
So how to deal with these two phenomena? There are two ways to improve the group decision making process and to limit the impact of groupthink and groupshift.
First is brainstorming. This has been a very popular approach in the 90’s and 00’s but the effectives of this approach is in question nowadays.
The other approach is a nominal group technique where you facilitate group decision making by doing a couple of things:
- Get everybody involved together
- Let people think for themselves first about the problem at hand
- Share the thoughts
- Discuss on how to solve the problem
- Order the ideas and decide
You probably connected the dots already but this technique is a nearly 100 percent fit with the approach from Derby and Larsen. So we do retrospectives to facilitate group decision making and in order to amplify the benefits of this approach structuring your retrospective as described above helps! If you look around on the web you can find plenty of ways to run your retrospectives this way. A nice example of this is the Retr-O-Mat, a retrospective generator.
Next post will address another very important aspect of Scrum related to groups. Having a cross functional, multi-disciplinary team to accelerate delivery and knowledge sharing. But sharing knowledge is extremely difficult especially in the very complex world of software development.
