Gaining Value From Sprint Retrospectives


Avoid Just Ticking The Box

When you and your team have been sprinting for a while, you need to make sure that your Sprint Retrospectives remain a regular event and don't become just a tick-box activity that fail to deliver any real value.

The Continuous Improvement Ethos

Agile has always embraced the Continuous Improvement ethos and hopefully your team does too.

Remember the Twelve Principles of Agile Software development? Principle 12 states: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly." (Strange how the Agile Manifesto itself hasn't been updated in years. Steve McConnell thinks 20 Years is Enough! It’s Time to Update the Agile Principles and Values.)

The Scrum Guide says that the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness and therefore supports principle 12 as a recurring reminder to drive continuous improvement with each iteration.

Whilst the focus of the sprint is often primarily on the business value of the potentially shippable product increment under construction, teams must not forget to also focus on the delivery of strategic value through the achievement of continuous learning and improvement. (See previous blog articles: Two Customers and Building People, Then Products.)

Plan-Do-Check-Act

The Scrum ceremonies map well onto the "Plan-Do-Check-Act" lifecycle with the Sprint Retrospective being intended as the "Check-Act" part of that lifecycle.

Doing too little or too much checking without taking any actions will make retrospectives feel unproductive and fuel the "why bother to contribute when nothing ever gets done" attitude within your team.

However, taking on too many improvement actions at one time can also introduce too much change too soon, causing disarray within your team if things don't quite work out as anticipated.

Encouraging Full Team Participation

