What can you do if retrospectives repeatedly go wrong?

Not all retrospectives go well. When you support a team as a Scrum master, there are all kinds of strange behaviours or team dynamics that can make retrospectives go sideways, time after time. A facilitator can’t always prevent that. At least I can’t. Not always. Got lots better, though. Over the years I’ve picked up several different angles to get retros back on track (what I think is the “track” anyway). Enjoy:

Choose specific activities

When I started out as a Scrum master I thought my only option was to carefully choose activities to nudge people into the direction I thought they needed to go. And for some situations that works well.

The team acts the victim. Others need to change, there’s nothing they can do? Try Outside In, Circles & Soup, If I were you, …

There is a specific “weak” area they don’t like to look at? Communication Lines for (surprise!) flow of information, Quartering for Tickets, Company Map for Power Dynacmics, …

Talk to individuals

Then I started to address individual behaviour in spontaneous 1:1s whenever I could snatch the person alone. For instance: “I’ve got the impression that you often address me during the retrospective (/standup/…). The information is not for me, it’s important for the others. I would love for you to try to look at the others more.”

Other example: “You’re very quiet during the retrospectives. I think your perspective is valuable and your view and ideas are missing. We are missing out. I’ve also noticed that you often aside, a bit removed from everyone else. Are you not feeling as part of the team?” In this case the answer was No. If it’s Yes, you’ve got a whole other problem to work on.

“Would you humor me and take a seat smack in the middle next time?” In this case it worked. He picked a middle seat and engaged more. (I had addressed the quietness before with other suggestions. I chalk that win up to the seating arrangement \o/)

Set the topic

Then I re-learned from “Agile Retrospectives” that I can set a topic for the entire retrospective. (I usually let participants set the topic, i.e. collect topics and then Lean Coffee their most important ones.) Setting the agenda gives you a lot of power. Wield it wisely.

Style Critique

This one I learned from a great ex-colleague. He facilitated a meeting among team leads. He was the boss of about half of the people in the room. When we thought we were done with the retrospective, he went meta on us and reflected our own behaviour back to us, namely that we talked over each other and didn’t really let each other finish. One possible interpretation of this is lack of respect. AFAIR he then made the express wish for us to be more considerate next time.

On the personal level I was stunned, I was part of the group and had not really noticed our subpar behaviour. On the meta level I was thrilled. I remember thinking “Wait, you can do that? This is great (if sparsely used)”. It was a new tool to address group / team problems.

Formerly I would have just shaken my head in despair that the team has such poor dynamics and tried one of the previous approaches, often to no avail.

I would not have dared to go meta as a new facilitator. Also I wouldn’t have had enough examples of behaviour to compare against and know when it’s appropriate to go meta critic. Now I sometimes do it after the actual retrospective, for example in this case:

“You’ve off-handedly mentioned that $person’s behaviour is detrimental for $team, yet doing anything about this behaviour is not part of your solution. From my perspective it looks like your action item will work around issues with $person. That seemed very strange to me. Worth pointing out.”

It’s just an observation, something to ponder. I won’t press the issue. They can dwell on it. If it’s important it will come up again.

So, there they are. My re-railing tactics. What are yours?

PS: Did you know there's a Retromat eBook with all activities from Retromat, plus tips and tricks? Check out the eBook

