BONUS: Module 2, Retrospectives Master Class with David Horowitz

This is the second of a multi-part series on Agile Retrospectives with David Horowitz who’s the CEO of Retrium, a company that builds tools to help you facilitate remote retrospectives. The links to Retrium’s Retrospectives Academy below are affiliate links, if you prefer to follow a link that takes you to Retrium’s site, but does not give anything back to the podcast, you can. Just follow this link: On the other hand, if you want to help us grow this podcast, you can follow the links below or this link to Retrium’s Retrospective’s Academy.

In the second instalment of the Agile Retrospectives Masterclass with David Horowitz, we talk about the 5 phases of a successful retrospective, and share tips and ideas for each of those phases to ensure you are prepared and get the team to find and act on breakthrough improvements. 

You can find Module 1 of the Retrospectives Master Class here

It all starts with a simple check-in: “Set the Stage”, Phase 1 of a successful retrospective

When we start a retrospective, usually at the end of a Sprint, the team member’s minds might be on that last bug they just closed, or the story that didn’t get delivered, or the feedback they just got from stakeholders. The Check-in phase of the retrospectives helps all the team members, and the facilitator to get into the retrospective mood. To forget the open threads that will need to be picked up later, and focus on the question: “How can we do even better in the next Sprint?”

In this segment, we talk about the Constellations exercise that helps everyone visualize agreement and disagreement with a specific statement in a way that raises engagement, and increases the energy level of the retrospective. You can find here a detailed description of the Constellation exercise for Agile Retrospectives

We also discuss the “one-word check-in” exercise and the “Mad/Sad/Glad” check-in for Agile retrospectives.  

For retrospectives that try to focus on improving collaboration between team members, David suggests The Circle Of Appreciation exercise

In this segment, we also refer to the classic book: Agile Retrospectives by Diana Larsen and Esther Derby

Gathering Data and Generating Insights, the core of an Agile Retrospective

If we want to enable deeper conversations, we need to be aware that the information that is shared will directly affect the quality of the conversations. Therefore, Agile Retrospectives require special attention to the “gathering data” phase. There are many ways to gather data, and some might even happen during the Sprint, instead of during the retrospective. 

During the retrospective, however, we will visualize that data and help the team make sense of it. 

In this segment, we talk about the timeline exercise, and how to use emotional-queues to help uncover important pieces of information. 

Soft or qualitative data can also be used to augment the use of other data in the timeline exercise. One such way is to use the “journey lines” exercise.

When the data is visible and understandable, then the team focuses on finding insights by analyzing the data and generating possible connections and causal links. Here the challenge for a Scrum Master is to prevent the team from jumping too early into solutions before they deeply understand the problem they are trying to solve. 

David shares some tips to help prevent the team from discussing solutions before they have a shared understanding of the problem. We talk about The 5 Why’s technique, but there are many more. 

Making Retrospectives Impactful: Deciding what to do

Many teams fail in Phase 4, Deciding what to do. But they might fail in quite different ways. For example, some teams might want to commit to too many items at once, while other teams might not commit to any improvement. And finally, the worst problem: those teams that commit to improvements, but work on none of them. 

Great teams, understand well how many improvements they can take from a retrospective, and are clear on the commitment, maybe even including the improvement ideas as items on their Sprint backlog. 

In this segment, we talk about the ICE method for prioritizing improvement ideas and the importance of brainstorming several solutions before deciding what to do. It’s also important to use methods of consensus generation when there are several options that seem equally valuable. The commitment of each team member to the solution to be tried will directly impact their commitment to the work to be done for that solution. 

In this segment, we talk about experiments and the use of such templates as the Hypothesis-Driven Development template by Barry O’Reilly

Phase 5: Close the retrospective

At the end of the retrospective, our goals are to provide closure, a sense of achievement, and energy for the work ahead. 

How can we do that? In this segment, we talk about the “retro on the retro” and the “gif check-out”. Two simple approaches that help the team feel a sense of accomplishment, and also get better at doing future retrospectives. 

Which closing exercises have you used? Share those with us on Twitter or LinkedIn

About David Horowitz

