Your Favorite Agile Retrospectives. POST THEM HERE AND LETS BUILD THE ULTIMATE LIST by Troy Lightfoot


#23

Updated the OP

Here is @rajanikasturi speed car retro he was mentioning.

Speed Car:

http://www.funretrospectives.com/speed-car-abyss/


#24

Here’s a sample of the Sprint Satisfaction Surveys I use. We have a fair number of our teams using this or modified versions of it. I don’t always throw in a bonus question, but will use ones like “What’s our super power?” What’s our kryptonite?" “What services does the team provide?” or items that hone in on a specific Agile principle/value.

https://www.surveymonkey.com/r/D936V3G


#25

I love using

  1. timeline exercise combined with the “sad face/smiley face” categorization of event on the timeline
  2. Story cubes for “Setting the stage” where everyone can pick an image that represents his/her emotion at the beginning of the retrospective or an image that remind them of their last Sprint. Fun way to start a retrospective that helps to engage equally introverts and extraverts. Also works great with the teams that have non-english speakers.

#26

Love the story cubes. They are really priced low too:



Reminded me of “Muse Cubes” which I use for long meeting sessions to keep the energy going.


#27

The dixit retro is another variation of the story cubes. I posted about it earlier in the thread. Awesome everyone!


#28

Another one I like that I just used with one of my teams today is “I like…, I wish…, I wonder…”. Here are a couple of write-ups I found on this one.

I personally like to do this one without stickies up on the board. I like to give the team 5 minutes to think about “I like, I wish, I wonder” items and stickies they can write their thoughts on but when it comes time to discuss them I have each person go one at a time and tell one of their items. Make sure everyone gives at least one before doing a second round and so forth till the team runs out. Lots of good conversation has come out of this activity every time I have done it.

Happy Retrospectiving Folks!


Coalition Community Feedback / Retrospective
From wish to action retro
#29

We are planning a department retrospective to emphasize needs for cross-functional solutions and collaboration. It will be almost 60 people from five location connected via a web conferencing tool. We are two moderators.

Any thoughts how such a retrospective can become more engaging for everyone are highly appreciated!


#30

I have to admit having 60 people engaged at the same time without splitting into groups is difficult. Over the wires would be quite a pickle. I’ve been pondering this for a while. I’d be looking for games to open the communication. I’m assuming each site is 5-15 people?


#31

Between 2 and 20 people per site.


#32

I’d definitely try and use a tool to help with the facilitation of the retrospective. Something like Scatterspoke and the like. Also I’d try and figure out how to break the group into sub-groups for sure if at all possible, probably by location and some of the bigger locations might have to break into groups as well. Any activity that facilitates breaking into sub-groups then coming back into one to present results would be how I’d try and tackle it.

Anyhow getting a little off the original topic of best retrospective techniques so I’ll shut up now. lol


#33

@hdietrich I have a wild and crazy idea for a distributed retro of 60 people.

1) Use https://zoom.us/ as the connection point.
Great VoIP and the ability to split people out into break out rooms (manually or automatically)
https://support.zoom.us/hc/en-us/articles/206476093-Getting-Started-with-Video-Breakout-Rooms
Can message all rooms as admin, call folks back into the main room etc. Awesome.

2) A Ten Pack of Keep Talking and Nobody Explodes
http://www.keeptalkinggame.com/bulk-purchase/index.html
A puzzle game that is incredible at revealing how shared vocabulary, collaboration over specialization, and repetition makes for high performing teams.

I’ve run this retro twice - once with 25, once with 35. With a second facilitator should be able to scale to 50.

Groups of 5 ± 2 work well.


Source of idea from Josh Briggs.

I’m working on a write up of my experiences so far with it; here are some notes:

The Big Idea

Have you ever felt a breakdown in communication around requirements?

Or maybe a lack of connection between Dev-Team members and the Product Owner? Or Product and Design? Or any other role combination…

What impact do component silos have on our ability to deliver value at the right pace? What impact does specialization versus collaboration have? How does previous experience affect things?

Important keys for solving for these problems include:

  • Communication
  • Collaboration
  • Empathy

During this retrospective, we’ll explore the impact of these keys and discuss ways of increasing their use - continuously improving the effectiveness of our team work.

The Role Playing Scenario

One teammate (the “Defuser”) is trapped in a virtual room with a ticking time bomb they must defuse.
The other players on the team are the “Experts” who must give instructions to defuse the bomb, which they do by deciphering information found in a bomb defusal manual.

But there’s a catch: the experts can’t see the bomb, only the defuser can.

Oh, and the team has only have 5 minutes. And one mistake too many and things go boom!

Debrief

