How to improve retrospectives

11 Ways to Improve Your Retrospectives

Possibly the most important part of your Agile journey is your ability to inspect and adapt. This helps you to constantly iterate and improve your output, methods, processes, and product. A retrospective provides the opportunity to look back on the sprint you’ve just completed and make plans to improve in the future. Here are 11 ways to ensure your retrospectives are successful. 

Want to run better retros? Learn how in our online short course, Facilitating Retrospectives

What is a retrospective?

A retrospective is a meeting held for the purpose of reflecting on the product development or workflow process. The aim of a retrospective is to look closely at the processes and products produced during a sprint, discuss these as a team, and decide on a way forward together to drive constant improvement. 

A retrospective is also known as a Scrum retrospective, retrospective meeting, a sprint retrospective, or simply a retro. 

Why are retrospectives important?

When done correctly, retrospectives can be a catalyst for organisational change as well as team change. They can be a place to build and enable teams, or to help teams start their journey from the best possible place. Team retros can be a place for learning, problem solving, or having fun and motivating each other. This is why it is so crucial to get them right. 

Online Retrospective Facilitation Course

Common mistakes in retrospectives

Many retrospectives follow the same formula: the team is all gathered in a room around a small table. The Scrum Master throws some pens and some sticky notes on the table, and the team writes down what went well and what can be improved. They make lists and group the topics together. Often, half the people in the retro aren’t really engaged, and some are on their phones. Most of them would rather be coding.

While this makes sense on the surface level, when you look a little closer you often find the same strengths and weaknesses emerging every time. Actions aren’t always followed through effectively, resulting in a sort of Groundhog Day experience that can be very frustrating for all involved. 

If people stop engaging in the meeting and feel that their time is being wasted, then it probably is. If meetings aren’t adding value and actively driving change within the team and the organisation, they aren’t achieving what they set out to achieve, and they need to be stopped or changed.

How to make your retros successful

There are some simple changes you can introduce to vastly improve your retrospectives. Here are our 11 top tips to make your retros successful. 

Embrace the five stages of a successful retrospective

Diana Larsen and Esther Derby’s book Agile Retrospectives – Making Good Teams Great lays out five stages of a successful retro.

  1. Set the Stage: Understand where everyone is coming from today.
  2. Gather Data: Get the viewpoints of all members of the team so that you can create a shared picture of what is happening.
  3. Generate Insights: Unpack the data and analyse or look for the root causes.
  4. Decide what to do: Make sure the team decides what’s most important together.
  5. Close: Appreciate people’s time and get feedback on how to improve your retros in future. 

Your retrospectives won’t always need to include all five stages, but this is an excellent base-line and makes for a good starting point. 

Recommended for you: Take an online course on Facilitating Retrospectives

Tailor your retro to your team’s needs

A generic retro structure can be a good start, but if you want to make meaningful improvements you need to make sure you understand the specific needs of your team. The facilitator, coach, or Scrum Master should observe and pay attention during the sprint, project, or whatever cadence the team has. They should be looking closely at how the team works together and any difficulties they’re having. If you’re the Scrum Master, ask yourself:

  • What does the team need? 
  • Is there a specific issue that they are grappling with?  
  • Are they making their sprint goals? 
  • How is the level of trust? Have they lost trust in each other or is there a lack of trust between the team and the product owner? 
  • Are they a new team still finding their rhythm? 
  • How are the energy levels? 

With these answers in hand, you can start to put together a picture of what the team needs: maybe there are big trust gaps in the team that need to be addressed, or maybe they’re lacking resources. Maybe they have just had a hectic series of sprints, and they need to celebrate their wins and not change anything. The only way to find out is to be in tune with your team and the work they’re doing. 

Recommended training to boost your skills: Advanced Scrum Master certification

Plan well 

Once you have decided on what your team needs to focus on, you need a plan for your retrospective. Spend some time deciding how you are going to divide up the time spent in the retro: are you going to split it into the five phases? Do you need all five phases, or can you skip some? And finally, what are you going to do for each phase? 

Break people into smaller groups 

Groups of two or three are optimal in a retrospective.It makes it much easier to keep the energy high and keep people engaged. It is also much easier to get things done.

Encourage team members to contribute in their own way

Make sure you are encouraging everyone in the team to contribute in their own way. Many people are tempted to force people out of their comfort zones, such as making introverted employees take the lead on talking. While there is some merit to encouraging people to step out of their comfort zones, remember to play to everyone’s strengths. Someone who doesn’t like talking may prefer to do the writing, do some silent brainstorming in a small group, or get up and take notes on the board. These are valid ways of being engaged, and they bring the best out of people rather than putting them on the spot and causing anxiety. 

Have an outcome in mind

A common mistake in team retros is to approach it without a specific outcome in mind, to see what comes up. This lack of structure can be useful on occasion, to allow the team more freedom to explore their experiences. However, most of the time it can make things feel directionless and can get in the way of moving forward. Make sure that there is an outcome for the retrospective and provide support to the team in reaching that outcome. Be careful not to make the change for the team: you want to encourage self-organisation. 