David Horowitz is the CEO of Retrium, a platform for agile retrospectives that has powered over 100,000 retrospectives from thousands of companies across the world.

Prior to co-founding Retrium, David spent a decade at The World Bank as an engineer turned Agile coach.

He has degrees in Computer Science and Economics from The University of Maryland and a Master’s Degree in Technology Management from The Wharton School of Business.

Learn more about Better Retrospectives with David Horowitz by accessing the FREE Retrospective’s Academy by Retrium:

You can link with David Horowitz on LinkedIn and connect with David Horowitz on Twitter

BONUS: Agile Retrospectives Masterclass, PART 1 with David Horowitz

This is the first of a multi-part series on Agile Retrospectives with David Horowitz who’s the CEO of Retrium, a company that builds tools to help you facilitate remote retrospectives. The links to Retrium’s Retrospectives Academy below are affiliate links, if you prefer to follow a link that takes you to Retrium’s site, but does not give anything back to the podcast, you can. Just follow this link: On the other hand, if you want to help us grow this podcast, you can follow the links below or this link to Retrium’s Retrospective’s Academy.

In the first installment of the Agile Retrospectives Masterclass with David Horowitz, we talk about the basic setup for a successful retrospective. It all starts with what David calls the triangle of success: People, Process/facilitation, and Follow-through.

How to set up your Agile Retrospectives for success with the right people

Continue reading BONUS: Agile Retrospectives Masterclass, PART 1 with David Horowitz

Agile Practices Retrospective – How to help teams get unstuck!

This is a guest post by Jeff Campbell, author of Actionable Agile tools (available on Amazon, and direct from the author at

Keeping retrospectives impactful and fresh

We like to keep our retrospectives fresh. We find it helps to reveal things we might not otherwise have found if we alter the format frequently. With this goal in mind, we follow a simple system:

Once a month we use our ”normal” retro format. Everyone in the team is familiar with this, and we can perform them quite quickly, with minimal prep work and explanation required. Basically, effective with very little admin.

Once a month we have our ”experimental” retrospective. A little more set-up time required, but a good opportunity for experimentation and explorations.

This is the story of one such retrospective.

Click to learn more about how you can help your PO

Agile Practices

Obviously, you can perform many Agile practices, but not be Agile. However, there are a lot of practices out there and sometimes teams can become focused solely on those that they are currently using, rather than looking at other tools they might bring to bear. This is where the Agile Practices Retrospective comes in.

Prep Work

In preparation for the retrospective, we created cards with various Agile practices as headlines, and a brief explanation of each listed on it. I also color coded them under various categories so they could be more easily identified from afar. Then we simply taped all these cards to a wall in their respective categories. There were about 50 cards in all.

Special thanks to Jurgen Appelo for providing the initial list I worked from:

Here is a link to a google doc with the prep work I have done, to save you some time:

Reducing the complexity

With over 50 cards, there was a lot of information. We split into groups and started categorizing the cards under a new set of headings, it was made clear to all that they were not expected to read all the cards.


  • Doing (Working Well): Things we are currently doing, and quite happy with the way they currently work.
  • Doing (Could be better): Things we are currently practicing but could use improvement.
  • Not doing (By choice): Things we are not currently practicing, but have made a choice not to use in our context.
  • Not doing (Not tried): Things we are not doing, and have never really tried.
  • WTF!?!: We have no idea what this is, or what it means.

Deciding what to focus on

We obviously cannot talk about all these things. So, we used dot voting to decide what topics to focus on. Each team member was given 3 ”dots” for each of these types of vote:

  • We should start and or alter this practice in some way. (Indicated by a dot)
  • We would like to learn more about this practice. (Indicated by a +)

I also printed out simple list versions of the same information, as I knew it would be hard for everyone to gather around the board when deciding how to use their votes. Despite this, this was still not as successful as we would have hoped. Part of this is because we are actually two teams and our 3 customer representatives, so the whiteboard was too crowded. I feel this would go better with a single team.

Discussions and action points

We had open discussions and tried to create action points/experiments around the topics we had discussed. I will just give a very brief of what we arrived at:

Root Cause Analysis/ 5 Why’s

We even arrived at the fact that without formal tools, we are still quite good at root cause analysis. But perhaps a formal tool might reveal something we would have otherwise been unaware of.

1)Focus on using our discussion time during retrospectives (Generate Insight) to use more formal tools like 5 why’s.
2) When events are added to our timeline at daily stand-ups, then we should also consider doing a more in-depth analysis of those items.

Product Vision

We felt that we very likely do have a product vision, and even a fair amount of impact mapping done for that, but this is not communicated to the entire team at a frequent enough rate. Also, we need to get better at following up these things.

1)Make the product vision more concrete and communicate it at a regular interval.
2)Follow the vision and impact map up at a regular interval.

Behaviour Driven Development (BDD):

This is a discussion point we wanted to learn more about. So, the discussion was brief. We basically arrived at the fact that it was intriguing and we want to know more.

1)The two team members who know something on the subject will provide some links and a quick intro for everyone else.
2) Some of the team will experiment with these concepts in our ”Brain Day” next week.


The Good:

This retrospective was reviewed well by the team, everyone generally liked it.

It was a fairly active retrospective, because of all the moving things around and working in teams, so the energy level remained high throughout.

Probably the best aspect of this retrospective was the addition of fresh concepts into the team, the idea to focus on things we wanted to learn more about was a good one. In the future, we would probably recommend only focusing on these things.

The Bad:

There was a fair amount of prep work involved in this one, although I consider it worth the investment, it wasn’t free. Hopefully, a bit cheaper for you, as we have provided the work we have done. Once again:

It was too hard to get an overview with so many items, this may have been due to team size, and might have been possible to mitigate by having the team read the list beforehand.

Despite there being so many items, the list was not even close to exhaustive, and it was hard to leave off some practices that really should have been included.

About Jeff Campbell

Jeff Campbell is the author of Actionable Agile Tools, a book with practical tools and practices to help you amplify your impact as a coach and Scrum Master

Jeff is an Agile Coach who considers the discovery of Agile and Lean to be one of the most defining moments of his life and considers helping others to improve their working life not to simply be a job, but a social responsibility. As an Agile Coach, he has worked with driving Agile transformations in organizations both small and large.

Jeff is also involved in the Agile community and is one of the founding members of Gothenburg Sweden’s largest agile community at 1500+ members , and he also organizes the yearly conference

You can link with Jeff Campbell on LinkedIn and connect with Jeff Campbell on Twitter.

Constellations dynamic for retrospectives

Total time execution for this format: 60-90 minutes

Click to learn more about how you can help your PO


The purpose of this dynamic is for everybody to participate and share their feelings, perceptions and opinions without even talking (at first).


  • For the team: They can see themselves and understand their colleagues from a different perspective, they can really feel others because they are not talking or trying to gain their position within the room. They just observe, feel and act their feelings.
  • For the facilitator: There is something so powerful about standing in a circle. You know it if you do your daily meeting. We can immediately see the whole picture, the real feedback from the team without mixed perceptions or words, which generally cover the real significance. We can say: “bodies don’t lie”.


  • Empathy building.
  • Address and specify the situation the coach is sensing and the team doesn’t feel like talking about this for of any reason (e. it’s too painful, they feel uncomfortable, and some team members are unaware).

What you need – Preparation

  • Find out the number of participants first: The room where the retrospective will be run must have enough space for everybody in the team to be able to stand up in a circle (and move from a tight to a larger circle).
  • Adhesive tape: to post the cards on the wall or board before the discussion.
  • An element or object: big enough to serve as a reference for the responses, noticeable and “good looking” (I wouldn’t recommend a trash bin), and not so distracting or not so high that participants can’t look at each other’s faces. (e., it could be a mini statue, an umbrella stand, or a little circle drawn in the middle of the room).
  • Write down statements or questions: to read out loud on cards so the team can express their response about these topics.
    • Statements examples:
      • I feel free to express in this retrospective.
      • I am satisfied with the results of this sprint.
      • I am happy with the quality of our code.
      • I consider our releases are easy and smoothly delivered.
      • I think my daily work is recognised.
    • Question examples:
      • Do you feel safe enough to be able to express in this retro?
      • Are you satisfied with the team collaboration?
      • Do you consider the technical debt has been reduced in this sprint?
      • Do you feel motivated in your daily work?
      • Do you think you are making an impact on people’s lives with our product?

How to run the retrospective

A. Introduction (1-5 minutes)

  1. Brief check in: Make sure the team is relaxed and ready to start. A brief check in exercise can help to set the environment.
  2. Explain the rules: Position the element in the centre of the room to act as a reference for the team members. No one is allowed to talk during this exercise. Only explain that standing closer to the object will mean “YES”, “I TOTALLY AGREE”, while being farther will represent of “I DON’T AGREE”, “NO”.

B. Running the exercise (10-15 minutes)

  1. Read the cards out loud one by one and leave time for the participants to respond with action.
  2. Observe the situation: They will individually respond by getting closer or farther from the object. You will notice people in between: “I AM NOT SURE” or “MAYBE”, just watch. Take mental notes, or have someone external to the team help you with the notes.
  3. Ask the participants about their feelings: Listen closely to what they went through during the exercise. You will notice the different reactions and realisations. That input is invaluable for you as a facilitator to go on with the discussion. Sometimes the participants are so amazed they need time to stay calm and reflect about what had just happened, especially when one of the topics was revealing for the team. Maybe a relaxation exercise is handy here, if necessary.

C. Sharing thoughts (10-15 minutes per topic)

  1. Post the cards on the wall and vote: Tell them to vote prioritising the situations according to what they consider critical to address now for the team.
  2. Select the topics: The most 2 or 3 voted topics will be discussed in pairs or mini teams of 3 or 4 people, according to the time left for the retrospective.
  3. Discuss: Start by the most voted one first. Set the time for discussion. Let the conversation begin!

D. Taking action: (15-20 minutes)

  1. Share results: After each topic discussion, share their opinions, proposals, options and work to find the next steps to follow.
  2. Make a commitment: The result may be an experiment to try: set the hypothesis, metrics, who will be accountable, and time to check again.

Powerful questions:

  • How does this topic make you feel?
  • Do the other team members feel the same? Why?
  • How can you contribute a solution to the situation you have just found?
  • What could we do to improve this particular subject?
  • Is there anything else creating this perception?
  • Where can we start? Who else can we involve in the solution?
  • Why is this important for the team?

Additional tips, comments and alternatives:

  • It is very important to find the right questions/statements for the team to elicit reflection, especially when you already know the situation, and they can’t see it yet.
  • Questions and statements are good for The participants tend to repeat them in their heads, so they get to their feelings and act accordingly.
  • Follow a defined format, questions or statements. Following all at the same time might be confusing.
  • Choose a maximum of 10 topics to avoid losing focus.
  • The topics can be technical, human, process or product related; there are no limits here. You could even use this dynamic for an agility assessment, where the statements or questions are related to the agile principles.
  • It has been very useful to me during facilitation in almost any case, with people; talkative or shy, who were new or had been working together for several years, who weren’t participating too much lately in the retros, and so on.

Special thanks

Thanks Vasco Duarte for bringing up the subject in your podcast: Scrum Master Toolbox

About Carolina Gorosito

Carolina is a natural connector and team enabler, great at finding people’s strengths and helping them combine their skills to become high performers in the organisations and obtain better results every day. She currently works as an Agile Coach and is a dedicated Creative Change Agent, specialised in problem solving and communication.

You can link with Carolina Gorosito on LinkedIn and connect with  Carolina Gorosito on Twitter.

Click to learn more about how you can help your PO

A “Positive” Retrospective

One of the Agile principles states that “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” These “meetings” are more likely called Retrospectives and can be held in many different formats (here are some examples er-facilitators and​. The most famous is the “Mad, Sad, Glad” format, and many others are just variations of this very basic format.

Read on for the “positive retrospective” format and exercises.

Click to learn more about how you can help your PO

These formats are based on the aim to analyze the previous team’s activities in order to achieve better results. Sometimes, it may also help to analyze the successes of the team in order to understand what helped in achieving them and how to replicate such successes: that’s what I call a “Positive Retrospective”.

The period we may wish to analyze may vary; last iteration, last month, last year and so on. What do we need to organize this retrospective? The usual materials such as some stickers, pens and a whiteboard or a flipchart.

The first action to take is to create a collaborative and positive atmosphere, so ask the attendees to write down some few words of appreciation for a colleague (or more), thanking him/her for something he/she did during the given period, for the person or for the team. Give the team 5 minutes to write.

Then ask each attendee to read aloud what they wrote, speaking to the colleague they want to thank. This phase shouldn’t take more than 5-10 minutes.

The next phase is to list all the positive results achieved in the period.

Ask the attendees to write down on the stickers all the positive results achieved, using a short statement (one per sticker) – they will be given the opportunity to explain in the next phase. Give them 5 minutes to write.

Now ask the attendees to explain the individual positive issues, one by one. They should be concise in their description but still be able to let the other attendees understand the issue. Then the sticker is pinned to the whiteboard. If any other attendee has a similar issue, he/she has to discard it. Please be careful to avoid starting any discussion. This is the time to list the results and not to discuss them (moreover, the discussion will be shaped in a particular way, as we will see in the following stage).

Once everybody has explained their issues (this stage should last no more than 10 minutes), you’ll have all the stickers on the whiteboard. It’s time to vote.

Each attendee will have six votes to give to the issues stuck on the whiteboard: three votes to vote the issues by its intrinsic or technical value (for example, the team reduced the technical debts by 50%, or has stabilized the daily standup) and three votes to vote the issues by the positive impact it had on the product (for example, thanks to this new feature, the customer increased his sales by 20%). You can use any means to vote: in my example, we used little red self-adhesive dots for one and green for the other, but you can use different signs, different colored pens, and so on.

Why differentiate this way? The answer is easy: teams tend to identify their success with the product’s success; we delivered this feature, the customer were happy, we eliminate that bug and so on, forgetting that with success stories, many other aspects must ​ be considered. For example, adopt a more effective framework for the chosen programming language, start unit testing, practice a scrum ceremony in a more efficient way and so on. The team must learn these positive issues as well, as they allow the team to be more effective ​ (as per the above mentioned Agile principle).

Once the voting is finished, just rank the issues by the numbers of votes (any kind).Voting and ranking shouldn’t take more than 5 minutes.

Once the stickers are rearranged on the whiteboard (the most voted ones are on top) you can start to discuss. The format may be free (you can discuss any issue as long as you want), or fixed (an issue can be discussed for a maximum amount of time of 5 or 8 minutes, for example). Choose the format you like, what counts is the discussion itself.

Ok, let’s discuss, but about what? We usually discuss what’s going wrong, and how to fix it. Now, here instead, we’re discussing what went right! Well, we can first identify what made that positive issue possible. Usually, we can identify two main paths: one internal to the team, and one external. The internal one refers to all the actions the team takes to achieve a result, which may impact the team, the process or the product. For example, by autonomously adopting a new programming framework the team was able to deliver those given features and the customer was very happy. Note the ​ word “autonomously”: the team was not forced by any external entity to take that decision, but reached a result that had an external impact anyway.

The external path refers to all those actions taken or conditions set up by the system (your department, your local agency, your company, and so on) that made it possible to achieve that given result. For example, the team was able to learn how to deal with noSQL databases thanks to a dedicated budget for training on new and emerging

technologies/methodologies. In this case, an external reason made it possible to achieve an internal positive result. Nevertheless, we mean to say that an internal result will sooner or later reflect itself into an external positive result (or at least, this is what the system hopes…).

The discussion stage may last up to 50 minutes, to keep the whole retrospective no longer than 2 hours.

And now, just like any Retrospective worthy its name, let’s write down some action points.

Like any positive issue in any field, we aim to replicate it and also do something to improve that experience to feel even better. So we can define the underlying actions that will lead us to even better results. Some questions easily come to mind: can we replicate the positives we had during the period, applying them to current or new issues? For example, we may ask for a new course to learn a new language to create a new software asked by our customers. Or, can we improve the path that led us to have positive results to have better results or even the same results but in different areas? For example, improve the continuous integration process to have a faster/safer deployment of our deliverables.

Or just have more frequent retrospectives to improve our work!

Discussing and writing the Action Points may take up to 20 minutes.

Now the meeting may be closed. See you next Retrospective!

About Enrico Di Cesare

Always interested in improving the quality of the software produced for himself or for his customers, Enrico became an Agile enthusiast as soon as he discovered it. With extensive previous experience as a Project Manager and Coordinator, Enrico works as an Agile Coach, Scrum Master and Product Owner, introducing, mastering, facilitating and refining the adoption of Agile with new collaborative tools.

Alex Fürstenau explains how retrospectives can help teams get out of the “us vs them” anti-pattern

When a team faces a problem they have a choice between blaming someone else (“them”), or taking ownership and making it happen even if that improvement looks beyond their reach. We as Scrum Masters can help teams take ownership, even when they need to involve other people in the resolution of the problem. Alex explains the problem, and some of the possible techniques to get the team to understand that they own the results of their work.

About Alex Fürstenau

Alex Fusternau scrum master toolbox podcast(1)When he was 12, his father bought him his first computer, a C64. The moment he saw characters appearing on the television was the moment when he knew he would do something with computers. Several years and a computer science study later that “dream” became true.
Alex quickly realized that the customers were not happy with our product. The first approach was to fix more of the requirements but it made things worse. During that time (around 2002) he thought “There has to be a better way” and he found several, among which was Agile.

You can link with Alex Füsternau on Linkedin, or connect with Alex Füsternau on Twitter. Alex also facilitates a regular meetup in Hamburg on the topic of Liberating Structures, for more on the meetup visit their meetup page.

Alex Fürstenau reminds us that Retrospectives need energy

Often we disregard this very simple fact, by the end of the sprint people are tired. Hosting the retrospective at the end of the day, on the last day of the sprint is not ideal from the engagement and energy level point of view. Alex explains how he failed at keeping the energy level high in one retrospective and what he learned from that moment, that he still applies today.

About Alex Fürstenau

Alex Fusternau scrum master toolbox podcast(1)When he was 12, his father bought him his first computer, a C64. The moment he saw characters appearing on the television was the moment when he knew he would do something with computers. Several years and a computer science study later that “dream” became true.
Alex quickly realized that the customers were not happy with our product. The first approach was to fix more of the requirements but it made things worse. During that time (around 2002) he thought “There has to be a better way” and he found several, among which was Agile.

You can link with Alex Füsternau on Linkedin, or connect with Alex Füsternau on Twitter. Alex also facilitates a regular meetup in Hamburg on the topic of Liberating Structures, for more on the meetup visit their meetup page.

Zuzi Sochova on the “we’re already good” anti-pattern

Many teams get stuck in a bad place, but there are some teams that also get stuck, but because they think they already are “good enough”. Listen in to learn how Zuzi learned to work with teams that already think they are “good enough”.

About Zuzi Sochova

Zuzi help companies and individuals to be more successful. She teaches teams and their managers how to be more efficient, how to provide better quality and how to communicate and organize teams so that people have fun, they are motivated and have high commitment. Zuzi helps teams and managers find out how to handle customer relationship to help them improve customer satisfaction.
You can visit Zuzi’s website at:, and link with Zuzi Sochova on LinkedIn, or connect with Zuzi Sochova on twitter, or your favorite conferece.

Sven Schnee on the importance of retrospectives for Scrum Masters to evaluate their work

Retrospectives are a key part of any Scrum team’s process. However, they are also key for Scrum Masters to evaluate their performance. Sven shares with us a process he uses to help him detect possible problems, and invest in solving the right problems to help the team, and himself succeed. We discuss plenty of practical advice regarding the structure and the content of Retrospectives.

About Sven Schnee

Sven started his journey as a developer around the year 2000. He experienced many projects and felt the pain of how traditional approaches to software development failed.
A few years ago he discovered Agile and Lean, and he is not going back.
He is an Agile Coach and Founder of Oikosofy. He wants to bring agile ways of working to a variety of customers from small companies to big enterprises. One of his key strengths is helping teams evolve on their path to self-organization.
You can connect with Sven Schnee on twitter, and link with Sven Schnee on LinkedIn.
You can read Sven Schnee’s blog The Product Owner Toolbox.