Scrum Retrospective 4 – Decide What To Do

This is the fourth post of my blog post series about the five phases of a Scrum Retrospective. In this post I cover Phase 4— Decide What To Do.

If you haven´t read the previous posts in this series you can start with Phase 1 —Setting the stage

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each Retrospective meeting, which I lead as a Scrum Master.

Until now we have covered the first 3 phases. After Phase 1—Setting The Stage we spend a considerable amount of time in Phase 2—Gather Data to identify the most crucial problems of the team.
Then I covered Phase 3—Generate Insights in my previous post. At the end of that phase we had a list of possible root causes and potential solutions for a problem.

Now, let’s go on with Phase 4 and decide what we are going to do about the problem.

Decide What To Do

The goal of this phase is to create action items to improve in the next iterations.

You identified a list of possible root cause of the problem and potential solutions. Now you want to decide what you want to do differently in the next Sprint.

Therefore you create a list of action items what you exactly want to do differently.

When creating action items there are a couple of things you want to keep in mind:

  1. Make action items actionable
  2. Make action items small
  3. Don’t pick too many action items
  4. Make action items visible

Let’s look at each bullet point of this list a bit more closely.

1) Make action items actionable

You want to phrase your action item in a way that it is completely clear what needs to be done. Be as specific as possible. It shouldn´t require a discussion with the team whether an action item can considered to be completed or not.

An example for a bad action item is “Improve team collaboration”. Phrasing it like this does not tell you what you need to do exactly. It leaves a lot of room for interpretation.

A better example would be “Pair programming on Monday and Wednesday from 10:00 to 12:00”. This tells you exactly what you need to do and when you need to do it. And only if you have really worked together in pairs for those two hours it is clear to everyone in the team that you can mark the action item as completed.

2) Make action items small

You want to make action items small enough so that they don´t have an impact on the amout of planned work for the upcoming Sprint. At this point in the Retrospective you don’t want to commit to work on a big action item.

Planning and prioritizing is done in Sprint Planning, but not in the Retrospective meeting.

If the action item requires a couple of days effort to be completed, then it is definitely too big.

For instance, “Implementing 2-factor authentication for the web application” is too big for an action item of a Retrospective.

If your team is sure that they want to work on that with high priority, then the action item might be “Create a user story for 2-factor authentication and put it on top of the backlog”.

Big action items contain the risk that they are not worked on or cannot be finished in the Sprint. Or something else might be considered more important in the next Sprint planning.

If that happens regularly, then your whole Retrospective meeting has become just a meeting where you commit to things you wish to improve instead of actually improving them.

Having small action items makes sure that they will be completed. Then your team will be consistent in making sure that action items are always finished.

3) Don’t pick too many action items

If you have too many action items it is likely that the team will forget about some of them. It is easy to remember 3 things, but it is a lot more difficult to remember 7 or even more things.

Therefore I make sure that my team creates a maximum of 3 action items per Retrospective so we can keep the focus on the few most important items.

4) Make action items visible

Another method, which proved to work very well, is to make action items visible to the team.

You place the stickies with the action items at a place where the team can see them. Usually I put them on the physical scrum board, which is at the team area. Additionally, you can use some “screaming” colors, like pink or orange, so that they stand out on the board.

Then, a couple of days after the Retrospective meeting, when you see that an action item is not marked as done yet, you can ask the team during Standup about the status. You make the action item “visible” in their mind by pointing it out during the Standup.

So, by making the action items visible to the team in different ways, you can do your best to make sure they will be worked on and completed until the end of the Sprint.

Try-Measure-Learn Loop

There is one more important thing, which you should keep in mind when creating your action items:

Make clear to the team that you are dealing with complex problems here.

Each problem does not have just one root cause and exactly one solution. There might be a combination of circumstances, which lead to your specific problem and therefore there are also multiple things you need to do in order to solve it.

So mostly there is not one obvious thing what you can do to fix the problem. Make clear to the team that Scrum is an empirical approach—you are working with a try-measure-learn loop.

