My First Retro

Introduction

A few days ago the opportunity came up for me to run a sprint retrospective for our sprint team. So I took the chance to try my hand at doing something a bit different.

To give a quick bit of background to our sprint team. We have been trying to adopt agile practices for a while now but for one reason and another we have been quite slow in adoption of all the sprint practices we want to use. As such even though we have been "using agile" for over a year now, we have only had one sprint retro prior to the one I volunteered to run.

Before I hosted the retro I read up (probably reading the same articles that everyone else reads after googling "sprint retrospective") and got the usual things about you cover "what we should start doing", "what we should stop doing" and "what we should continue doing". Rather than this being a rehash of these articles I wanted to talk about something different - the actual practicalities of hosting a retro.

My Retro Plan

First, the running order I came up with beforehand for the retro (how I envisaged it going):

• Review previous retro: see the status of the actions from the previous (our first) retro. We use a page in Confluence dedicated to each retro, listing the issues raised and actions to be taken and keeping a log of action updates.
• Review incomplete actions from the sprint: in the Confluence document that I was going to write up this retro in I had already put a list of the incomplete sprint items in, the stage they were at (backlog, dev, testing etc.), who they were currently assigned to and had left a space to allow the assignee to make a comment about why the sprint item had not been completed. I showed this to the team and asked them to complete the reasons why they were incomplete later in their own time. This way we could hopefully identify recurring issues as to why sprint items were not being completed.
• Mood: everyone to write down one word that describes the mood of the sprint on a post-it note, put it on the whiteboard and discuss each.
• "What should we start/stop/continue doing": go through each one (start/stop/continue) in turn, each member of the team writing their contribution on a post-it note, put it on the whiteboard and going through each different item (some items maybe similar, so group together) and discuss.
• Voting: dot voting - each member of the team has 3 votes and can vote for any 3 items (in any of the start/stop/continue categories). Voting is done by putting a dot on the post-it note. Post-it notes with the most dots will be the items that are actioned.
• Actions: discuss the highest voted items to help determine actions later.
• Sprint star: everyone (if they want) to write down on a post-it note one or more people that they want to acknowledge as "star of the sprint" and put on the whiteboard, (me to) read through all the stars acknowledged so everyone can hear. 
• (Post-meeting): write up above, decide actions, follow up actions.

So, that was the plan. But having ran the retro I discovered there were a couple of issues that I didn't anticipate.

Issue 1: Timing

I had an hour to run the retro in and it became very apparent during the retro that I wanted to do too much in the time.

The step that took the most time was discussing each item that went onto the whiteboard individually. In our team we have a lot of out-spoken members. This isn't a bad thing in any way, in fact its good that people are passionate, have good ideas and share their opinions. But it did mean that there was quite lengthy discussions for most of the items that went up on the board. It took us about 40 minutes to get through the "what should we start doing" items. Clearly, at that rate, we wouldn't be able to get through everything that I wanted in the time we had.

Solving Issue 1: Timing

So, a different way of discussing the items is needed. To help decide how we should change the format of the retro, to make the discussion more worthwhile I thought about what the point of the discussion is. I'm not saying that there shouldn't be any discussion, but in a retro where lots of people what to give their input, there needs to be a more focused way of having the discussion. From the limited experience of retros in our team it seems that the wider discussion of issues should be done to help identify 1) the root cause of an issue and 2) possible solutions to the issue. This helped me identify what the purpose of the discussion should be - it should be to help shape the actions that we are going to carry out to solve the issues the team has. 

A colleague also helped with a solution to this problem. They suggested that each participant should explain their post-it note with 2 or sentences (if the post-it note is not self explanatory) and then since we are going to action the most important issues, to help reduce the time in discussion, we should allow open discussion for only the highest voted issues. 

Another time saving idea I had was to get team members to write down their post-it notes before the retro meeting. So future meeting requests (booking in the room and time for the retro meeting) could include a statement asking participants to think about the mood/start/stop/continue/star items beforehand and writing them down on post-it notes. This prompt also means that participants could write down their issues during the sprint and are less likely to forget them come retro time. If participants can't think of anything during the sprint then that's fine, they can still come up with them during the sprint. 

In fact one of the things that I noticed running the retro, as I did, is that the "mood" section of the retro can be very useful to help participants to think of what items wot write for the start/stop/continue sections of the retro. That is, it helps them to start thinking about the sprint we just had and sets the scene for the retro.

Issue 2: General Issues