Dig deep and find the root cause of problems

If you are only looking at the symptoms of a problem and not understanding the root cause, then you are missing a valuable opportunity for learning and improvement. You will also keep having to deal with the same or similar issues over and over again. This may also result in long lists of policies or agreements set up to change behaviour, but without meaningful change, because the root cause hasn’t been addressed. Analyse and dig beneath the surface, or you may just be wasting your time.

Make use of retrospective games and exercises

There are plenty of places to find great ideas for exercises to do during retrospectives. Diana Larsen and Esther Derby’s book Agile Retrospectives – Making Good Teams Great has a wealth of things to do and is an excellent starting point. There is also a website called Retr-O-Mat that has many ideas for games or exercises. While a game or exercise can be a great way to get creative juices flowing, break the ice, and relax the mood, be careful not to overload your teams with games. The most important thing is to pay attention to what your team needs, make sure your retro flows, and have an outcome in mind. 

Use SMART goals

Remember to not try to do everything at once. One or two key changes are usually more than enough. If a team tries to do everything, they often end up doing nothing. A good idea is to come up with an Action Plan and include a SMART goal. Smart goals are Specific, Measurable, Attainable, Realistic, and Timely. 

Get professionals involved

One of the best ways to transform your retrospectives into useful, successful events that the whole team finds valuable is to consult with professionals like the coaches, mentors and facilitators at agile42. Contact us to enquire about our services. We offer them remotely or in-person, and we can set you up for success so you can go forward confidently. 

Ask for regular feedback

The easy answer to this is to ask for feedback from the team. At the end of each retrospective, devise a way to get feedback on the retrospective itself and ideas for improvement. There’ll always be someone who will just request pizza, but you will be surprised at the great ideas that are offered if you open the door for honest feedback. As you are asking for continuous improvement from your teams, make sure that you are also looking to continuously improve yourself and your retrospectives.

Finally, remember, if you are having fun, chances are others are too. Sometimes we need to be serious and sometimes we just need to have fun.

Growing as a Scrum Master and Beyond

Last Wednesday, the 11th of November, we ran our webinar "Growing as a Scrum Master and Beyond"! This topic clearly resonated with many, as we set a new record number of participants. We spotted familiar names who have been following us over the years, and many new names we hope to see again. It makes us happy to see our webinar network growing! 

We had the great honour of welcoming two guests on this webinar, Jelena Vucinic and Bob Stomp, who joined our CSP-SM training this fall. Together with agile42 trainers & coaches, Giuseppe De Simone and Niels Verdonk, we hope they provided you with the content you were after. 

As the coaches mentioned early on in the webinar, being a Scrum Master in a company is much more than just attending a 2-day training to get certified. Whilst your role is to primarily coach the team, it is also to teach, give advice, be a mentor and role model of the Agile and Scrum values and principles. This is not always an easy task. The knowledge and skills you need as a Scrum Master will grow through education, perhaps some additional coaching and most of all the experience and support of other Scrum Masters in your organization and network. 

As Jelena mentioned during the webinar, a typical day for a Scrum Master is not only to facilitate Scrum meetings, however a multitude of other undertakings. You observe the team, prepare for meetings, follow-up action points from meetings, handle impediments, have 1-on-1 meetings with the team members and stakeholders when needed and think about new ways in which you can help your team.

The webinar attendees were particularly interested in the ways you can grow as a Scrum Master, for which there are various paths. You can of course take the training provided on the Scrum Master growth path as visualised in the diagram below. Each training goes deeper into the content of the Scrum Master, and you will gain valuable new skills and learnings to add to your toolbox. The below diagram shows the steps to become a CSP-SM: 


We recommended reading The Hitchhikers Guide to Agile Coaching and checking out the post on 5 books we believe every Scrum Master should read.

Other training we offer is the Advanced Team Coaching Course which we recommend for those who already have CSM certification. There is also the ICAgile Team Facilitation Certification to support you as a Scrum Master. Furthermore you could consider coaching from one of our Agile coaches, for example, to grow you or your team of Scrum Masters.

Many of you listening asked us about the whole CSP path, how to grow skills and mindset as well as next steps after CSP-SM certification, and we feel that depends on what skills you wish to deepen. Below you can see examples of next steps, and our Mentoring programme can assist you on these paths. Mentoring is a long term commitment both from your side and the Mentors side, and this is a great opportunity to meet like-minded people, and to grow and learn together. 

If you would like to explore next steps on your individual growth path and/or like to enquire about our Mentoring programme after the CSP-SM, please get in touch with us and we would be happy to help.

Our upcoming trainings can be found here - take the next step on your journey with us!

The recording is available online. Feel free to watch it again and share with your network. It is also available on YouTube.


Below you will find the slides, with some further content. Please also feel free to share the slides around.


Connect with us on social media, to stay updated with blogs, webinars, training and other events which support your learning journey :) 


Have a great weekend, and don't forget to check out post and upcoming webinars!