If you have identified a possible solution, you cannot be sure whether this solution might really work. But you can decide to give it a try for a couple of Sprints and measure its outcome.

Then based on what you measure you can learn that this is a good solution and you keep it. Or you might measure bad results and decide to drop that solution, because it didn’t help to fix the problem.

If this is not clear to people, I noticed that some respond very negative to certain action items.

For instance, imagine you have a big issue and you have an action item to tackle that problem. Then, one simple action item is often just a drop in the ocean. This means that even if it is completed it will not have a big impact.

Therefore it is not surprising that some people will react like “That’s not gonna help anyway! We are just wasting our time here with trying to solve a problem we cannot tackle anyway”.

So, making clear to the team that we are working with a try-measure-learn model is a good way to make clear that this is just the first step in the hopefully right direction. This might shift their mind to a more positive attitude regarding the created action items.

Last Step

Ok, so at the end of this phase we have created a few small, actionable items to improve our process. Now we can continue with the last Phase 5—Close the Retrospective.

I will cover the details about phase 5 in my next post of this series, which I am going to publish in about 1 week. So stay tuned and keep an eye on the blog.

Ok, that’s it for today. See you around, HabbediEhre!

Scrum Retrospective 3 – Generate Insights

This is the third post of my blog post series about the five phases of a Scrum Retrospective.In this post I cover the Phase 3— Generate Insights.

If you haven´t read the previous posts in this series you can start with Phase 1 —Setting the stage.

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

We have covered Phase 2 —Gather Data in my previous post. At the end of that phase we had a list of subjects for further discussion.

Now, let’s go on with Phase 3 and generate some insights from those subjects.

Generate Insights

The goal of this phase is to dive deeper in at least one of the subjects from the previous phase. We want to uncover the root cause why certain things happened. And then we want to find options for a possible solution.

We can split this phase up in two steps.

At first we decide which particular subject we want to select. So we have a focus point on one specific subject rather than talking about multiple topics at the same time.

In the second step we dive deeper into the selected subject to find the root cause.

Step 1: Decide for a subject

The decision, which is the most important or valuable subject to pick is sometimes obvious. Often there is a topic, which bothers the team the most. So you as a Scrum Master will obviously decide for that particular subject.

For instance, if the application, which is managed by the team, had a big outage during that sprint, then this is probably the most important topic for the team.

In case the team didn’t already have a separate Blameless Post Mortem for that outage, you as the retrospective leader will obviously decide for that topic.

Dot-Voting

But sometimes it is not so obvious. In such a situation I usually make a pre-selection of possible candidates and then ask the team to vote.

The pre-selection is just done to make the voting easier, because there are often some subjects that you don’t need to dive in deeper.

For instance, if somebody mentioned that he is so happy that he finished his Professional Scrum Master certification, then this is really great to share within the team. But you probably don’t want to dive deeper into that subject.

After the pre-selection I usually use dot-voting, which works as follows.

Everybody gets a set of virtual dots and can place them on the sticky notes on the board. The sticky note with the most dots wins.

For instance, everyone gets 3 dots. Then they can go to the board with the sticky notes and place their dots there. Afterwards you count the dots and the topic with the most dots will be selected.

Ok, now as we have a selected topic, we can dive deeper.

Step 2: Dive deeper

The goal of this step is to find the root cause of the selected problem.

There are different activities to get to the core of a problem. The retromat can help you to find a lot of possible activities.

My favorite options are to have a discussion with the team or to use the 5 Whys activity. Let’s have a closer look at both of these options.

Facilitating a discussion

Having a focused discussion on a specific issue is a very natural and simple approach.

I have made the experience that people, especially very analytical persons like software developers, don’t like to participate in “weird” activities. One developer once asked me why we are doing these “Montessori” games while we could use our time much more effectively by writing some code.

So I tend to keep the amount of unknown activities low—especially with a team, which is not very familiar with retrospective meetings. Therefore just having a discussion feels very natural to everyone involved, because you have discussions all the time. And a good discussion can create very good results as well.

In order to have a good discussion you need some facilitation skills.

