InnerWorks Logo
Return to main siteReturn to main site

Running Agile Retrospectives


10 May 2017 • 8 min read

Cogworks favourite Scrum meeting - the retrospective.

Innerworks is coming soon...

This blog was originally published on our previous Cogworks blog page. The Cogworks Blog is in the process of evolving into Innerworks, our new community-driven tech blog. With Innerworks, we aim to provide a space for collaboration, knowledge-sharing, and connection within the wider tech community. Watch this space for Innerworks updates, but don't worry - you'll still be able to access content from the original Cogworks Blog if you want. 

In this blog, we're talking about Cogworks' favourite Scrum meeting - the retrospective.

Following the Scrum guide, “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint”. In our Agile world, inspect and adapt is probably one of the most common phrases. The retrospective is about checking what works well, what can be improved and how to accomplish changes. Let me show you how you can use retrospectives to improve and hone your team’s output.


It’s worth starting a retrospective with a little warm-up. Some of the team members may be shy, others not in the mood or just tired. There are many ways of waking up your team and getting everyone ready to work:

  • Candy love - This activity helps team members to get to know each other better, open themselves up and find out interesting facts about one another. All you need is a packet of Skittles (my favourite!) or if you’re a chocolate person - M&Ms.
  • Thank you - This activity starts the retrospective on a positive note and is all about appreciating each other and thanking people for amazing things they’ve done. You can not only use certificates but also flowers, candies or beers - it’s up to you and your team.
  • Defining Nirvana - This is a team-building game to help people find the common ground by defining their Nirvana together.

Of course, you can use other activities, just make sure that they won’t take more than 10 minutes - 15% of the retrospective time.

Flowchart showing which retrospective is right for your team

The Retrospective Meeting - a powerful tool

Every time I organise a retrospective for my team, I adjust it to the participants and the project itself. I’ve learnt that the output depends on the maturity of the team, the project and on the retrospective method. At different stages, we face different problems and we should modify retrospectives to make them as effective as possible.

You may wonder how to define a mature team, I like Brian Garavaglia’s description: “As teams start to mature, one is able to witness a greater refinement of the roles that each member of the team holds. Team members come to understand their roles that they play, how their roles interface with other team members, and how the interdependency of each and every member is critical for a fully working and productive team”. Of course, the maturity of the team is subjective and you’re the best one to judge if you are in the mature team or not. So maturity here is more akin to how experienced the team is, both from within the project perspective and their experiences with each other and the agile method.

I’d like to share with you my observations and give you a simple guide to what you can do with your next meeting. Below, I have also included links to the proposed ways.

Retrospective propositions for more mature teams:

A serious (play) retrospective (1. proposition) and (2. proposition) - How about some Lego! Creativity in its purest form - especially when your team members know each other well, have been through many retrospectives and are in need of some fun. This method is also great for workshops, read our Scrum Lego blog to find out more.

Fishbone diagram - known also as the Ishikawa diagram, focuses on cause & effect, an important tool which can help to find the cause of problems. It’s essential to make the team understand what the tool is and why they’re using it. I worked with a team who had a lot of problems on a particular project. They believed that the issues lied in the process, but no one wanted to listen to them. The Product Owner decided to run a workshop using the Ishikawa diagram without explaining its purpose to the team and without actually listening to participants. The team spent half a day “creating a dead fish” (the diagram looked like a fishbone), not understanding what the Product Owner wanted to achieve. In their mind, the process and constant meetings, instead of the actual work, were the problem. However, the company didn’t want to accept this fact. The team still refers to it as ‘possibly the most useless retrospective ever’, and I believe that a proper introduction to this tool and a good meeting leader could have helped them.

Glad / Sad / Mad - what makes you glad, what makes you sad and what frustrates you? I find this method useful for young projects where teams are still looking to find their way through the inevitable initial project setup challenges. Just let the team release their emotions!

Liked / Learnt / Lacked - it’s powerful if your team learns a lot - I can assure you that the list of lessons learnt will be long and the team morale and positive attitude will increase.

Outcome expectations - this method works pretty well with projects that are stable and carried out by a confident team. It helps get all team members’ needs noticed and discussed.

Sailboat - visualisation is important in this game. The team imagines itself as a boat with anchors that are slowing it down and a wind that helps it go forward.

Start / Stop / Continue - the most basic and common format for a retrospective. It’s very useful, especially at the beginning of a project when the team needs to solve blockers (and as we all know, there are a lot of them at the start of any project). It’s important not to force anyone to look for problems where they don’t exist - I have experience of a team that has been forced to always find 2 negatives for months on end - this has created a range of non-problems like ‘this new coffee is not tasty’, ‘walls are blue’, or ‘it’s not sunny outside today’.

Top 5 - it’s a good method if you can easily identify the issues. It’s focused on defining actions and brainstorming ways to help solve problems.

Tree - it’s a type of retrospective that I created for The Cogworks company retrospective. My manager challenged me to find a way of showing people how many things we’ve accomplished in the last quarter. We did have a large, complex project that involved most of the company and we were in need of a morale boost. I drew a tree trunk and branches and asked everyone to write all the positives and all achievements from the last 3 months on post-it notes. These then became tree’s leaves. It was amazing to watch how bare branches transformed into a lush tree! The issues that still needed to be resolved were placed on the trunk (their solution needed to grow) but we didn’t stick many there. It was great fun and the atmosphere in the room was really positive after this exercise.

Retrospective propositions for Less Mature teams:

Appreciative retrospective - a great way to build a positive mood within a team. Starting with appreciating team members, through the team’s successes in the project.

Each one meets all - a good idea for a new team who just started working together. First impressions are important, right? A little bit of team-building at the beginning of the project is always a good thing!

Pillars of Agile Spiderweb - I found this method useful when teams maybe aren’t working so well together. The exercise helps understand the skills the team has and how strong it is together.

Strengths-Based Retrospective - focuses on the strengths that the team has, showing how they’re leading to success and creates a discussion about how to empower those strengths even more.

Retrospective proposition for everyone:

Scrum values - this exercise will work whatever the team’s maturity. It’s worth repeating this exercise on a regular basis, i.e. quarterly or annually. This helps the team evaluate the progress the team has made. It also helps to understand the values better.

After the Retrospection - A lesson learnt or a lesson experienced?

Once you’ve completed a retrospection, you need to work on your next steps. If things don’t change positively after a retrospection, a good team will soon let you know. It is imperative to follow-up on the agreed actions from the retrospection meeting, to ensure that what you experienced actually positively informs what the team do next.

I hope that the examples I have given will help you discover a whole new world of Retrospective meetings.

Hungry for more Agile knowledge?

I have a couple of recommendations for you to take a look at.

  • This short video, Scrum training series created by Michael James, will give you a great introduction.
  • A lot of knowledge can be gained from Helen Meek’s blog; she is a huge retrospective advocate and definitely a very creative person who loves to share ideas.
  • And as always, I strongly recommend you check out the Mountain Goat Software blog written by Mike Cohn which is full of really good Agile knowledge.
  • If you’d like to discover even more ways of running retrospectives, you should check the Agile Retrospective Wiki.

Share your experience!

If you’re organising or participating in retrospectives, you must have your own favourite method and definitely have interesting thoughts that will inspire others. Feel free to share your adventures on TwitterLinkedIn or Facebook. What made your retrospective awesome and what failed? Maybe you retrospected your retrospectives? Tell me about your experience and let’s discuss!

Community tech aid

Innerworks and Cogworks are proud to partner with Community TechAid who aim to enable sustainable access to technology and skills needed to ensure digital inclusion for all. Any support you can give is hugely appreciated.