What helped to solve the puzzle?

  • Collaborating all on the same module
  • Solving for the difficult/unknowns first
  • Using predictive information
  • Being explicit
  • Listening clearly
  • Understanding structure
  • Providing clear, detailed, explicit instructions
  • Providing enough nuance, enough details
  • Having a shared vocabulary
  • Having patterns, sequences, repetition
  • Doing the familiar first
  • Moving on when stuck
  • Having a clear game plan at the start
  • Active listening
  • Practice, repetition
  • Familiarity with “code base” (i.e., the modules)

What hindered puzzle solving?

  • External interference (interruptions)
  • Creating silos or specialization (this is MY module that is YOURS)
  • Not understanding documentation (no time in advance to read the manual, yet forced right into using it.) i.e., insufficient grooming /planning
  • Not having time to onboard / learn
  • Ambiguous / poor communication between team members
  • Lack of shared terminology
  • Having new problems all the time / changing conditions
  • Stress / Time pressure
  • Lack of planning
  • Assuming other people had the same knowledge as you…
  • Too many “architects” / cooks directing the recipe

Key Take-Aways
Persistent team membership and repetition of game play:

  • allowed teams to experiment quickly (silos vs collaboration)
  • developed a shared vocabulary and a process unique to each team
  • created rapid fail/learn cycles that promoted higher levels of performance

#34

@andycleff this is marvelous, as it the exactly the kind of thinking I am after

The reason for having retrospectives for a department of 50+ people distributed across several location is communication, collaboration, and - very important - empathy.

Splitting groups by location, roles, components, or features would make my life easy, but I would miss the objective to foster exchange and feedback between all members of the department. It is especially important as you can observe the rise of silos and dogmatic behavior in smaller groups if the feedback loop is missing.

I still need to digest your suggestions, but they are really compelling to me. The combination of ad-hoc grouping in web conferences without upfront notice as well as the nature of the puzzle you are proposing makes a lot of sense to me!

Bad thing for me will be to convince our office it to permit a second web conferencing to exist besides the one and to raise funding of $600 for a “puzzle game” with my boss. But these are the kind of challenges I love to pick up if I see that they can improve my teams :slight_smile:


#35

@hdietrich

My teams continue to play the game in their slack time. By choice. Other teams outside my fence approach me when they hear about it and say “Can we play too?” That alone is an indicator to me to the value of the experiment.

As far as convincing the office… what if you pitched it like this:

  • A ten pack of the game is $135 (that’s all you’ll need to support 10 groups of 5 players each. You don’t need a license per player, just one per “defuser”)
  • Zoom is $15 month to month. (Free won’t work, as it has a 40 minute time limit per session https://zoom.us/pricing )
  • So the out of pocket investment is $150.

Is the office willing to spend $3 per person for a 90 minutes experiment that will likely lead to improved levels of collaboration, communication and empathy that will endure for months?


#36

Adding a new one here. Pretty simple!

Anchors and Engine
This is a simple activity for helping the team to identify things that make them move faster, and things that slow them down.

Running the activity

  1. Ask the participants to write notes and place them on the following two areas: Engine and Anchors.

– Engine: What is the fuel for our engine? What are the things that push us forward?

– Anchors: What is holding us back, or slowing us down?

  1. Group the notes and discuss.

Boat


#37

I love it @troy - a nicely “minimal” approach to speed boat / sail boat

And it nails the two most important elements!


#38

@hdietrich: I finished my write up on the “Bomb” retro:


#39

Just did this one the last two days with two different teams. Really enjoyed it!


#40

Glad that it was useful to your teams @troy!


#41

I tried the speed car abyss out of curiosity. I thought it might be interesting. It went amazingly well. Conversation started the moment we started putting stickers on the board.

We were able to distill thoughts down into reasonable actions and we can make a move on it. Definitely a keeper. Thank you.

(Yes, I even drew the car)


#42

A useful one I run every once in while, especially with teams who are new to (or out of practice with) retrospectives, is a Magic Wand retrospective.

It’s a twist on the basic retrospective. As with the basic format you create Doing Well and Could Improve columns on a whiteboard, but then add a third called Magic Wand.

The purpose of the Magic Wand column is to challenge the team to come up with 1 or 2 issues/fixes that if they could wave a magic wand and could instantly fix.

The benefits of this retrospective are:

  • Keeps team focussed on improvements they can action. The team collates actual improvements for the team within the Could Improve column rather than putting out of scope (i.e. large business issues) in the improve section.
  • Understanding Allows a cross-functional team to understand each others pain points (i.e. the test engineer would wave the magic wand to get a better Android emulator).
  • Feedback to other parts of organisation The suggestions gathered under the magic wand column are good to get feedback on, these can be: ideas/concerns over the business roadmap (raise to CEO/CTO), problems with specialist platform tools , etc.
  • Some of the Magic Wand items can be discussed and turned into actions. Someones magic wand item might be an achievable acton, once ideas are talked through with other specialists.