During a discussion some people might be very outgoing and talking and talking and you can hardly stop them. Some other people like to stay in the background and don’t say much. They just give their opinion when you ask them directly.

As a good facilitator it is your job to notice such behavior and do something about it.

For instance, you might interrupt the talking Mary and throw the ball to introvert Tom like this: Thank you Mary for your opinion. Now, Tom, you didn’t say much. What do you think about it?

Another thing I tend to do during discussions is to make some notes about the most crucial points that are discussed. I try to identify possible reasons for problems and possible solutions.

Then I put them on the wall, so the group can use that information in the next phase to take a decision.

To be honest this is very hard to do. Because on the one hand you need to facilitate the discussion and on the other hand you should make notes.

While practicing you will get better over time, but at the beginning I think it is not necessary to make notes. It is more important to properly facilitate the discussion.

Ok, so having a good discussion is a nice way to find the core of a problem. Another option to achieve the same result is the 5 Whys activity.

5 Whys

The 5 Whys activity is a method to drill down to a problem by repeatedly asking Why?

The name comes from the fact that often you often find the root cause of a problem with the fifth answer.

For example, let’s imagine the team struggled with an outage of their product during the sprint. And we want to identify the root of the problem with the 5 Whys activity.

Why was there an outage? Something went wrong during deployment and so the application didn´t start anymore.

Why went something wrong? Because Tom, who started last month, made a mistake. He did it the first time and didn´t have the experience.

Why did he do it the first time? Because Mary was on holiday so somebody had to do it. Unfortunately he didn’t get a proper training before that.

Why was there no training? Because it is not part of the onboarding process.

So we identified the root cause of that problem. And the solution might be to add a proper deployment training to the onboarding process.

So by repeatedly asking Why? you can drill down to the core of a problem. And after identifying the root cause you can look for possible solutions.

Recap

Ok, let’s quickly recap the important things of the Generate Insights phase.

The goal of this phase is to drill down to the root cause of a specific problem and find possible solutions.

In the first step we decide on a specific subject, which we want to analyze. For instance by using dot-voting.

In the second step we dive deeper. Among a list of possible options I prefer to have a discussion or use the 5 Whys activity to get to the core of the problem.

When you are done with one problem and there is enough time left for your retrospective you can also try to tackle another subject.

Ok, so at the end of this phase we have analyzed the root cause of at least one specific problem. Now we can continue with the next phase.

You can read about the details of the next phase here: Phase 4—Decide What To Do.

Meanwhile, let me know in the comments about your favorite activities for the Generate Insights phase. Maybe you have something you absolutely love to practice with your team?

Ok, that’s it for today. See you around, HabbediEhre!

Scrum Retrospective 2 – Gather Data

This is the second post of my blog post series about the five phases of a Scrum Retrospective.In this post I cover the most crucial ideas for Stage 2—Gather Data.

If you haven´t read the previous post in this series you can find it here: Stage 1 —Setting the stage

These five stages are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Set the Stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each retrospective meeting, which I lead as a Scrum Master.

Ok, let’s get to the meat.

Gather data

The goal in this phase is to bring the facts of the sprint to the table, so that every participant has the same picture of what happened during the iteration.

I usually split this phase up in two steps. First I announce the hard facts and statistics based on the data the team generated during the sprint. Secondly, we want to get the insights and personal opinions from each individual to generate a complete picture.

Step 1: Hard facts

The idea of this step is to make the status quo transparent, based on the facts you already have. This type of data is usually generated during the sprint and does not reflect any personal opinions, but hard facts.

It is the responsibility of the Scrum Master to get this information before the meeting starts. Even though the Scrum Master doesn’t have to get the data by himself, he is responsible to make sure the data will be available for the meeting.

This data includes: the sprint goal and the amount of planned and delivered story points. Next to that it also includes any other hard facts, which are measured during the sprint.

Sprint goal

First of all I name the sprint goal and we figure out whether we did achieve our plans. Most of the time it is obvious whether or not we made the sprint goal, but sometimes there is a short discussion within the team. This is fine, because I want a collaborative decision if we did or did not make it.

