How to continuously improve as a team

Retrospectives are a powerful way to make improvements happen over time. 

Why and how to conduct retrospectives

Retrospectives are one of the keystone ceremonies conducted within a Scrum framework, and they are also one of my most recommended life hacks. But if you’ve never worked on a team that follows Agile principles, this concept may be new to you. I believe these are the most important meetings that can be conducted within any team and, the better you get at conducting them and applying the learnings, results will follow.

Even if you have worked in sprint-based environments, though, you will notice that I’ve intentionally decided to apply the retrospective habit in other key areas of my life and work to gain the same benefit.

Before we get into the how-to of retrospectives, though, let me share more on why I find these meetings to be so particularly powerful.

Why retrospectives are essential

There are three major reasons that I believe retrospectives are the most important meeting a team can conduct.

  1. Without pausing to reflect on and share what’s taken place with others, learnings can more easily remain individual rather than collective

  2. This practice forces teams to celebrate wins and failures, encouraging everyone to realize that success is forged through failure

  3. Retrospectives result in real, sustainable, and implementable change that leads to better performance across the board

The questions asked in every retrospective

I won’t belabor this point, because the questions are very simple and should be practiced by all. They are:

  • What went well, and why?

  • What didn’t go well, and why?

  • What will we/you change next?

When to conduct retrospectives

In most teams, retrospectives are typically conducted at the end of a sprint (a.k.a. “iteration”), which are consistent periods of time in which you plan, commit to, and ship finished work. While employed heavily by product and software development teams, sprints can be employed by any type of team—especially teams that create finished deliverables in established periods of time (HR teams, marketing teams, finance teams, etc.).

However, on teams I lead, I encourage people to hold retrospectives much more frequently. In addition to post-iteration ceremonies, I also encourage that retrospectives take place:

  • On a regular basis as a functional team or squad

  • Immediately following key moments and activities that are essential to the performance of an individual or team

  • After shared, cross-functional events that are customer-facing

  • Following significant wins and failures

  • On occasion after repeated, recurring internal events and meetings

For example, these additional moments of learning might include:

  • A weekly retrospective as a specific team

  • Immediately after a sales person performs a sales call, demo, or presentation

  • Immediately after a service team member leads a customer-facing event

  • Sometime after winning or losing a big new or expansion deal

  • After losing a customer’s recurring business

  • In the last 10 minutes of a weekly meeting, especially after the first few, but even after every two to three months or so

The key in all of this is not to stick to the process just for process’s sake alone. Never. Instead, each participant should be looking for opportunities to reflect and share learnings with the team, injecting these retrospectives into their own process at the moments which help everyone most improve their performance. They should never become perfunctory, only perfecting.

Where and for how long to conduct retrospectives

While you should find a common place for recurring, post-iteration ceremonies to be documented, in the case of these more impromptu retrospectives, I encourage posting the learnings to a relevant Slack channel with a team, or perhaps just to Evernote if you’re doing it personally.

Wherever you document the learnings, simply exercise good judgment in who you believe will benefit from the knowledge. The more relevant information we share, the more others will learn, too.

Regarding the length of these retrospectives, once again, I encourage you to discern that for yourself. That said, time-boxing the effort can be helpful, and I do encourage it. So, as you go about conducting these retrospectives, consider:

  • You should include about 15 minutes of retrospective time for every week of iteration time (e.g. weekly retros are 15 minutes, every other week retros are 30 minutes, monthly retros are an hour, etc.)

  • Post-event retrospectives with other team members should probably take no more than 5-10 minutes

  • Personal retrospectives after repeatedly recurring activities, like sales demos and presentations, should rarely if ever take more than 2-5 minutes of reflection

If typing isn’t your thing, consider recording an audio or video of your retrospective that you share with others. You could use your phone’s voice memos and share that out, or you might just capture a quick Loom video. The only thing that really needs to be written down are the tasks you’re committing to implementing after the retrospective.