Postcards (#42)

[This post was first published in 2012 when Retromat was tiny and new. Seems like a lifetime ago.]

I’m always looking for inspiration for retrospectives e.g. over at Thorsten Kalnin’s or in the retrospectives wiki. Time to give back! This is a format I tried out some time ago: The basic idea is to let the participants describe the issue with a metaphor.

A metaphor is a literary figure of speech that uses an image, story or tangible object to represent a less tangible object or some intangible quality or idea; e.g., “Her eyes were glistening jewels.”
(Source: Wikipedia)

There are several ways to have participants come up with metaphors, e.g.

  • “Which movie title would best describe our sprint?”
  • Drawing the sprint as described in this blog entry
  • Or… Choose a postcard as a representative!

There are two reasons to use metaphors in a retrospective:

  1. It gives a shared understanding of someone’s perspective
  2. It can open a path to find new solutions. It’s similar to an approach you sometimes take in math: Say, you have a problem and don’t know how to solve / approach it. Some problems can be transformed into an analoguous form in a different field of mathematics, where it can be solved. Afterwards you transform the solution back to the originating field and have a solution to the original problem. Tada

Enough theory, this is how the session went down:

Situation: The developers and PO were going through a rocky patch back then and I wanted to help them overcome this.

Preperation: I selected about 30 postcards for 5 participants and 2 rounds. For most postcards I had a loose association how they might relate to the topic. On top of that I stacked a few random and / or abstract images for good measure. (Who would have thought my impressive collection of postcards would come in handy for my agile endeavours?) I scattered the postcards all over the room on the floor, so that the participants have to get up and wander about.

Session plan: The postcards were part of the Information Gathering phase:

  • Pick the postcard that best resembles how you see the team right now.
    (No shared postcards. If you’re not fast enough, pick another one.)
  • Write down 3 keywords that describe how you see the team (with regards to the postcard)
  • In turn everyone hangs up their postcard and keywords and explain their choice

Usually you’d only have one round but we had a second round on the question “How would you like the team to be 3 months from now?”

Followed by:

  • Brainwriting: How could we get from the Now-state to the Wish-state?
    (I often do written activities to level the playing field for quieter team members.)
  • Collect all Brainwriting ideas, cluster and dot-vote which 3 suggestions to talk about.
  • Create action items (preferably as SMART goals)

It was the most productive brainwriting session I’ve ever seen.

[This Change Management training gave me the idea with the postcards.]

PS: Need more ideas for retrospectives? Try out my very own Retr-O-Mat 🙂
The Postcards are Activity #42, Brainwriting is Activity #66 and SMART Goals are Activity #13.

How to transition from Set the Stage to Gather Data

Here’s another interesting question about retrospectives I got in my inbox, this time from Claudia: 

I just became a Scrum Master and will have my first Retrospective ever. What I find difficult for the beginning – I’m sure this will change after doing some Retros – is the transition from Set the Stage to Gather Data. After setting the stage, how do I go the Gather Data? Do I simply say “thank you, now, we’ll continue to gather data…“ or do I comment anything from Set the Stage to Gather Data.

[If you are new to retrospective and have never heard about the phases you can find out more here.]

Questions like these are great, because they make me examine something that I don’t consciously think about and “just do”. So yeah, how do the heck do I frame the transition? As always, the answer is: It depends 😉

It depends on what I want to achieve with “Set the Stage” (StS). Let’s look at the different cases:

Default case: I want everyone to speak, preferably about something positive and true and relevant to the last iteration

In this case, yes, most of the time it is close to “thank you, now, we’ll continue with gathering data…“ I wouldn’t use that exact phrasing because it implies that the 1st phases content is throwaway, when it reveals something about the last iteration. I can’t remember ever picking a starting activity solely for the fun of it… 

My default opening method is a question that goes around the circle. Here are some of these questions and a transition to “Gather Data” that lends itself to that question:

Of course, the transition has to also match the activity you’re leading to in “Gather Data” (GD). But yeah, usually the sticky notes from StS just keep hanging on a board and are not re-used. If people have the same point again for GD, they can rewrite the sticky or re-hang the existing sticky note. I don’t care either way.

Special case: Testing the waters – with a new team or in a conflict situation 

When I facilitate for a team for the first time or in a conflict situation I like to test the waters with ESVP: Do people want to be here? How much engagement can I expect from them?

If I expect problems, I might use Constellation or Team Radar to explore questions like “How likely are you to speak openly?”. It might be necessary to adapt these to a written form that participants fill in anonymously.

The important thing is that you have to be willing to deal with problems that come up. What if half the participants are Prisoners – How will you handle it? What if nobody dares to speak openly – What will you do?

In short, you’ll have to have at least a rough idea of a Plan B. The more problems you expect, the more solid your Plan B needs to be.

Btw, “normal” opening rounds and retro activities can also derail, either because something “traumatic” happened to a single person (divorce, sick loved one, …) or the team as a whole (someone being fired, new boss, …) that you hadn’t been aware off. In these cases, don’t try to follow your original plan. The retro is not an item to tick off a list. Stay calm, sometimes it’s okay to just let people talk. But I digress …

Special case: Outcome Expectations

Related to the previous case: Some activities are about the retro on a meta level, e.g. asking for Outcome Expectations. I’ll try to help meet the expectations or at the very least check if they’ve been met or not throughout the retro.

Special case: StS is already data heavy

There are some data heavy StS activities in Retromat that can easily be fleshed out for use in GD, e.g. Amazon Review or Postcards. Don’t be limited by the phase that is assigned in Retromat. There are many activities that also fit into a different category.

Actually, when you look at my retrospectives individually, you’ll usually find only 4 to 4.5 distinct phases in them. The middle three phases kind of bleed into each other. Which one I stress varies. But whatever I do, you can spot Lean Coffee in each one of them, just rarely as a standalone technique.

(If you plan your retrospectives with Retromat, you can get around the strict “5 phases” layout by manually changing the IDs in the URL and hitting enter.)

Anyway, the above are all the special cases I can currently think of. Do you have any to add? How do you transitien between StS and GD?

Thank you for the question, Claudia! It was fun to think about this!

PS: Did you know there's a Retromat eBook with all activities from Retromat, plus tips and tricks? Check out the eBook

My most important retrospectives were horrible

I’ve got a confession to make: I think fun in retrospectives is overrated. And I never bring cookies, when I facilitate.

Don’t get me wrong, I prefer having a good time to moping about and yes, I prefer participants to be in a good mood. Light hearted people are more creative and willing to try new things.

But all my most important retrospectives – the ones I still remember years later – were horrible! Or at the very least deeply uncomfortable. That holds true regardless of whether I facilitated or was a regular participant.

The important retrospectives, the ones that really counted and made a profound difference were about troubling topics: When something or someone wasn’t working out despite everyone’s best efforts. These retros had a big impact like teams dissolving; people leaving teams or even the company. That’s category of events I’m talking about.

Something like that is decidedly not fun. But it’s necessary to have these conversations. I’m grateful to people who have the guts to bring up the crucial topics even if it hurts in that moment. After the dust has settled everyone is better off, because a harmful situation has turned into a new beginning. And work in general, not just retrospectives, has a chance to be fun again.

PS: Did you know there's a Retromat eBook with all activities from Retromat, plus tips and tricks? Check out the eBook

Activities for Checking up on Action Items

There are a lot suggestions for Retromat that I can’t  include. Sometimes because the strict 5-phases format can’t accommodate them. One example: Anja Schwarzpaul developed the  following activities for “the new Phase 2” (that I used to call “Phase 0”) aka “the phase in which you check what happened to last retro’s action items”. So far, there are very few activities for this new phase described out there. That’s why I’m extra excited to have Anja’s permission to share these two with you!

Her reason for coming up with these?

I feel it’s important to analyze successful or completed experiments in at least as much detail as failed or incomplete ones. Success doesn’t just happen. There’s always a reason. Real life success example in my team: The phrasing was clear and concise, leaving little room for misunderstandings and making the item easy to follow.

And here are Anja’s activities in her own words:


Flow Chart

Use a good old fashioned flow chart to dissect a single action item. (Probably scales to 2 or 3 actions). Duration is flexible and largely depends on the number of questions.

Photo courtesy of Anja Schwarzpaul

From a start node, draw an arrow to a decision node labeled “Done?”or “Success?”. Now branch to “yes” and “no” paths along one or more boxes containing questions to be asked. Near the end of the diagram, merge both branches into a final box “Anything else?” and end in a final state.
Follow the path that the team indicates. If the result is ambiguous, use the “no” branch until just before the merge, then the “yes” branch.

You can either display the entire diagram at once or draw it as you go along. I outlined the start and decision nodes with a marker and sketched everything else with a pencil, in real time outlining only the path we used. This allows for adapting the question(s) to the situation.

Possible Questions:

  • Why did / didn’t it work?
  • How did / didn’t it work?
  • What could we have done to make it work?
  • What does it do for us as a team?
  • Is this something we can use / try again…
  • on a regular basis?
  • in a different context?
  • at some point in the future? (for non-continuous activities, e.g. release estimation)

Improve the Improvement

Suitable for 2 or more action items. Duration depends on the number of items and questions.

Write each hypothesis / item / experiment on a large-ish index card or sticky note. Lay them out on the table or stick them to a wall or board. Let the team rank them from most to least successful, top to bottom. Now ask a few strong questions to help the team analyze the outcome of the experiments. The goal is to get some general ideas of why and how experiments work, and put these ideas to use during the “decide what to do” stage, thus improving the improvement.

Possible Questions: What would have had to happen in order to…

  • make the least successful item come out on top?
  • reverse the order?
  • make all items an equal success?
  • move item <no.> move up a spot?

And maybe:

  • Under which circumstances would you not be able to rank the results?
  • How do you feel about the success to priority ratio?

If I ever have more time (fat chance…) I’ll figure out a good UI to include the new phase in Retromat. Until then, thank you Anja for sharing these with us!

PS: Did you know there's a Retromat eBook with all activities from Retromat, plus tips and tricks? Check out the eBook

Activities to say farewell and reminisce in a retrospective

Teams go through stages. They form, clash, perform well, quarrel, perform, and so on. Until they  eventually disband. Tuckman called this stage “Adjourning”.

A while ago, Stephane asked for activities for a retrospective for an adjourning team. Here are some suggestions:

My team is awesome” would be a great opener.

Appreciative Inquiry” would also work well, if the questions were tweaked a little to serve the purpose.

If you’ve got a budget to take the team out to eat, “Retrospective Cookies” are an excellent option.

I guess it depends a little on whether you’d rather the team takes away a farewell lesson that they can carry over to the next team or you’d rather let them bask in their team spirit and appreciate each other.

What activities do you recommend for an Adjourning retro?

PS: Did you know there's a Retromat eBook with all activities from Retromat, plus tips and tricks? Check out the eBook

“Too many topic ideas leave too little time to talk in-depth” – Retrospecive Problems

Scrum Master Ellen wrote me about a problem with running out of time during retrospectives:

“I have a team that is quite elaborate in their retrospectives especially in the gathering data and insights part. Perfect, but this leaves less time for deciding what to do and transforming problems we face into action. Do you have suggestions on how to keep the teams focused on only the really important things they want to fix in the next sprint? The thing I try now is to minimize the number of post-its each person adds, but I would love to have some other suggestions.”

Yep, I definitely know that problem quite well. As I facilitate short retros (45-90 minutes) time is always an issue. Even small teams can come up with a multitude of topic ideas. And the more topics a team suggests, the fewer it can actually talk about.

Regarding minimizing stickies, there are at least 3 different ways to do it, all with their own trade-offs:

A) Give only very little time to write down topics
Con: Stresses some people

