Agile Retrospectives

The goal of this post is to give teams a basic, solid introduction on how to have not-sucky Sprint Retrospectives. I cover here the common misunderstandings about retrospectives and share the fundamentals of how to have an effective Sprint Retrospective. If you’re later interested in going in-depth on this topic, my Guide to Effective Agile Retrospectives also includes examples and descriptions of recommended activities to help improve this Scrum Event that Team Members and ScrumMasters often struggle with.

Retrospectives are explicitly part of Scrum – “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.” and implicitly part of the whole Agile movement – witness Agile Manifesto Principle #12: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”

Scrum values openness and courage. It‘s all about looking honestly at past performance and making changes where needed. The Scrum pillars of transparency, inspect, and adapt are applied to pull those values, tenets, and goals together. To achieve this, continuous improvement and short feedback loops are at the core of any Agile process. Without a structured improvement process, it can be difficult for teams to improve, and without improvement, they will stagnate. For frameworks like Scrum and XP, and relatives like Lean, we use retrospectives as the core part of this process.

Common Misunderstandings

When I run Certified ScrumMaster workshops, I notice people often arrive with three common misconceptions:

• A retrospective is the same as a Post-Mortem – No, they’re more like distant cousins
• Retrospectives are Product-focused – No, that’s what a Sprint Review does
• Retrospectives all have the same Agenda: What went well/poorly and improvements to make –Boring! Most people would rather poke out an eye than attend another boring event. Teams should craft agendas that work well for them.

It’s Not a Post-Mortem

The traditional approach with project work is to wait until the work is over before seeking systemic improvement. They often use a Post-Mortem: a meeting after a project, to help learn from what happened.

Retrospectives differ from Post-Mortems in some key ways:

• Post-Mortems occur after the project is done (or even dead), when it’s too late to improve that project. Retrospectives encourage change to happen throughout to improve the final result.
• Post-Mortems are long feedback loops, once per project, which might mean every 6-18 months. Retrospectives are short feedback loops, happening often enough to be relevant and valuable during the project.
• Post-Mortems often generate attractive-looking reports that are placed on a shelf and ignored (also called write-only documentation). Retrospectives create no dust, only honest communication and action.
• Post-Mortems sometimes turn into blame and shame events. Retrospectives offer opportunities to say “how can we” rather than “you should have.”

It’s Not a Sprint Review

Most people aren’t used to the idea of separating product improvement from process improvement, so it’s no wonder they don’t understand how a Sprint Review differs from a Retrospective.

The Sprint Review gives the Development Team, Product Owner, ScrumMaster, and any interested stakeholders/customers a chance to examine the product and make decisions about improving the product. By contrast, the Retrospective is about team and process improvement. When a team focuses too much time and energy on product discussion, it loses an opportunity for improvement.

It Doesn’t Have to Be the Same Agenda Every Time

I’ve personally attended and (gulp) facilitated too many retrospectives that followed a simple format: what went well, what went poorly, and what do we want to improve. People always wanted to rush through these events. I kept wondering why. There was some engagement, but it was the same few people every time.

When we use the same limited palette of activities and fail to follow up on improvements, the energy for retrospectives dies. Even worse than habitually repeating the same structure each time, is having no structure at all – some retrospectives are nothing more than team members gathering in a room, speaking over each other and rehashing the same old problems Sprint after Sprint. Perhaps it’s not surprising that these teams stagnate.

If you want your retrospectives to be engaging and reveal current problems, you must vary their style and content. To help you do this, I’ve outlined the structure and intent of retrospectives below. You can also subscribe to receive the much more detailed Guide to Effective Agile Retrospectives, which includes recommended activities and samples of each.

With an improved understanding of retrospectives and that handy Guide for activities, there is no excuse, and I should never again hear that a team member attended the same boring retrospective, Sprint after Sprint.

What is an Effective Retrospective?

A retrospective is a structured moment for the team to stop, breathe, and reflect on the past cycle. The team meets to discuss what went well, what went less-than-great, and some things that could be better if the team has the energy to improve. In the world of Scrum, the retrospective is usually the last activity in a Sprint.