During the retro some participants also raised what I would describe as very general issues. When it came to deciding actions later (I did this after the retro) this made it difficult for a few of the issues as they were quite general and so hard to define specific actions to address them.

For example, a general issue could be "stop blindly following processes". A good idea, but hard to write an action to solve.

Solving Issue 2: General Issues

I think the proposed solution for the timing issue would go some way to help with this issue. If there are any general issues that are highly voted the proposed format would provide more time for the discussion of these issues. 

I also think, however, there is more that I could have done as the person running the retro. On reflection of what I did in the retro as the host, I think that it was my responsibility to recognise that general issues were raised and then carry out more in-depth questioning with regards to these issues. For example, asking for specific examples related to the general issues so that something could be easily actioned as a result of the retro. Trying to resolve a very general problem ("stop blindly following processes") can be quite hard but having specific examples of a problem ("stop turning the servers off at night just because we've been told to turn our computers off at night to save on electricity costs") gives you something that can be easily remedied in a tangible way. If other examples of the general issue arise later on then these can be treated in the same way, until (hopefully) all instances of the issue have been resolved, thus resolving the general issue.

Issue 3: Not Following Through with Actions

This wasn't necessarily an issue with this retro but something I noticed from our first retro. We decided our important issues, actions were decided upon, but not all actions were followed through. This wasn't any single persons fault. But I think it happened because no ownership of the actions was taken. This is something I wanted to try and avoid with this retro, I wanted to make sure issues we had raised as important were given the time they deserved to be resolved.

Solving Issue 3: Not Following Through with Actions

What I did to try and alleviate this issue was to assign actions to individuals. A few of the actions were things that I could do, so I assigned them to me. But other actions required involvement from higher-up (I could propose actions but ultimately it required them to drive the change, or suggest an alternative action). I assigned actions within the Confluence document I used to record everything for the retro (this has the start/stop/continue doing and the list of actions) by tagging the appropriate people against the action. I also followed up each "assignment" with an email to the appropriate person explaining the problem and the action. Finally, I had a meeting with all the team's line managers (no managers were present during the retro) to discuss the issues raised in the retro and what I now needed help from them for.

Hopefully this assignment and follow up will make the issues more visible to the people who need to follow up on them and they will end up actioning the issue and resolving it for the team.

Also, any actions decided upon should be SMART:

• S = simple
• M = measurable
• A = achievable
• R = realistic
• T = timely (they can be done in a specific time frame)

This should help with the completion of any actions.

My Retro Plan for Next Time

With all these points considered, the next time I run a retro I will use the following plan.

Pre-retro:

• Ask participants to think about and write up post-it notes for mood, start doing, stop doing, continue doing, star (this shouldn't be a hard rule as team members may think of things during the retro) before the retro - send out prompt about this in meeting request

Retro:

• Review previous retro: update on progress of actions from previous retro
• Review this sprint: work complete, highlight any issues not complete, ask members to fill in reason why not complete later
• Mood: put up mood post-it notes on whiteboard, arrange in a spectrum from "bad" to "good" on the board. Person hosting the retro to read them all out then pick out one negative one and one positive one to discuss.
• "What should we start/stop/continue doing?": (again, do this for one before moving onto the next) team to put their post-it notes on the whiteboard, then team member running the retro reads each one in turn and if not self-explanatory (or if the team member who wrote it wants to) they can explain it with a max of 2 to 3 sentences, no discussion.
• Voting: dot voting - each member of the team has 3 votes and can vote for any 3 items (in any columns). Voting is done by putting a dot on the post-it note. Post-it notes with the most dots will be the items that are actioned.
• Discussion: as a team, discuss the highest voted items from the preivous step. This should help shape what actions need to be taken for the most important issues.
• Sprint star: everyone (if they want) to write down on a post-it note one or more people that they want to acknowledge as "star of the sprint"  

Post-retro:

• Write up issues from retro
• Decide actions
• Assign actions to appropriate people:
• Tag in Confluence
• Send email explaining problem and (proposed) action in more detail
• Have meeting with line managers to follow up on issues raised in retro

Take Away Points (TL;DR)

• Get participants to write down their mood, start, stop, continue doing, star items beforehand.
• Go through each item, allowing the author only 2 or 3 sentences to explain what they meant (no open discussion on all issues).
• Vote, then discuss the most important items in more detail.
• Mood can be used to help people think about what items to write in start, stop if they were previously struggling.
• Don't allow very generalised issues - need to be specific so that they can actually be actioned. Get people to expand on general items via detailed questioning.
• Assign actions to people.

The End