I use this information also to keep track of how the team is doing over time. And you can mention in the retrospective that the team achieved the sprint goal for instance 5 times in a row.

Story points

I mention how many story points we initially planned for the sprint and how many were successfully finished.

Here it is a good idea to have an excel sheet with historical data prepared and show in a graphical overview how the team is doing over time. Keeping this historical data in a diagram can give you insights easily in how the team grows over time, is more productive, finishes more work etc.

Other measured data

You can mention at this point any other important data, which has been measured during the sprint.

For instance, if your team struggles with too many open bugs and too little of them are solved and closed during the sprints, then this is important data to keep track of. This data is usually available easily by having a look at the bug-tracking tool you are using.

In such a case you can announce the amount of open bugs before and after the sprint.

If your team has constantly problems with the high amount of incidents during the sprint, which prevents the team from making good progress with the planned user stories, then this is also important data to keep track of. This data is also usually available in a bug-tracking tool and you can bring this data to the group here as well.

Basically any interesting data, which is measured and might be important to the team, is welcome at this point to share with everyone. This is because it helps that everybody has the same picture of what happened during the sprint.

Data you don’t want to show

But there is also some type of data, which you don’t want to show to the team. This is any kind of data, which might put a specific person on the spot—unless you specifically intend to do so.

For instance, showing how many story points were delivered by each person brings the lowest-scoring person in an uncomfortable situation and doesn´t help the team. Therefore this should be avoided.

You should also make sure to just bring data, which has been measured and therefore is a fact. Don´t bring data, which you think is a fact, but actually is just your personal opinion.

For instance if you know that people didn’t do as much pair programming as initially planned, but you didn’t measure how often they actually worked together in pairs, then don’t mention it at this stage.

At this point it is important to just give the hard facts, which have been measured, to the team so that everyone knows what was going on in the sprint.

Step 2: Personal opinions from each individual

When the hard facts are on the table, the second step in the Gather Data phase is to collect the personal opinions and feelings of each individual.

Here it is important that everyone has a voice. Therefore I always use a format, which gives each individual some time to think on his own and express his or her own opinion.

Silent writing

In order to achieve this I always use a couple of minutes of silent writing, where each person writes down the items on sticky notes. So everyone has to think about his or her own experience, feelings and events during the sprint.

If you don’t use sticky notes, but just start a discussion where everyone shares his or her thoughts, then you usually end up with a very unbalanced set of data. Because more confident people will take over the floor and express their opinions while other participants won´t be able to contribute their thoughts.

Especially if there are a few introverts in the team, these people are not going to speak up while for example the senior developer taking over the floor. Even though the opinion of the introverts might be very valuable, they want have the chance to contribute them to the discussion.

Therefore, for the gather data step I always use a format, which starts with a few minutes of silent writing followed by a round of explanation, where each person explains his or her stickies to the group.

Formats for the gather data step

There are many different formats for the gather data step out there, which basically all work the same way with just slight differences in asking the questions. For instance, there is the Start Stop Continue format, or the Mad Glad Sad retrospective, or you can use the Sailing Boat.

Some of these formats work better than others in different situations. For instance, if the sprint went really well and there is almost nothing to complain, then the Start Stop Continue retrospective is a good way to generate some ideas for improvements.

If you use the Mad Glad Sad retrospective to gather data when a sprint worked really well, then it will basically work, but in my experience you will get much better results using the Start Stop Continue format. If you want to know more about that check out my post about the Start Stop Continue retrospective.

Recap

Ok, let’s quickly recap the important things of the Gather Data phase.

The goal of this phase is to bring all relevant data to the table so that every participant has the same information about the sprint.

This data consists of the hard facts, which have been measured during the sprint. These are the Sprint goal, the amount of planned and delivered story points and any other relevant facts, which have been measured.

The second step is to get the opinions and feelings from each individual by a few minutes of silent writing. After that each individual presents them to the team and clarifies what he means.

At that point you have all the important data ready and can continue with the next phase, which is Phase 3—Generate Insights.