When retrospectives become useless

The whole point of a retrospective is to implement a change. There are three times in the lifecycle of a team that retrospectives can become useless which everyone needs to look out for. They are:

  • When there are no actionable changes that are identified and assigned to a directly responsible individual to help implement

  • When there are far too many changes to implement and it becomes an overwhelming burden

  • When a team stops being accountable to implement the changes discussed

No need to explain each of these. In short, these are the reasons why you should look for that “Goldilocks” sweet spot of 1-2 changes noted for next time. Nothing more, nothing less. When you talk about what needs to change, assign the action, set a due date, and get it done.

One way in particular to ensure that these changes are implemented is by reviewing the changes before starting your next iteration. For example, if you conduct a retrospective as a team on Friday, when you start your next iteration on Monday, start the planning process by reviewing the 1-2 changes you discussed the previous week and re-communicate the change that’s being made.

Always be learning

In all of this, be sure to not forget the primary point of conducting retrospectives and why to do it in the first place.

In the Pulitzer Prize-winning play-turned-movie, Glengarry Glen Ross, there is a famous line that is often used among sales teams:

“ABC. ‘A’, always. ‘B’, be. ‘C’, closing. ALWAYS BE CLOSING. Always be closing.”

As much as anybody can appreciate this sentiment and it aligns with the corporate value for creating sales cultures, I have a different mantra around the teams I work with: ABL. 

“A”, always. “B”, be. “L”, learning. ALWAYS BE LEARNING. Always be learning.

Using any Agile framework or the retrospective in particular isn’t just about shipping more finished work. The real goal of making commitments and conducting retrospectives is for everyone to increase their speed of learning. The faster you learn, the more you improve, and the greater your results. It really is that simple. If you remember nothing else, remember this.

In short…

retrospectives are really just a way to pursue this singular, clearcut goal: increase your collective speed to learning. As you develop this discipline, the sky's the limit. Never stop improving.


✅ Tips and takeaways

Now that you have a fuller understanding of retrospectives, it’s time for you to implement these ideas into your individual and team practices moving forward.

  • Participate in and contribute to a team retrospective at least once a month

  • Identify at least one key activity after which you will conduct your own retrospective on a go-forward basis

  • Rotate the responsibility of retrospective facilitation and note-taking among various members of your team

  • Never make it about the process alone—always focus on the purpose behind the process and how we can improve the process to better reach those outcomes

  • Shorten your team’s iteration cycle times so that your speed to learning is accelerated—2 weeks seems to work very well for many teams, but yours might be longer at first

  • Include at least 1 day between your retrospective and next planning ceremony

  • Use Loom videos or audio recordings if you’re looking for a quicker way to capture your thoughts without having to always write them down

  • Make leaders disappear on a fairly regular basis to ensure that the team conducts the practice and builds the muscle without always having someone more senior there

  • Consider doing daily standups or using another type of check-in process to stay on the same page and keep communicating openly and consistently

Above all, remember that none of this is about more meetings—it's about improving your focus and accelerating learning. The more you do this, the more rewarding your journey will be as team.


👇 There’s more…

Learn more

If you’re interested in learning more about Agile teams, frameworks, and continuous improvement practices, there are a number of excellent resources to choose from. Explore at your leisure.

The Agile Coach
Atlassian's no-nonsense guide to Agile development (and ideas). 

Scrum: The Art of Doing Twice the Work in Half the Time
Look into the framework from which many Agile ceremonies originate.

Shape Up: Stop Running in Circles and Ship Work that Matters
Personally, I really like Basecamp’s revisionist Scrum methodology.

Sprint: Solve Big Problems and Test New Ideas in Just Five Days
This is a great book that utilizes a specific framework to get big stuff done.

Atomic Habits: An Easy and Proven Way to Build Good Habits and Break Bad Ones
James Clear is all about continuous improvement for individuals.

 If you liked this, you’ll probably also enjoy my recommended life hacks 🚀