Retrospective evolution

I get the feeling that after 5 or 6 sprints, retrospectives tend to lose some of their power.
For instance, let’s look at the number of actions the team came up with during the course of a project.

Numbers fluctuate a lot during the first 5 sprints after which they tend to flatten out. When I think about it, this is in most cases aligned with my feeling about retrospectives of a project. In the first weeks and months, they tend to create a lot of valuable feedback, are highly energized with creative discussions. But this generally doesn’t last for the entire project duration.

You might say “Were done, the team has improved all there is to improve”, but I don’t believe that’s true. Not after 6 sprints! There must be lots of other areas in which we can do better. Maybe only the obvious improvements have been done.

I believe we enter a second cycle of continuous improvement. One in which it may not longer be appropriate to hold a retrospective after a sprint. Maybe we should work on our culture of continuous improvement, so we always keep an eye open for possible improvements. It requires an atmosphere that embraces change and supports continuous learning.

It feels like a logical next step to me. Starting the project with a fixed moment to reflect and adapt, until the team embraces the mindset of continuous improvement. Then switch to a looser process, where reflection is nurtured instead of forced.

Anyone got some experience with this?

About Nick Oostvogels

Hi, I'm an independent management consultant. My biggest strengths are located in the fields of teamwork, motivation, leadership and continuous improvement. In the IT industry you find a lot of these values in the agile movement, in which I often act as a project leader, product owner or coach. My interests go a lot further, into other industries where we find these values in lean production. Besides that, I try to broaden my horizon as much as possible, always looking for better ways of doing business.


  1. Are you changing your retrospective design format (or activities) to help the team think differently about their work? Are you choosing a different area of the team’s methods, interactions, practices to focus on each time? Have you tried looking at patterns that occur across iterations/sprints as well as during a single iteration?

    Some mature teams get to a place eventually where they don’t do retrospectives after every iteration. However, I agree with you, it’s unlikely your team has arrived at “nothing to improve” after only 6 sprints. Try switching up how you run your retrospective or who leads them, before throwing the retros out.

    • noostvog

      Diana, thanks for the reply.
      So far I never threw the retrospectives out.
      I was wondering if others have the same feeling I have, and if so, do they change the retrospective format?
      Like you suggested, maybe looking at patterns across sprints? Focusing on single problem area’s, instead of trying to review the previous iteration as a whole?
      If the classic search for improvements doesn’t cut it anymore, what kind of facilitation would be appropriate to keep the team improving as in the first sprints?

      • When I’m facilitating retrospectives, I nowadays try to never use the exactly same format twice in a row.

        I’m not sure what you mean by “classic search for improvements”. I’ve seen different changes do the trick:

        – do an appreciative retrospective
        – focus on a theme
        – invite different people – include the PO, the manager, …
        – change the way you decide on what topic to focus: the typical fallback seems to be importance, but if energy is low, “what gives us energy”, “what can be done easily” or “what gives us quick success” can work better
        – change the location – do it in a nice conference room, in a cafe, in the meadow
        – design it more like a game (for example, use the “Like to Like” exercise from “Agile Retrospectives”)

        If you discuss this with your team, you can probably come up with your own idea…

      • noostvog

        Ilja, thanks for the nice replies.
        When I talk about the classic search for improvements, I mean the exercises most people are familiar with:
        What went good, what could we do better?
        I feel that the focus here lies on searching for as much improvements as we can find. Same for other exercises such as the starfish.
        As you mentioned, it is important to change the format of the retrospectives, change focus, other exercises, other participants.
        I like your tip to focus on “what gives us energy” when energy is low.
        May I conclude that you agree that the start of a project focuses more on the search for improvements, while after some time single focus points are chosen per retrospective?
        As Diana mentioned, experienced teams may no longer need this fixed timeframe of the retrospective to do this. Do they evolve more towards a lean approach?

  2. Pingback: Tweets that mention Retrospective evolution « Nick Oostvogels’s Weblog --

  3. Frankly, I don’t think that your graph is best explained by retrospectives losing their effectiveness after a number of sprints.

    – the number of actions is a bad indicator for effectiveness of a retrospective. In fact, I’d argue that it’s better to focus on two to three significant actions, and to really follow up on them, than having a whole dozen of actions

    – actions are not the only significant outcome of a retrospective. Another one is telling stories of what happened and thereby getting a common perspective on the project. I’ve had some very successful retrospectives where there wasn’t decided on any actions at all

    – if retrospectives really become stale, that can have a whole number of reasons: there isn’t enough diversity in the exercises, people feel that they can’t talk about the really important topics, they feel that the retrospectives don’t have the expected impact, etc. pp.

    Do you include any reflection on the retrospective itself in the closing, such as a Return On Time Invested or Plus/Delta?

  4. Pat

    Hi Nick,

    Thanks for pointing this discussion out to me. I found it a great read. I agree with Ilja in that I don’t think effectiveness of a retrospective is best measured by number of actions (easy to measure yes but not the only thing).

    If you’re looking at ways of refreshing your retrospectives I, too, like to vary the retrospective (different exercises, format, location, the questions, the facilitator).

    Do a retrospective on the retrospective as well.

    I’d like to find that team members feel like continual improvement (more lean) is part of what they should do everyday. At this point, I think retrospectives are still important, but may require less frequency.

  5. I don’t think that’s what Diana actually said – I read it more like “every other iteration might be enough”. 😉

    Anyway, for me retrospectives also have the very important purpose of team-building due to the sharing of stories, better mutual understanding and setting of expectations. The “search for improvements” (I prefer the Scrum phrase “inspect and adapt”) might even be secondary, though still important.

    The difference between early and later retrospective seems to be more that at the beginning, everyone still has a “beginner’s mind”, so things to change are rather obvious. Once the team gets used to the way “things just work here”, it simply needs some deeper digging to find the issues that are holding back the team. Setting focus points and using more elaborate exercises are simply tools for doing that.

    I wrote a little bit about a similar topic here:

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: