Blog

Retrospectives 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!