Retrospectives

Last Friday, I had a chance to facilitate the retrospective of the Scrum team I am part of.  We have done retrospectives in the past, yes, but I would say that our understanding and practice is fairly shallow, and will need more time and reflection in order to mature.  This retrospective aimed to start doing just that.  Here are some of my thoughts from the retrospective. 

Leveling

Before we started, we had a leveling exercise to determine how open the team is in discussing things within itself.  This is very important as it sets everyone’s expectations on the retrospective and allows everyone to act accordingly during the discussions.

Each team member wrote anonymously on a piece of paper a number ranging from 1 to 5, with 5 being the most comfortable.  These are then averaged in front of the team and the outcome is the team’s comfort level.  This is then revisited at the end of the retrospective if the discussions did reflect the level.  We scored a 4, which was quite high in my opinion, but was actually reflective of our discussions and thus was pretty accurate and is a good thing as the team is fairly comfortable with each other :).

Retrospective itself

I would group the retrospective into three main parts: revisiting the sprint, discussion of relevant points, and coming op with action plans.  We revisit to gather information so we have something to talk about and thus act upon.  The common way is to have a timeline where everyone would post events they feel are important.  My CSM training suggested other possible approaches such as the team drawing a picture of the sprint (shown in the image above), or an emotion graph to indicate how happy the team was each day in the sprint.  We had a combination of the three and below is the picture that we came up with.

Admittedly I think we had more discussions with the timeline than the picture but the latter did give us an idea on what the team felt the sprint was like.

We built the timeline as a team with each team member posting what they felt was relevant on each day.  No group discussions yet at this point as we want to get everyone’s perspective before we stop and integrate.  As an added twist, we put smileys on each day to signify how they felt.  Smileys were either happy :-), not happy :-(, or no reaction :-|.  We did this on a whiteboard, but I think it would have been better on something that we can easily archive so we can revisit it in the future.

We then went through the timeline and then everyone wrote what they felt was remarkable from it and this served as our discussion points.  Another approach is to ask the team to mark events in the timeline that they found relevant and then discussing them afterwards.  A valuable addition to the timeline would be a burn down chart, as the slope changes give a summary of the team’s performance each day.  Unfortunately we didn’t have burn down charts in this sprint so we didn’t have access to this info.  We did start on one for our current sprint so we have something to use in our next the retrospective.

We spent most of our time in the discussions and came up with 3 “things to keep” and 3 “things to improve” for the next sprint.  One of the things that we should have done during the retrospective was to discussed how we can actually say we improved on these 3 items in the next sprint, as this sets everyone’s expectations on what needs to be done.  We defined these during our sprint planning the Monday after the retrospective.

End with the retrospective

It was pointed out that this sprint was the best one yet (yehey!).  We were able to end it will all tasks done.  We accomplished this by not adding stories into the sprint as well as cutting items from the sprint when we felt we couldn’t finish them (a burn down chart would have really helped here).  I don’t think people would have wanted to end the sprint and then immediately start on the next one.  It would be better to drink to the success of the sprint, or drown it if it wasn’t, which merits drinking as well :)

The common scenario is retrospectives happened and is then immediately followed by planning.  I think this happens because of the following:

1. Product Owner availability to do a sprint review.  Either the review was moved to another day, or was not done at all.  Unfortunately, we are the latter simply because we haven’t figured out how to do this in an offshore context with a fairly large time differential.  Sprint review and retrospective should happen in the last day, and we need to get everyone’s commitment on this.  This also means we took the entire day for the retrospective, which isn’t good as well as we didn’t time box properly.
2. 2 week sprints.  Sprint reviews should be done in 4 hours and retrospectives in 3 hours, but this is for 4 week sprints and for 2 week sprints we cut this into two.  This leaves about half a day free to do other things, which leads us to point 3:
3. Maximize time.  Why not have a planning meeting?  My thoughts is that it may be possible to either just stick to the 4 hour review and 3 hour retrospective, or use the extra time for training or team activities but not planning.

Each point is valid of course, so I’m not really certain on how to do this.  Time to bring it up to the team then :).

We weren’t able to plan our post sprint event but most of the team were able to head out to Charlie’s burgers for carwash and to try their burgers.  Check this out:

More pictures of the retrospective and Charlie’s burgers at my Flickr site.