Invite the Product Owner and their colleagues. They may choose not to attend (and that's sometimes helpful 😊) but it demonstrates the spirit of transparency which helps to build trust and confidence with your customer. After all, any views your customer has about what needs to improve are extremely important so why would you fail to ask them? Sometimes it's the customer that needs to improve too.

You may need to coach some of your "quieter" people outside of retrospectives to remind them to bring up a specific item from a prior conversation during the retrospective and may even need to prompt them on the day. Hopefully it will boost their confidence going forwards as well as start a useful debate.

Recently, someone raised a great point right at the very last minute of the meeting. None-the-less it was greatly appreciated.

Keep It Fresh And Fun

Sprint retrospectives can easily become stale if you don't make an effort to keep them fresh, especially if the continuous improvement ethos is not alive and kicking in your team culture.

Retrospectives can often take the form of a team discussion to answer three questions:

  • What went well?
  • What didn't go so well?
  • What or how can we improve?

Whilst these are helpful questions to drive useful conversations, using the same meeting format in the same location with the same people on each occasion can cause that "same old, same old" feeling to set in and take the edge off your good intentions.

It's helpful to vary the meeting format (and perhaps the person running the event) to keep things fresh and fun. There's nothing to stop you from communicating your intentions in advance so that the team can come prepared.

There are plenty of good books and websites discussing different approaches to retrospectives that you might want to try. (See Try One of These for example.)

Come Prepared

It's not enough for people to just turn up to a retrospective. People need to come prepared.

Many improvement opportunities are lost through lack of preparation. πŸ˜’

Relying on your memory usually isn't enough. I find that keeping notes throughout a sprint helps me remember what I observed and prepares me for the retrospective. Even the Sprint Review that precedes the retrospective can provide numerous feedback items and suggestions for improvements.

Preparation can be as simple as keeping a notepad on your desk (or a text file on your desktop) and simply jotting down notes as matters arise during the current sprint.

Before COVID-19, I sometimes stood at the doorway of the meeting room and wouldn't let people into the meeting until they could prove that they had done some kind of preparation. People soon got the message.

Come prepared to be challenged. Sometimes it can feel like a negative experience when the feedback isn't what you had hoped for or expected. Perhaps some complaints or criticisms were surfaced that will need to be addressed.

Beware Techniques That Discourage Full Team Involvement

Just because you invited everyone and they turned up is no guarantee that everyone will get involved and contribute!

Just like Planning Poker encourages everyone to estimate a story and disclose their estimate at the same time, make sure that you don't use an approach or tooling that allows others to see or agree with someone else's suggestions before submitting their own and that ultimately discourages full team participation.

Before COVID-19 forced remote working on our entire team, we would conduct our retrospectives in a large room with team members writing their comments on sticky notes and all posting on the wall at the same time. This approach encouraged everyone to participate and we were able to group duplicate items.

Switching to remote working and use of software tooling for capturing feedback, we saw the number of comments reducing and so had to re-consider our approach to boost participation.

Having a very large project team also reduced participation and so we opted to revert back to individual retrospectives per scrum team instead of using a combined project-level event with all our scrum teams.

Keep It Safe And Fair

People will contribute to the retrospective when they feel it is safe and when they are given the appropriate opportunity to do so.

Retrospectives should always be a safe place to discuss things with almost no topic off limit and with everyone having equal opportunity to voice their views, suggestions and/or concerns.

A "no names, no blame" culture should exist with the agreement that all feedback must be constructive.

Allow anonymous feedback if necessary but don't encourage this to be the norm.

Many improvement opportunities are also lost because of lack of involvement. πŸ˜’

Don't allow highly-vocal or overly-opinionated individuals to dominate the air time. Try to give everyone equal opportunity and time to contribute. By getting the whole team involved and contributing you'll be giving your team the best chance to surface all potential issues and suggestions.

Remember To Give Yourselves A Pat On The Back

Don't just see the challenges but also recognise your successes.

There are many benefits to positive affirmation so don't miss the opportunity to bolster team morale and point out the great work that's been done despite any challenges that the team faced. People love praise!

It's great to accolade people and highlight clear areas of improvement that have been achieved this sprint or that continue to improve from previous sprints.

Discussion Is Valuable But Time Is Limited

Sprint retrospectives are time-boxed and the duration typically equates to one hour per week of sprint (i.e. a two-week sprint has a two hour retrospective) but this time does not include preparation time.

Sometimes there will be a myriad of discussion points and simply not enough time to discuss everything. Whilst you might run out of time, it doesn't mean you have to drop everything and forget all the good discussion points that were raised. You should also avoid getting sidetracked by "low value" topics.

By taking note of the useful discussion points identified you can organise follow-up meetings to discuss some of them in more detail. (Lean Coffee meetings can be a useful way of achieving and prioritising that.)

Have A Strategic Roadmap

Lack of time is never a valid excuse for failing to improve.

Having a strategic roadmap can drive serious improvements over the longer term that may take several sprints to achieve. Recognise such opportunities and allow people to take ownership of them so that they can turn them into successful achievements.

Actions Speak Louder Than Words

To birth improvements means changing what you do and/or how you do it. (Strange how it takes some people longer than others to figure that out! 😊)

Sometimes there are so many suggested improvement actions that it's hard to decide exactly which to focus on and for this reason some teams restrict the choices by voting to decide the top three improvements to try out.

Some suggestions may also be more radical than others and really challenge the status quo. This can be innovation at its best or surface vocal confrontation from your resident change resistors! (Some people just don't like change. πŸ˜’)

Trialling different suggestions in different scrum teams can yield interesting results.

Breaking Chains / Killing Sacred Cows

As someone who has coached many Agile teams over the years, I've seen a whole range of reactions to suggested improvements: whether to ways of working, adoption of a new technique or switching tool choices and recognise that it can take a variety of approaches, and sometimes real people skills, to convince some people (or even a whole teams) to embrace change before breakthrough can happen.

Rome wasn't built in a day and I've seen many a change resistor eventually sing the praises of the very changes they once vehemently opposed. Sweet! 😊

As a result, my deep respect goes to those charismatic winners of hearts and minds knowing that disruption is only half of the battle! 😊

Record Everything

For an accurate record, don't dismiss anything out of hand but rather record all feedback, suggestions and agreed actions for posterity as well as the list of attendees.

Hold A Retrospective Of Retrospectives

Continuous improvement is an infinite loop. It never ends. It may even be recursive! πŸ˜ŠπŸ˜’

Reflecting on your retrospectives over time will help you determine and improve their effectiveness and is therefore a valuable exercise that I would recommend doing from time to time.

I'd also recommend the Spotify technique I saw some years ago called "Definition Of Awesome" where teams agree what "awesome" would look like for them and then work out their next steps to march towards it. (This technique works well alongside a strategic roadmap.)

Both can help you prove (or disprove) that you are really making progress. Good luck with that!

Agile Health Check - Sprint Retrospective

Why not take the opportunity to give your Sprint Retrospectives an Agile health check?

#AgileHealthCheck

Healthy
  • Team has a healthy continuous improvement ethos.
  • A sprint retrospective occurs at the end of every sprint.
  • The whole team (including the Product Owner and their colleagues) are invited.
  • Team has sufficient time for the retrospective.
  • Team prepares properly for the retrospective.
  • The sprint retrospective and preparation activities feature in sprint planning.
  • Retrospective meeting format varied over time to keep events fresh.
  • Meeting host assigned to oversee the running and documenting of the retrospective.
  • The whole team attends the retrospective.
  • All attendees contribute to the retrospective.
  • Product Owner and colleagues attentive and actively contribute to proceedings.
  • A "no name, no blame" culture prevails throughout the retrospective.
  • Attendees feel safe to speak openly during the retrospective.
  • Almost no topic is off limits.
  • Anonymous feedback is allowed but not the norm.
  • Meeting runs smoothly with all participants having equal opportunity to contribute.
  • Team assesses both the positive and negative aspects of the sprint.
  • Event proceedings and attendees are documented by the meeting host (supported by team).
  • On-line meeting recorded (if possible).
  • Both the team and customer gain useful feedback.
  • Retrospective identifies a number of opportunities for improvement.
  • All agree that the sprint retrospective was a good and valuable experience for all involved.
  • Team votes / agree which improvement items to take forward into the next sprint.
  • Follow-up meetings are arranged to further discuss important issues and improvement suggestions that arose during the retrospective.
  • Agreed improvements from the previous sprint retrospective were completed in the current sprint.
  • Team has a demonstrable history of improvement.
  • Team has a strategic roadmap to track and guide longer term improvements that may take several sprints to achieve.
  • Team periodically holds a Retrospective of Retrospectives event to validate and improve the effectiveness of their sprint retrospectives.
Unhealthy
  • Team does not have a healthy continuous improvement ethos.
  • A sprint retrospective is not held at the end of every sprint.
  • Not all of the team (including the Product Owner and their colleagues) are invited.
  • Team has insufficient time for the retrospective.
  • Team fails to prepare properly for the retrospective.
  • The sprint retrospective and preparation activities do not feature in sprint planning.
  • The same meeting format is used for each retrospective.
  • No meeting host is assigned to oversee the running and documenting of the retrospective.
  • Only part of the team attends the retrospective.
  • Only some of the attendees contribute to the retrospective.
  • Product Owner and colleagues absent or inattentive and contribute little to proceedings.
  • A "no name, no blame" culture does not prevail throughout the retrospective.
  • Attendees do not feel safe to speak openly during the retrospective.
  • Some topics are off limits for discussion.
  • Anonymous feedback frequently occurs.
  • Meeting rarely runs smoothly with some participants having no opportunity to contribute.
  • Team assesses only negative aspects of the sprint.
  • Event proceedings and attendees undocumented.
  • On-line meeting not recorded (if possible).
  • Both the team and customer gain little useful feedback.
  • Retrospective fails to identify many opportunities for improvement.
  • Few feel that the sprint retrospective was a good and valuable experience for all involved.
  • Team fails to vote / agree which improvement items to take forward into the next sprint.
  • No follow-up meetings are arranged to further discuss important issues and improvement suggestions that arose during the retrospective.
  • Agreed improvements from the previous sprint retrospective remain incomplete after the current sprint.
  • Team has no demonstrable history of improvement.
  • Team has no strategic roadmap to track and guide longer term improvements that may take several sprints to achieve.
  • Team does not periodically hold a Retrospective of Retrospectives event to validate and improve the effectiveness of their sprint retrospectives.

Like

Tim Simpson
14th January, 2022
#LifeAtCapgemini

« Previous Blog Post Blog History Next Blog Post Β»