B) Limit the number of stickies to write (“Write 3 stickies with your most important topics”)
Con: Gives some people analysis paralysis

C) After writing, tell people to go through their stickies and only keep a certain amount (“Please count your stickies. If you’ve got more than 5, only keep the 5 most important ones and discard the others”)
Con: People have to throw away some of their work

[Z) You or the team set the topic beforehand and only explore aspects of this limited scope – Completely valid option if there’s an “obvious” topic to tackle]

Between options A-C, I use C most often but choose depending on the team. I pick the way I think they can best live with.

Alternatively, you can try to shorten the time that people take to present their topics. By 1) making them aware of the time problem and 2) intervening whenever people dig into a problem pre-maturely and start discussing instead of moving on to introduce the next sticky.

In my context (mature teams, very short retros of 60min every 2 weeks) “Gather data” is strictly for broadcasting: Everybody hangs up their sticky ideas, says one sentence per sticky and that’s it. Clarifying questions are okay, but no going into detail. Participants are great at reigning themselves in, when they go too deep into a topic. Everybody is used to postponing until after dot-voting and then discuss the agreed-upon topics.

That’s certainly learned behaviour. I’ve recently started to freelance on the side and now sometimes introduce retrospectives in other companies that are new to it. I noticed how easily participants get into details before it is clear, which topics are shared concerns. I stepped in a number of times. That’s when I realised how rarely (if ever) this happens “at home”.