You can read about the next post in this blog post series here: Phase 3—Generate Insights.

Meanwhile I would be interested in formats you mostly use to Gather Data in your Scrum retrospective. Leave a comment if you have any interesting insights, which formats work well in specific situations!

Ok, that’s it for now. See ya in a bit, and HabbediEhre!

Scrum Retrospective 1 – Setting The Stage

This is the first post of my blog post series about the five phases of a Scrum Retrospective. I will cover the most crucial ideas for Phase 1 — Setting the stage.

These five phases are presented in the book Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:

  1. Setting the stage
  2. Gather Data
  3. Generate Insights
  4. Decide What to Do
  5. Close the Retrospective

I use this five-step-approach as a guideline in each of the retrospective meetings, which I lead as a Scrum Master.

In this post I will explain what the leader of an agile retrospective needs to know and should do in order to have a successful start of the retrospective meeting.

Setting the stage

The goal of the first phase is to bring the mind of the team to the retrospective meeting so they have their focus on the work at hand.

You want to set an environment where everybody feels save to speak. Everyone should be in a state that he feels like he wants to contribute his thoughts and ideas as much as possible.

People have been working on other tasks just a few minutes ago before they had to stop and go to the retrospective meeting.

Their mind is still filled with the thoughts of their previous task. For example, one colleague might still be thinking hard on how to solve that bug he is currently working on.

The goal for you as the leader of the meeting is to bring the focus of the team to the work at hand.

What, Why, When

In order to set the stage for the meeting you are starting with a short introduction giving some facts about the meeting itself.

You mention the goal of the meeting, which is to reflect on the previous sprint. And you announce the available time for the meeting, giving the participants an outlook on what they can expect how long they will be locked up in this meeting room.

For instance you might say something like this:

Here we are again at the end of our sprint—this time we completed sprint number 56. Let’s look back together and figure out what went well and what didn´t so we can improve our process and become even more productive. Now it´s 4 minutes past 2, so we have exactly 56 minutes to come up with some results.

After this announcement you should have the groups attention.

I learned that there is another important part of Setting the stage, which is to get everybody to say a few words.

Get everybody to speak up

At the start of a retrospective it is important that everyone says something out loud. If you speak out loud at the beginning of the meeting the chance that you are going to join the follow-up discussion increases drastically.

I couldn’t find where I have read about this fact, but I remember that it was packed with some awesome statistics. Since then I always perform this little exercise at the beginning of a meeting.

There are a couple of possible activities in order to give everyone the chance to speak up.

I usually just ask a simple, open-ended question and ask the people to answer shortly one after another going around in a circle.

The question might be: How do you feel about the previous sprint on a scale from 1 to 5?

Another example is to ask the participants to state in one sentence what they want to get out of this retrospective meeting.

And another example might be: Tell us how you feel about the previous sprint in maximum of 3 words!

The retrospective leader has to make sure that the statements are really short, which means just a few words. You want to avoid that people start a discussion at this stage. You just want to get everybody to speak up to generate the mind-shift and enable maximum contribution of everybody in the next phases.

When everyone has put some thoughts to answer the question then the group should have the focus on this meeting. Everyone has put his previous task on hold and put his attention to the work at hand. The mindset of the group is in a state of getting some work done.

Next: Phase 2

At this point you are finished with Setting the stage and you move forward to the next phase, which is: Phase 2—Gather data.

You can read about the next post in this blog post series here: Phase 2—Gather data.

Meanwhile I would be interested in how you kick-off your Scrum retrospective meeting and what you do differently. Do you have any interesting insights, which you can share in the comments?

Ok, that’s it for today. See you in a bit, and HabbediEhre!

Start-Stop-Continue Retrospective

Reading Time: 4 minutes

Is your team bored with the way you do your retrospective meeting? Is it always the same after every sprint? Then why don´t you try something new?

I recently found a nice article from Mike Cohn about a format of sprint retrospectives, which I haven´t heard before – the Start-Stop-Continue retrospective.

Continue reading “Start-Stop-Continue Retrospective”