Scrum Master vs. Project Manager

Project Managers are the lubricant that makes projects run. According to the PMI, the role of the PM is the director of action, the key role responsible for delivery of the project. But how does that role change as agile practices are introduced, and a pool of resources manipulated by PMs becomes a swarm of dedicated agile teams? We’ve often struggled to explain the difference.

As agile coaches we are tempted to give the irresponsible response that agile teams “don’t need project management” or agile companies “don’t do projects”. While true, the answer is uninspired and unhelpful. If we really want to understand the change that agile brings to project delivery, surely we need a better response than the mantra of “no project managers”? This led us to consider a better metaphor for the role of project management vs. scrum masters (or coaches) in the success of product delivery. We chose that of the one-level traffic junction.

Many cities use traffic lights to battle congestion. Traffic flow through many major intersections is managed by a central authority – in the 20th century perhaps a staffed control center, nowadays computers with sophisticated sensors and adaptive algorithms. The trick here is to force half of the traffic to stand still while the other half moves. There is a bit of switching involved, but nearby junctions can be connected so that batches of cars can run on a “green wave” across several blocks.

The traffic circle (or roundabout as it’s known in the UK) represents a more distributed and devolved solution to the same problem. First invented in France as the carrefour à gyration, it requires more space than a cross junction but increases safety and throughput. In a traffic circle, there are no central directions to be followed. Instead drivers need to apply a number of rules to their own local position in the junction. People have the same visibility as everyone else and take responsibility for their own surroundings. When dozens of drivers pay attention and interact in this way, positive results emerge on the global level.

When people start understanding the system, synergy starts to appear between drivers. People come up with things like the zipper merge method, where cars from two lanes alternate into one lane. This works particularly well under congestion, reducing queues and increasing the perception of fairness among the drivers.

Similarly to how a PM is the central authority of a traffic light junction, the ScrumMaster can be seen as the “RoundaboutMaster”. The responsibilities of the role are, roughly, to teach and remind drivers about the rules, to help them improve the roundabout, and to straighten out any delays and deadlocks. The roundabouts pioneer in the UK, Frank Blackmore, would park himself in the middle of a roundabout and support bewildered drivers by shouting instructions through a megaphone. (This presumably makes him the first RoundaboutMaster ever.)

Initially the ScrumMaster would have to spend considerable thought on the physical and artificial constraints placed on the traffic. Luckily ready-made collections of practices — Scrum, XP or Kanban — exist for the drivers. As soon as these are in place — constraints and rules have been deployed — drivers can follow simple rules to make decisions for themselves, and we will find that certain behaviors emerge.

But we can’t choose any random collection of rules. For example, if we decide to give cars entering the roundabout the right of way — as was the case in the UK up to the 1960s — they are likely to block the route for drivers who want to go forward to another exit. And when a deadlock forms, the rule ensures that neighboring parts of the junction also get blocked. Conversely, if cars already in the roundabout are given the right of way — another concept introduced by Frank Blackmore — they can move out and free up space for new cars.

But does this devolved, distributed approach scale? We know that the PM approach scales hierarchically through the Project Management Office (PMO). But even if one Scrum team works fine, how do we manage dozens or hundreds of teams?

In 1972, Swindon in the UK saw the opening of one of the most striking attempts at traffic circles for directing high volumes of traffic through an intersection. The Magic Roundabout, as it become known, was designed by nobody less than our old friend Frank Blackmore, and contains five interconnected traffic circles forming a large reverse circle in the middle. This extreme example of the art of roundabouts has been nominated as one of the scariest junctions in the UK several times. Tourists and visitors are often advised to stay in the outer circle and leave the inner ring to the locals who presumably know what they are doing. (In Swindon, you can purchase T-shirts with the text “I survived the Magic Roundabout”. They are also building a second, slightly smaller magic roundabout.)

Roundabout in Swindon, Wiltshire, Uk.

Roundabout in Swindon, Wiltshire, Uk.

Despite all this, the Magic Roundabout in Swindon is a resounding success regarding throughput as well as safety. Drivers can choose the shortest paths and spend less time inside, which reduces the number of vehicles inside and thereby increases the throughput. Over four decades’ worth of statistics show that drivers are 75% less likely to get injured in this type of roundabout, mostly due to the low speed but also the slanted angle of entry. In fact, the Magic Roundabout seems to be the safest flat traffic junction layout ever invented!

Half a dozen Magic Roundabouts have been built in the UK over the years. Despite the positive evidence most of them have now been rebuilt using different layouts, and no more are being built (except in Swindon, obviously). The Magic Roundabout has simply been killed by public opinion — most people seem to be scared when they have to actually think for themselves. It’s so much easier to disconnect your brain and let somebody else take the responsibility.

And on that note, we would like to end our analogy. What is your organization doing when it comes to managing projects? Are you allowing your fear of local thinking override the need for smooth projects? Let us know in the comments.

Photo “Traffic Light Tree @ Billingsgate London” by Loco Steve
Photo “Roundabout” by born1945