One way team members can help each other stay on track is with Jeff Patton’s Cups.

Hopefully, some of these ideas help you carve out more time for the important topics 🙂

PS: Now I wonder what a “normal” amount of topics per retro is. Across several teams I found we typically cover 2-3 topics in a 45-75 minute retro.

How many is “normal” in your retros? And how long are those retros?

PS: Did you know there's a Retromat eBook with all activities from Retromat, plus tips and tricks? Check out the eBook

Phases are not always linear in retrospectives

If you facilitate retrospectives then you’re probably familiar with the 5 phases from “Agile Retrospectives” by Derby and Larsen:

  1. Set the stage
  2. Gather data
  3. Generate insight
  4. Decide what to do
  5. Close the retrospective

Whenever I talk about them and in all the material I’ve created, it always looks like the phases are strictly linear. But that is not how they work in the majority of my retrospectives – because I rarely have single-topic retros. I usually run a “gathering potential topics”-activity like “Speedboat” or “I like, I wish” and then the team works through 2 or 3 of these topics.

It would be strange to first talk about 3 topics in depth and afterwards come up with action items for all of them. Instead we talk about 1 topic in depth and create an action item for this topic. And only then start with the next topic. Like in this highly elaborate diagram 😉 :

I thought it might be worth stating this explicitly as it’s not necessarily obvious for beginners.

