March 5, 2014

Retrospectives - What makes a retro good

Why are retrospectives important?


They provide the opportunity for a team to look back and see how they can improve. 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. They can be a place for learning, problem solving, or having fun and motivating each other.  To not have retrospectives or to do them badly means that you are missing an opportunity to inspect and adapt, possibly the most important part of your Agile journey.

What do your retrospectives look like?


When you have a retro is the team all gathered in a room around a small table? The Scrum Master throws some pens and some stickies on the table, and the team writes down what went well and what can be improved? You make lists and group the topics together. Retro after retro the same stuff emerges and the actions are not always followed through, or perhaps they are not within the influence of the team.

Half the people in the retro check out and aren’t present or participating, and some are on their phones. Most of them would rather be coding.

Does any of that sound familiar??


What’s wrong with that?

If people stop engaging in the meeting and are feeling that their time is being wasted, then maybe it is. If meetings aren’t adding value and actively driving change within the team and the organisation then you need to change them or stop doing them.

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 the root cause of the problem is not being solved.

Analyse and dig beneath the surface to the root cause, or you may just be wasting your time.

What does your team need?


The first step is to understand what your team needs and where they are with their journey.

As a facilitator /coach /Scrum Master, I try to observe and pay attention during the sprint, or week, or whatever cadence my team has, to what is going on with the team. What do they need? Is there a specific issue that they are grappling with as a team? Are they not making their sprint goals? Are they a new team still forming and learning to trust each other? Have they lost trust in each other or is there a lack of trust between the team and the product owner? Maybe they have just had a hectic couple of sprints, and they need to celebrate their wins and not change anything.

Tailoring the retrospective to what the team needs, is hugely valuable and in my eyes very important. Understand where your team is at, help them to see what they might not be seeing and help them to understand how to move towards a solid change. Make sure that you are facilitating a space where people can analyse and dig beneath the surface.  Sometimes setting a goal is useful especially if you as the Scrum Master are seeing things that the team needs to address.

What makes a good retrospective?


Read Diana Larsen and Esther Derby’s book Agile Retrospectives - Making Good Teams Great. In the book, they lay out five stages.

  • Set the Stage - Understand where everyone is coming from today.

  • Gather Data - Get the viewpoints of all members of the team so that you can create a shared picture of what is happening.

  • Generate Insights - Unpack the data and analyse or look for the root causes.

  • Decide what to do - Make sure the team decides together what is important and what is the most important thing for them to do.

  • Close -  Appreciate peoples time and get feedback in terms of how to get better at retrospectives, both you as facilitator and the team.


This is an excellent base-line for your retrospectives and makes for a good starting point. Use the book and the stages coupled with your observations to tailor a retrospective for your team. Bearing in mind that sometimes the retro does not need to include the five stages.

How do I keep people engaged?


Once you have decided on what your team needs to focus on then you need a plan for your retrospective. Spend some time on deciding what you are going to do for each phase or if you are not going to have phases then how you are going to divide up your time. Break people into smaller groups of up to three people whenever possible, its much easier to keep the energy high and keep people engaged in smaller groups; it is also much easier to get things done.

Make sure you are encouraging everyone in the team to contribute and encouraging people to do that in their own way. I once made the mistake of trying to force people who weren't big on being on the spot and talking to do that. It didn't go well. Silent brainstorming is a good way to gather data and make sure that everyone stays engaged.

Where can I get ideas?


There are plenty of places to help you with ideas for exercises to do during retrospectives. Diana and Esther’s book has a wealth of things to do and is an excellent starting point. There is a website called Retr-O-Mat  (http://plans-for-retrospectives.com/) that has many ideas for games or exercises that people have run. Be careful not to overload your teams with games, the most important things for planning your retro are to pay attention to what your team needs and to make sure your retro flows. Keep the flow going; and of course you make sure that you have something to action.

Remember to not try to do everything at once. One or two key changes are usually more than enough to do. 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.  Jeff Sutherland also has a 3-minute video “Inside the Sprint Retrospective” (http://youtu.be/MFLvQXMNrO8).

How do I know that I am doing the right thing?


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

This topic is rather large, and probably requires multiple posts. This is just a starting point. Read blogs, get ideas, read books and grow. Whatever you do; make sure your retros are adding value to the team, and it doesn't hurt if they are fun.

Make sure that there is an outcome for the retro and then support the team in making that change, be careful not to make the change for the team, you want to encourage self organisation and not be the solution provider. Have a look at my other blogpost on Action Plans for cementing outcomes. (Http://arbitrarymix.blogspot.com/2013/08/the-action-plan.html)

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.
Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.
blog comments powered by Disqus
Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.

Latest Posts

Mike Freislich on the inevitability of change

Video of Mike Freislich interview with Klaus Leopold on the Lean Business Agility podcast

Image of abragad

Alessio Bragadini

Web community manager of agile42, trying to post relevant, informational, fun bits of content on the blog and social networks

Agile Portfolio Management in it-daily.net

A new article in German magazine it-daily.net

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Why Agile Transformations Fail – Do You Fall Into The Same Pitfalls?

Insights from TAC2017: Why do agile transformations fail? Identify whether your team or organization falls into the same pitfalls.

Image of hwong

Hazel Wong

Marketing Assistant at agile42. Passionate about gaining insights from data in order to create content that resonates with the audience. Eager to help teams and companies open their mindset about the application of agile methods to address their challenges.

Sponsoring Let's Test South Africa

Let's Test South Africa 2017 sponsored by agile42

Image of joperold

Joanne Perold

Agile Coach in South Africa. Explorer, learner, experiencer, part time philosopher, working with teams and organisations to be more agile.

Niels Verdonk, new Certified Scrum Trainer in the Netherlands

Niels Verdonk has qualified as a Scrum Alliance Certified Scrum Trainer

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.