Changing Our Retrospectives

May 7, 2010

I’ve been thinking a lot about retrospectives lately both because our team has been struggling with them being ineffective/wasteful and because retrospectives were the subject of conversation at the last DC/NOVA Scrum Users Group meetup.

Our team has been tweaking and experimenting with various modifications to our process but one thing that we’ve left untouched for a year now is our retrospectives.  Every sprint, we ask “What went well?” “What went badly?” and “What can we improve?”  Rarely, though, do we follow through on those items under “What can we improve?”  We’ve tried forcing ourselves to make these items concrete, posting them near our board, bringing them up in the standup meeting, etc. but to no avail.

We’re now experimenting with changing the meeting itself to better foster improvement.  First: we’re going into the meeting with an agenda rather than having it be a free form discussion.  Generally, when we treat it as free form, memories are dull and it is difficult to start a conversation.  We’re hoping that a prepared agenda (to which anyone can contribute) will help grease the skids, so to speak.

Secondly, the “What can we improve?” section will now be more explicitly a “What experiments should we run?” discussion – things like “should we be using Selenium instead of our current solution?” or “what if we only tasked out half of the stories at the beginning of the sprint and left the second half until the middle of the sprint?”

The “What went well?” and “What went badly?” topics, then, can focus not only on unexpected things that came up but also on the results of these process, tooling, and workflow experiments that we’re running.

Hopefully, this will prove to be a true PDCA loop and really drive improvement.  After all, that what retrospectives are supposed to do.

Share

7 Responses so far | Have Your Say!

  1. Nimat
    May 18th, 2010 at 8:20 am #

    Ken,

    From my experience, it is always helpful to have a specific agenda for retrospects. One must have topic in my retrospect agenda is to talk about 5 minutes the improvement task team decided to implement last sprint. Did they experience the expected outcome, why or why not (5 why questions)? and change it as necessary.

    Also, a visual time line of events (that happened during the sprint) is helpful for the developers because it helps them to answer the specific questions during retrospect.

    Good Luck.
    Nimat

  2. Ilja Preuß
    May 18th, 2010 at 8:58 am #

    If you go into the meeting with a prepared agenda, it might be a good meeting, but it’s not a retrospective. The purpose of a retrospective is to get a common understanding of what happened, and to generate new insights. It is not primary a problem solving meeting.

    Sounds to me like you could benefit from incorporating some exercises on gathering data and generating insights into your retrospective. I highly recommend the book “Agile Retrospectives” as a great resource on exercises and retrospective design.

  3. Ken Furlong
    May 18th, 2010 at 9:25 am #

    Ilja, thanks for the comment. I’m curious about the idea that a retrospective, because it is supposed to reach a common understanding of what happened, cannot have a prepared agenda. I don’t see a necessary connection between reaching new insights and spontaneity. For instance, we ran a retrospective yesterday where one person had asked that we talk about a potential “What went badly,” namely, whether or not we “slowed down” towards the end of our sprint. We all discussed it and eventually reached a consensus that we had not and that there was no problem. We didn’t go into the meeting with the idea that this was definitely a problem and we needed a solution. Is this in line with what you’re envisioning?

  4. Paul Boos
    May 18th, 2010 at 9:08 am #

    I’ll start with the question; do you use an Agenda different than the 3 questions you posted above? (I don’t want to leap that you do or don’t have one…) That could be a first start, but even if you do – I would move to the format that Esther Derby and Diana Larsen recommend from “Agile Retrospectives”. The primary reason is it will objectively guide you to an important, but easily chewable issue to fix and it will help actually identify the action(s) to be taken. One exercise even invites those to identify who has energy to work the issue, thus finding people who will commit to getting it done.

  5. Ken Furlong
    May 18th, 2010 at 9:21 am #

    Yes, the agenda is based on those three questions, although the “What can we improve” section varies in that sometimes items directly address “What went badly” items and sometimes they are just general improvement ideas.

  6. Maurice le Rutte
    May 19th, 2010 at 3:07 am #

    It is applaudable that you at least notice that the follow up of the retrospective’s outcome is insufficient. I’ve seen teams that do a retrospective (or at least spend some of the company’s time under that name) who don’t even see that they are not using the outcome.

    I’m not sure how detailed your agenda is, but dividing the retrospective (≠ meeting) into sections and doing timekeeping is a good idea. Otherwise you’ll end up with retrospections where you don’t have time to think about ‘what shall we do’.

    You did a lot to make yourself actually do the items, but still you didn’t. Have you reflected on the items you created? If you didn’t do them they were not the right steps to do. Maybe they were to ambitious, in which case you should look for a smaller step. Maybe they were politically or cultural correct but not what people really wanted, in which case you should work on safety for freedom of speach. Maybe…

    I’d expect that if you find items that you really care about you’ll actually do them and anybody in the team will make sure that they happen.

    For those who are able read Dutch can also view my slideshare on retrospectives on my blog.

  7. Steve
    May 28th, 2010 at 5:19 am #

    Ken,

    From my experience, it is always helpful to have a specific agenda for retrospects. One must have topic in my retrospect agenda is to talk about 5 minutes the improvement task team decided to implement last sprint. Did they experience the expected outcome, why or why not (5 why questions)? and change it as necessary.

    Also, a visual time line of events (that happened during the sprint) is helpful for the developers because it helps them to answer the specific questions during retrospect.

    Good Luck.
    Nimat