Agile/Scrum blog

Onderwerp: Retrospectives

Validated Value – continuously improve your impact

Peter Koning Door: Peter Koning,  08-04-2014
Onderwerp: Validated value  Retrospectives  

Process like Scrum, Kanban, ITIL and Waterfall all describe the steps from idea until delivery to the customers, or from requirement, bug, wish or problem until potentially releasable to customers. They all describe how to deliver value. Which is good, but not good enough.

The only problem is that the real power of Agile isn’t in increasing the value. The real power of Agile is in maximizing the things not done and maximizing the impact. So how can we maximize our impact continuously? Because many process don’t look beyond the output step, we aren’t focusing on validating the value we’ve delivered, on the impact we have at our customers. How can we learn from the things we’ve created and delivered in such a way that our next delivery to our customers is even better? How can we validate our delivered value?

Groups & Scrum: How to stop a team?

Stephan van Rooden Door: Stephan van Rooden,  25-03-2014
Onderwerp: Groups  Retrospectives  Scrum Teams  Agile Coaches  

This is the fourth post in a series of blogs on groups and scrum. In the first three posts, I focused primarily on explaining the benefits of groups from a social psychological view. This post will take a more practical point of view.  So based on what I described in the previous posts it shouldn’t come as a surprise that this collection of individuals which we call a team, eventually becomes a real team! Hurray! But what if the team has to stop?

Groups & Scrum: Why we do Retrospectives

Stephan van Rooden Door: Stephan van Rooden,  10-03-2014
Onderwerp: agile  Scrum  Retrospectives  Groups  

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.

Groups & Scrum: Why we do Retrospectives

Stephan van Rooden Door: Stephan van Rooden,  10-03-2014
Onderwerp: agile  Scrum  Retrospectives  Groups  

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

  1. Set the stage
  2. Gather Data
  3. Generate Insights
  4. Decide what to do
  5. 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:

  1. Get everybody involved together
  2. Let people think for themselves first about the problem at hand
  3. Share the thoughts
  4. Discuss on how to solve the problem
  5. 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.

 

 

Groups & Scrum: A group of people does not make it a team!

Stephan van Rooden Door: Stephan van Rooden,  01-03-2014
Onderwerp: Scrum  Retrospectives  Scrum Teams  Groups  

This is the first post in a series of blogs on groups and Scrum. This first blog will look into what a group is and into what makes a group into a team. In future posts I will explain more on why we do retrospectives, knowledge sharing in a group and much more. Let’s start with the definition of what a group is.

Done, usable and potentially releasable product increment?

Melvin Nijholt Door: Melvin Nijholt,  29-11-2013
Onderwerp: improvement  Scrum  Retrospectives  

The scrum guide states that development teams should create a "Done", usable and potentially releasable product increment every sprint. But what does dit actually mean? To clear this up we have to look what "Done", usable and potentially releasable actually means in this context.

Retrospective

Dave Woertman Door: Dave Woertman,  02-08-2013
Onderwerp: Retrospectives  Scrum  Agile  

Tijdens het coachen van teams heb ik veel contact met Scrum Masters. Binnen mijn huidige Agile transitie opdracht heb ik de verantwoordelijkheid over tientallen teams, waarbij ik me voornamelijk focus op het werk van de Scrum Master. Een collega van me begeeft zich meer op het vlak van de Product Owner.

Aangezien de boeken voorschrijven dat de Scrum Master verantwoordelijk is voor de retrospective meeting, krijg ik daarover de meeste vragen. Welke manier van retrospectives werkt het beste? Wat is het doel van de retrospective? Hoe versnel je het team?