How I Started with Agile Retrospectives

flipchart retrospectiveRetrospectives are becoming more and more used, now organizations are adopting agile. Many organizations start doing them because they are part of Scrum; it is one of the scrum practices that are implemented, next to planning games, stand-ups, and sprint reviews. I started with retrospectives because I wanted to help a project to improve along the way, so that we could reap the benefits already during the project, and benefit ourselves. It’s the same technique, but for a different reason, and introduced in a different way.

I started doing agile retrospectives at the beginning of the 21th century, in an organization who wasn’t working agile at that time (looking back my guess is that almost nobody had heard of agile back then). Projects used the Rational Unified Process to develop their software in increments. PROPS was used for project management, which described that you made a final report at the end of the project which included some lessons learned. Most projects organized a session at the end to discuss and evaluate how things had been done and reported this to the management, but we wanted more.

Having seen Norm Kerth at the 2001 Software Management conference in San Diego presenting about agile retrospectives as a tool for a learning organization, I decided to introduce them into the project that I was working in.

Doing retrospectives, without telling it

My idea was to do evaluations every 3-4 weeks when the team finished an increment instead of only at the end of the project. To come up with improvements and implement actions I applied an agile mindset to the retrospective techniques that were described by Norm Kerth in Project Retrospectives (back then this was the only book that I could find on retrospectives).

I never used the word retrospective (it was all in “stealth” mode), prime directives, or any other term used with retrospectives. But I made sure that there was a culture where people felt safe to speak up, and didn’t blame team members or the organization.

Initially, I used the 4 key questions (see which questions do you ask in retrospectives) to get the team into a learning mood, later I started varying questions. And I assured that the team looked for actions that they could do in the next increment, instead of things that “the organization” needed to do, empowering the team members. Since we did a retrospective every increment, we could easily follow up on the actions and track them to completion. It all made sense!

Some years later the company started with a pilot project for agile and Scrum. When I did the first retrospectives with the new agile teams, I continued the way of working that the teams and I were familiar with, but now I could call it a retrospective. The reaction from the teams was: “we’ve been doing this for years, and seen it work, so let’s continue doing it and see if we can do it even better now we are becoming agile”. And we did :-).

Making retrospectives work for you

My opinion is that doing retrospectives is one of the success factors for using Scrum and getting benefits. Varying the way that you do them helps to keep getting business benefits out of retrospectives, I use a toolbox of retrospective techniques for that purpose.

You do not have to be working “fully agile” to do retrospectives, actually, retrospectives can help you to become agile and lean; you can even use Scrum with retrospectives to improve your processes.

My advice is to start with retrospectives for a good reason: To enable teams and the whole organization to improve continuously, and get quicker benefits from your actions!

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

This Post Has 2 Comments

  1. Sunil Mundra

    If a team is doing retrospective for the first time, I would keep tthe following in mind:
    1. Get a facilitator who does not belong to the team
    2. Do a safety check. Ask each person to write a number from 1 top 5, where 1 indicates they are not comfortable sharing their views and feeling with the group, and 5 indicates that they are very comfortable. Since just 1 number needs to be written, believe will feel confident that anonymity will be maintained in this. Share the results with the group. If the average is 2 or less, I may postpone the meeting or ask the Manager to stay away from the meeting
    3. Emphasize the fact that this is not a fault finding/finger pointing exercise, and that What is working well is as important as finding out what is not working well. The approach should be to look at both of these from a team perspective, rather than focus on specific individuals
    4. Ensure Action items are identified from the feedback received, and an owner is assigned to each item. For some items, the owner might be the entire team.

    1. BenLinders

      These 4 things you mention where indeed what made it a retrospective, and not a project evaluation!

      I facilitated the sessions, and assured that people felt safe. We looked for things that the team could do themselves, and had a follow up in every increment.

      At that time, it all made sense. And it still does 🙂

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.