What about you? When do you decide on action items?

PS: Did you know there's a Retromat eBook with all activities from Retromat, plus tips and tricks? Check out the eBook

“How can I motivate people for retrospectives?”

… or “Retrospectives are only Step 1 (of 2)”

“How can I motivate people to do retrospectives?” is a question I used to hear frequently.

If you ask me, that’s the wrong question. It’s wrong because you don’t have to motivate people to do something that they perceive as valuable.

Which makes the real question:
Why aren’t they getting value out of their retrospectives? And is there anything anyone can do to get them their money’s time’s worth?

The only time, when the “motivation” question is admissable is if you’re trying something for the first time. You’ve never done a retro before? Yes, then you’re asking for a leap of faith from participants. And maybe the first one is wonky and you need a second one to make it count. But that’s it. From then on retros have to pay their own way – just like any other meeting should. If it’s not creating value then why are you doing it?

Btw, the retrospective itself is usually not the problem. It’s what happens afterwards. Which is often enough: nothing. It’s unfair to tell people “come on, we’ll look for improvements” and then not implement a single improvement idea. The actual meeting is Step 1. Following up on the agreed upon action items is Step 2.

When is a retrospective successful? Change happens.

Sometimes this problem with Step 2 originates in the retro: The improvement ideas are too vague to be actionable. Other times it’s outside: There’s not enough time or money to do anything. If retrospectives don’t affect any change or these changes aren’t beneficial the majority of times, then yes, people don’t want to do them anymore. And rightly so. They shouldn’t. In these circumstances, retros are a waste of time.

Ironically, I’d use a retro to figure out what’s going wrong and how to actually make them more valuable 😛

But only after I did my homework. And I’d try something new, not the same format that failed people before. Maybe this one.

PS: Did you know there's a Retromat eBook with all activities from Retromat, plus tips and tricks? Check out the eBook

Things happen in their own time

[The following is my piece of advice for Yves Hanoulle’s collection “Tips from the Agile Trenches“.]

What type of person picks a relatively new career like “Scrum Master”? A role that often involves working in organizations that transition to agile and go through lots of uncertainty. A role that focuses on “inspect and adapt”, e.g. change. What type of person indeed? Probably a person that is curious and excited to try new things. Does that sound like you?

Here’s the thing though, different people have different degrees of “eagerness to try stuff out”. As a Scrum Master you are likely very near the “Yay, let’s try this”-end of the scale. Which means that most of the other members in the team will be closer to the “tried and true”-end scale than you, i.e. less eager for change.

It can be frustrating if you can hardly wait to experiment while others want to wait and see. At least it was for me. I was sooo impatient. Why didn’t the others feel the same urgency and thrill I did?

I’ve since realized that things happen in their own time. We’re asking people to think and act in a new way after they’ve been seeped in the “traditional” way for years and years. That takes time. You can only help people with what they are ready to hear and with the problems they are aware they’re having. Nowadays, instead of pushing harder against ever-increasing resistance, I’m planting seeds – ideas for what the team can try. Sometimes the team runs with something right away, sometimes they come back to a suggestion after weeks, sometimes they come up with a different solution, sometimes the problem goes away. All of these are fine.

So please don’t beat yourself up (or forcefeed the team) if things don’t seem to move fast enough. Remember that they are likely not on the same page. Yet. Be patient, sow the seeds and be there to water the seedling when it breaks out of the soil towards the sun.

And the best of all: Change is like a muscle. The more new things you try out as a team, the easier it gets. Eventually big changes become easy.

[Curious about the other tips in “Tips from the Agile Trenches“? Use this link for a 75% discount :)]