Planning a quick retrospective

Question

If we had a semi-crummy sprint with low velocity and little to show for it and don't want to inundate ourselves with scrum-related overhead, fully cognizant that something not-right happened, with only half the team on location what simple tricks can a scrummaster play to enliven a retrospective, keep it useful and not bore the team into submission or give them yet another reason to hate scrum.

How can I timebox the retrospective to about 20 minutes, get an action item and not have the team feel like scrum is failing them?

_{P.S. I'm not the scrummaster. I just am a scrummaster who has been appointed to run Sprint Retrospective meetings. If I were scrummaster, I would have made the 2 week sprint a 3 week sprint because I knew half the team was going to be out of the office half the time.}

Answer 1

As you said the team was out of office for half of the sprint and there is little to show at the end of sprint so that means at least the team did good job in including the stories that can be completed in actual sprint( which is one week). So give them +1 for that.

NOW

You do not need to change the usual way how the team has been doing retrospective in this specific case. instead this is a perfect example where actually team members can investigate their efficiency as a team and call out the inappropriate sprint/capacity planing, use of resources, getting away from purpose of sprint ... and many more.

if team members are not able to recognize anything wrong with this sprint then you as a scrum master(as a retrospective only scrum master) start asking few questions in retrospect to guide them why we are doing retrospect and what kind of question they should as themselves in retrospect.

With my limited knowledge to team/product/env I can just give example of the questions team should be focusing on, but you will have to refine them as needed.

Question:1 "What does the team think about this capacity planning? knowing that the team will be away for half time, could we have done better job in capacity planning ?"

Question 2: "What does the team thinks about stories they picked in this sprint? Have we done good job in sprint planning knowing that end of the sprint we should be demoing something which is adding some business value to our product."

Answer 2

I am a little unclear as to what your actual question is here. My advice though would be to have a clear goal/focus for the retro - probably something around accounting for capacity when half the team is out. Action items might be something like get everyones schedule prior to next planning so we can ensure our commitments are actually doable and they are not setting themselves up for failure.

Answer 3

A large part of the context is missing so I'd stick to your "requirements":

1. Explain why you're timeboxing
2. Focus on the actions to take, they should be very precise (long-term plans are not a 20 minutes job), actionable, and there should be a clear way of measuring whether the goal has been accomplished or not
3. Let the team come up with a list of action (maybe one per person) and let them explain why is important. The others should listen but not criticize it.
4. Let people vote the best action to take and, if needed, refine the action.

While you do this I'd take a look at the interactions, especially if the exercise fails, the way you phrased your question gave me the impression that you're navigating in troubled waters, so maybe there are bigger problems that can't be addressed by the retrospective or solved by quick tricks or exercises.

That said here you can find plenty of exercises that you can use to animate your retrospective:

http://www.funretrospectives.com/

PS

I'd also advise you to have a look at the "Safety Check" exercise as explained by Liz Keogh here:

http://lizkeogh.com/2012/12/05/how-to-run-safety-checks/

Answer 4

If you have such strict time limitation for retrospective, then lean coffee format is that you need (by my opinion, of course):

1) Select a theme (optional) [note: possible improvements for current process, for example]

2) Everyone writes their name on a sticky and keeps it in front of them. (Again, it’s optional, but name cards are very appreciated if not everyone knows eachother.) [note: no need for your team, of course]

3) Each person writes topics onto notecards (one topic per card). No limit to the number of topics per participant. (Pro-tip: keep the words per card to a minimum for readability.) [note: In your case each person should write a one possible improvement for current process.]

4) Set up a personal kanban board using three sticky notes, one for each column: To Do, Doing, Done (or To Discuss, Discussing, Discussed) from left to right. (Pro-tip: add a fourth column (“Actions”) to collect action items as they come up.)

5) Spend a few minutes (2-5) introducing each topic. Every author should share a sentence or two describing the idea they wrote on a given card. This adds a bit more detail and insight.

6) Vote. Each participant is given two votes (or three, depending on the size of your group). Simple dot-voting is quick and effective. Note that you may cast all your votes on one topic or spread them across multiple cards.

7) Prioritize the cards based on the voting results. Rank the more popular topics higher in the backlog (the “To Do” column).

8) Now that you have a democratic agenda, move the top item into the middle (“Doing”) column.

9) Set the timer (typically on a smartphone) for five minutes — or whatever length the group determines is reasonable. (Maybe eight is a better length; it depends on your group size & preferences.) This is the initial timebox for discussion.

10) When the time limit is reached, hold a simple roman vote (thumbs up, sideways or thumbs down) to see if there’s interest in continuing the discussion. If so, set the timer for a shorter duration (eg. three minutes) and continue discussing. You can repeat this step as many times as necessary until the group loses interest in the topic.

11) When the topic runs out of gas, move its card to the right (“Done”) column. Bring the next highest card over from “To Do” into “Doing” and repeat the process.

12) Optionally, at the end of the session, go around and elicit key take-aways and/or action items from the group. This is usually important if you’re using the meeting to drive decisions or create work. Taking a photo of the board or any artifacts (mind maps, etc.) is also handy.

Of course, even in this short format 20 minutes is not enough to take coordinated decision how to improve working process in your team and make a plan how to implement these improves. But in any case you will detect a most popular suggestion for process improvements (by common opinion) and you will have time to discuss some of them. It is better than nothing.

Answer 5

Wow, that's a tough one. Given how things went investing an hour to do an in depth analysis what has happened and come up up with the vital few actions would be my first suggestion, but I understand the risk of the team hating Scrum even more so that won't work in this situation.

A possible, short exercise would be to do the perfection game. It's a short and focused exercise, where team members compliment each other on good stuff and suggest further improvement. Although it can be challenging to do this one when team mood is down.

Another possible exercise is to do a start-stop-continue retrospective (a smaller version of the starfish exercise from our book Getting Value out of Agile Retrospectives). You only focus on 3 instead of 5 things, which makes it shorter.

Note that facilitating such a short intensive retrospective puts a high demand on the facilitator to keep the team focused and have everybody involved. It's doable, but not easy. Success!