What Good Does It Do

• Reminder of positive things that have happened recently in the team
• Focused improvement goals for the system
• Encouraged collaboration in the Sprint by collaborating in the Retrospective
• Heightened sense of ownership of their work and process
• Increased work satisfaction
• Improved quality and, eventually, capacity/productivity
• Better awareness of the needs of individuals and the team as a whole

Elements of an Effective Retrospective

Well-run retrospectives provide an opportunity for small improvements and clear agreement on actions to be taken afterward. Here are some things to focus on to help improve the effectiveness and reduce the “Ugh…” factor of your retrospective.

Not Focused on “Blame and Shame”

Retrospective Prime Directive (Norman Kerth): “Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”

Kerth’s Prime Directive is often misunderstood. He is not saying everyone is blameless no matter what happens in the retrospective. If we walk into a retrospective thinking about a certain team member and the big mistake they made, we won’t be looking at the circumstances surrounding the event. Instead, we will be focusing on the person. Many errors occur not because of a person’s behaviour, but because the system guided them towards the outcome. Example: mid-Sprint, a serious defect was found. A team member rushed to fix and deploy. Their work fixed the problem but created a new, larger problem.

A team focused on blame will focus on the individual’s behaviour (e.g., the team member failed to check the Definition of “Done,” they failed to run the unit tests before check-in, etc.), In this environment, the team member is likely to feel attacked than acknowledged for resolving the initial problem. They’re unlikely to learn anything from the criticism and, most importantly, miss the opportunity to dig deeper into the systemic issue.

Remind participants at the start of every retrospective that it is never about blame and shame. It’s about understanding what happened in the course of the last Sprint. The focus should be on events, not on people.

Simple Ground Rules

Clear meeting ground rules should be part of your Team Working Agreements.

Ideally, ground rules will be behavioural (e.g. “state views and ask genuine questions”) vs abstract (e.g. “be respectful”).^[3]

These should be created, maintained and owned by the team.^[4] The ones below are possible examples:

• Come with an open mind from all team members with a focus on solutions, not on problems.
• The facilitator must be capable of staying out of the conversation while maintaining its flow. Occasionally, bring in someone to facilitate who is not involved with the team or its work, to see and benefit from different approaches.
• Vegas rules – what’s said in the room stays in the room.
• Laptops and phones away.
• Use a Parking Lot for long discussions.
• Don’t interrupt (some teams using a talking stick to help with this)
• State views and asks genuine questions.^[5]
• Share all relevant information.
• Use specific examples and agree on what important words mean.
• Explain your reasoning and intent.
• Focus on interests, not positions.
• Test assumptions and inferences.
• Jointly design the next steps.
• Discuss undiscussable issues

Need a prompt to help create effective ground rules? Try “Think of the best or most effective meeting that you have been to recently. Tell the stories of those meetings, identify the common patterns. Those patterns are your potential ground rules.”^[6]

Well-Structured

Many retrospectives use the model originally outlined in “Agile Retrospectives – Making Good Teams Great” – Esther Derby and Diana Larsen.

Figure 1 – Creative Commons – Chris Smith https://leadingagileteams.com

That picture is evocative but it doesn’t tell you much about what happens at each phase, so let’s learn more about each one.

Set the Stage (also called Check-in and Opening) invites people to be in the room and it switches gears from the Sprint Review. Done well, it frames the purpose for the Sprint Retrospective and also reminds the team of the Retrospective Prime Directive and their agreed-upon Ground Rules. Choose an activity that helps to sense the mood or energy of the team.

Gather Data is when we look back to find information on what happened in the Sprint. In this phase, simply learn and list what happened and don’t immediately judge or search for things to improve.

Some of this work happens in the retrospective, but a lot of it happens before. Both the ScrumMaster and the Development Team could take data and bring it into the retrospective for this purpose. For example:

• • the Team calendar – helps to remember who was present and who was away
  • Number of Stories Completed
  • Sprint Burndown (hint: avoid burndowns in task hours as they cause team members to focus on completing tasks and not delivering features)
  • Sometimes better than the Sprint Burndown is to take a snapshot of the team’s Scrum Wall every few days. At best, a burndown shows that you had a problem. Snapshots of the team wall will show you which Product Backlog Items or User Stories got stuck and where the issue was.
  • Did the team have any Production Support issues to deal with? When did they happen? Were there interruptions from other sources (i.e. VP or CEO)? When? Capture this information on a Kanban wall.
  • Average Cycle Time and if there were any extreme outliers
  • Items still In Progress at Sprint End
  • Meetings that team members attended outside of the Scrum Events
  • Number of new defects introduced in the system
  • Number of User Stories that were thought complete but failed to meet Definition of “Done”
  • … Any other sources of information that could help with the team’s awareness of their circumstances – with one caveat – please, at all costs, avoid information that is focused or directed at one individual.

(For a massively long list of measures, see: https://agilepainrelief.com/blog/measurement-for-scrum-what-are-appropriate-measures.html). Start small and build as your team learns to digest and understand the data found.

It’s important to gather this data before the retrospective because we don’t have accurate or complete memories of what happened in the past Sprint. In a CSM workshop, I ask a simple question, “Without looking at your tools, can you tell me what you completed a week and a day ago?” Most people can’t. Yet when we walk into a retrospective, we magically expect people to have better memories of a 2 to 4-week Sprint. Since that is unrealistic, the team and ScrumMaster need to gather the objective data that is available to them and provide it to the Team before the retrospective, either in a handout or email. Team members then can take time, either before or during the retrospective, to review the data gathered.

For the data gathering that happens during the retrospective itself, we need activities that get information out of the heads of team members without judgement or comment. Silent listing activities^[7] can be especially important when some team members are quieter than others (often referred to as introverts). Quieter people benefit because their voices aren’t drowned out by the louder team members — all ideas get equal space.

Generate Insights. The data from the previous round is used to inspire the insights this round. The linkage doesn’t need to be direct. The goal of gathering data first is to ensure the team is working from the widest set of ideas to improve from.

Decide What to Do. For many people, this is the only part of the retrospective that seems natural because we want to jump in and solve problems. The effort until now has been focused on having a deep understanding of the issues. Now we decide which action(s) the team thinks will be most effective for making small changes.

Once you decide what you have the energy to tackle, consider writing your actions as S.M.A.R.T. Goals: Specific, Measurable, Attainable, Realistic/Relevant, Timely. S.M.A.R.T. is just a checklist that forces the team to ask questions about the action or change they have committed to. In the context of a Scrum team, I recommend always make ‘timely’ less than two weeks, so you check back in the next retrospective. Caveat: not all goals meet the S.M.A.R.T. criteria, and that’s fine. Sometimes the benefit is asking the questions, not the goal. If you want to take your actions up a level and turn them into experiments, we cover this is in more depth in this free download:

Closing is an opportunity for the team to reflect on the retrospective itself. Maybe there are things to change before running the next retrospective. It also provides an opportunity to celebrate – what did we learn about ourselves that will make us better in the future?

The structure we have described above (Set the Stage, etc.) isn’t a required format. You may use any model to organize your retrospectives, however, most sources, including blog posts, books, and online tools assume that you’re using it.

Who Attends a Team-Level Retrospective

 It should involve the whole Team – personally, I like to see (or hear) the Product Owner and the ScrumMaster as well. Some people will tell you the Product Owner’s presence isn’t necessary. That’s fine, but if they’re not there, they can’t help make things better.

Summary

Retrospectives are to help the team celebrate all the things that are going well, to provide feedback to the team, and to create a plan to improve in the next Sprint. They should be happening at the end of every iteration or Sprint. Scrum Guide suggests a three-hour retrospective for a month-long Sprint. I find, based on my client experience, allowing one hour for every week of a Sprint is more effective. Therefore, a two-week Sprint would have a two-hour Retrospective.

For a more in-depth look at retrospective items including suggested activities, subscribe to receive our extended guide.