Offline / Async Retrospectives

Is the team identifying and implementing at least one actionable improvement each Sprint?

Is the team identifying and implementing at least one actionable improvement each Sprint?

This is no longer a mandatory action according to the latest scrum guide, so it should not matter if they are doing this or not.  Of course, it would be great if they do, but perhaps some sprints have no space for team improvement PBIs. 

I just started working with a distributed, wfh, Agile Team that is running Offline Retrospectives. They have is a Confluence page where everyone can share their thoughts on the last Sprint, whenever it suits them.

As the sprint retrospective is a time boxed event and should be run at the same place and time each sprint (ideal world scenario), I would say that just because the team are WFH, this should not prevent them from having online events. 

I kinda like the idea of having such a site. But will it realy be read by the whole team? Do they start discussions on it?

I like such collections of feedback and use that sometimes, I also do some one-on-one calls with the team members every now and then, where I also collect feedback. But we still have Retrospectives so that we have a discussion in the team on those topics and can find a team decision.

The Scrum Guide says:

The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.

My advice is to consider carefully how well the team is doing so. If at least one improvement isn't being actioned in the next Sprint, ask why the timeboxed opportunity presented by a Sprint is being lost. Is the team's use of Confluence effective or constraining in this regard?

I have several concerns with asynchronous retrospectives.

The first thing that I'd want to do is what Ian suggested - make sure that the team is able to identify potential improvements, choose at least one, and plan to implement it. If the team is not able to identify, plan, and implement improvements to the way they work, then the Sprint Retrospective is not achieving its goals and how its conducted needs to be looked at. However, if they are, there are still some remaining concerns.

A frequent concern when using electronic tools is the privacy of what people said. In order to be effective, people need to feel safe and comfortable to freely share their thoughts about how the team is doing. For electronic tools that attribute content to individuals, it could be more difficult to achieve that. Using Confluence as a specific example, there are ways to protect the page from viewers outside the team to increase that confidence. I'd still want to check in with the team to make sure that they feel comfortable expressing their thoughts.

Anything that is done asynchronously has some complexity over things done synchronously. One of the Agile principles states that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation." More recently, "face-to-face" has been interpreted as meaning "real-time, high fidelity" rather than "physically in the same space", as technology has advanced. The reason for this is that it is faster to share information and make sure that all parties have a shared understanding. Holding a retrospective asynchronously may need back-and-forth as people ask questions or clarification for points people are making. Developing this mutual understanding of the problems facing the team and how to solve them is a key aspect of retrospectives, but it will take longer and be more difficult if it's done asynchronously.

There are some asynchronous techniques that can support a retrospective, but I would generally push teams to hold at least some aspects of it synchronously. However, if the techniques are working for the team, it wouldn't be at the top of the list for potential changes - solving actual problems should take priority over improvements to processes that are already working.

I'm really impressed. Thank you guys for such good points and suggestions. I agree with all the Pros and Cons you mentioned.

The Team I joined makes synchronous retrospectives from time to time, whenever they can, at the end of the Sprint, but that Confluence page must be populated in advance with everyone's thoughts. Then during the meeting, we read all the ideas and discuss them. At the end of the meeting, @Ian Mitchell: yes, there is always at least one action to take.

I'm not a big fan of that kind of meetings, but I'd like to mention some other benefits:

• It may work well for teams that are spread across diverse time zones
• Team members have more time to reflect and freedom to contribute when it suits best.
• The Retrospective outcome is documented automatically.

I wanted to make sure it's not an antipattern.

I'm looking forward to getting more feedback from the community.

I'm in favor of giving the team the opportunity to share their thoughts in advance. This is something that I've done with teams - at the start of the Sprint, making a page in Confluence for the team to make notes to help them remember the Sprint during preparations for the Sprint Review and Sprint Planning.

I'd just be careful to not make it mandatory. People shouldn't feel like they have to put something on the Confluence page with their name attached and visible to who-knows-who in the organization. As long as people are able to bring up other thoughts or views during the Sprint Retrospective, it's probably fine.

Ultimately, what does the team think? Are people comfortable using the tools? Does it help promote a good Retrospective? Is the team able to achieve the intent of the event? These are the important questions.