Retrospectives improve the health of agile teams. Actions your team takes, as a result of a sprint retrospective, will make your team more productive and happier. In this post, you'll learn 6 ways to help your team get the most value from its sprint retrospectives.
Whether new to agile software development or a skilled practitioner, you've probably participated in a retrospective. The ceremony is part of every agile team's calendar. However, in terms of the benefit you and your team receive, mileage can vary. Like any activity you perform with regularity, sprint retrospectives can become stale. More seriously, your team might have obstacles in its path, like a lack of trust among team members, which keep you from getting maximum benefit.
Why your sprint retro is important
Software development is about delivering change. It stands to reason -- when delivering any change -- you want to do it with as much quality, speed, and precision as possible. Your team is working with a lot of moving and changing parts:
- New or broken technology
- New or changed stakeholders: product owners, user groups, security, compliance, and other
- New or changing team member roles
- New team members or fewer team members
- New product direction
- Changes to interpersonal dynamics
Sprint retrospectives allow you to reflect on recent experiences and quickly adapt to new inputs while they're front-of-mind. They force you to inspect the health of your team, and help you capitalize on opportunities to increase your team's effectiveness, so the next time you do something, you'll do it better.
1. Invest effort in building trust
It's a misconception that, feedback provided by team members during a retrospective can be anonymous. This is untrue and has more to do with tools used to facilitate retrospectives than it does with the intent of a retrospective. You can use an online tool, like FunRetro, to facilitate your retrospectives. It lets team members submit feedback anonymously. But, if there's not enough trust on the team to actually talk about it, the feedback isn't actionable.
If a Scrum Master reads aloud something that didn't go well, and no team member speaks-up to own the feedback, that's a sign of lacking trust. The silence is actionable for the Scrum Master. S/he should respond to the silence by asking the team for ideas to build trust. They may answer with requests for peer-to-peer programming, team building exercises, or other. Regardless, the team's input should make it to the Actions column.
You're not looking for any long-term commitment. Instead, you're looking for things to experiment with, things the team thinks could build trust among team members. Later, the team will decide if they should continue running or iterating on a given experiment, based on whether or not it delivers a positive result. As a facilitator, the Scrum Master will have a test of their own. As trust increases, silence will decrease during future retrospectives.
2. Use an online tool
If your development team members work from a single location, you're fortunate. You can give preference to in-person sprint ceremonies over remote ones. Even when your retrospective is in-person, you can use an online tool to collect individual feedback during the sprint retrospective.
Ask your team members to bring their laptops to the retrospective. Then, display the retrospective tool of your choice on a monitor, where the entire team can see it. Now, using their own laptops, instruct the team to provide their feedback: what went well and what didn't go well.
Use of an online tool gives individual team members privacy while writing feedback. It doesn't change the sentiment of any feedback. It avoids the pressure of being on-the-spot; to publicly and quickly word sentiment in a way that's perfect. Most team members want to provide honest feedback. At the same time, they don't want to hurt anyone's feelings and might want to carefully word their comments. Using an online tool lets them do that. As a result, more sharing occurs.
3. Limit observations of your sprint retrospective
Agile invites observation. Sometimes called a go-and-see or Gemba walk (in Lean terminology), observations give leaders visibility into how their agile teams are performing and increases comprehension about challenges they might have. They give other observing teams ideas which they can bring back to their own sprint ceremonies.
Make no mistake. Observation is great. Healthy organizations encourage lots of observation. Sprint retrospectives are different though. An agile team needs to be operating with a high degree of trust to let someone observe their retro. Otherwise, there's risk that the observation will render the retrospective ineffective.
Few people like to air their dirty laundry in public. Effective retrospectives have a feature; they expose dirty laundry. The team needs to be in an environment where they're comfortable talking about it. Teams observed during their retro have a habit of watering down their experiences and making them appear more rosy than they are. The sprint retrospective is more personal than other agile ceremonies and must be treated as such.
When visiting a zoo, you're not viewing animals in their native habit. You're viewing them in your native habitat, which has been made to resemble theirs. You don't see animals as they would behave in the wild. The behavior you observe is conditioned to the environment in which the observation is occurring.
You can allow people to observe you sprint retrospective, but you should only do so infrequently. Do not allow consecutive retros to be observed.
4. Restrict access to the sprint retrospective page in your wiki
Many agile teams document their retrospectives in a wiki, and many wikis are open to the public. The directory with notes for your team's retrospectives should be restricted.
If your team's retrospective notes are surfaced as organic search results in a wiki, that will put your team in an uncomfortable spot. There may be notes that aren't fit for public consumption. Those notes would be viewed without any context, possibly by people who will take offense to them. Don't let strangers read your diary, unless you're comfortable explaining it. Chances are, not everyone on your team will be comfortable with that much public sharing. If they know that's going to happen, they will share less.
5. Track retrospective action items in the right place
Generally speaking, your sprint retrospectives will produce two types of actions: behavior changes and activities. Teams often store notes related to both types of actions as notes in a single location. It's fine to keep behavior changes with your retrospective notes in a wiki, but it's not the right approach for activities.
Behavior changes
Behavior changes modify how you do something. They don't introduce anything which requires specific, additional committed effort. For example, a team might want to change the questions asked during scrum or how its demos are run. Maybe the team wants to move its scrums to an earlier time in the day.
It's valuable for the team to answer, "Did we do this, and did it have the impact we intended?" However, since behavior changes aren't effort-driven, they don't merit inclusion in a backlog. They can simply be referenced in the team's wiki notes for the retrospective.
Activities
Activities require action. During a retro, a team might decide that automated test coverage is lacking, and the lack of coverage makes them slower and more hesitant to release. That's technical debt. It needs to be more than a note in the wiki. In fact, the related action items in the retrospective notes should instruct someone to add work items to the team's backlog.
During a sprint retrospective, a team might recognize a knowledge gap had pertaining to a needed CICD tool. Closing the gap will take time and effort. That too must be included in the team's backlog.
The team's work all needs to reside in one place. That's the backlog. If the work doesn't exist in the backlog, it might as well not exist at all. It won't get done.
How can a retro be private if work items go in the backlog?
It was argued earlier; the team's privacy should be protected. Observations of retrospectives should be limited. Notes taken during retrospectives should be kept in a private location. Backlogs are inherently public though. All true.
The team's conversation and notes should be kept private. Work items in the backlog are different though. They are stripped of emotion. For example, during a retro, a team member might express personal frustration about a lack of test coverage. That sentiment would be kept private. The work items reflected in the backlog would be without emotion or frustration. They'd only describe the work that needs to get done: objective and testable.
6. Act on retrospective feedback in every sprint
Action items captured during your team's retrospectives must be incorporated in your team's sprint planning. This is important for two reasons.
First, action items often relate to capability building and paying down technical debt. Both deserve effort investment. If unaddressed, they result in frustrated teams and slower, lower quality releases. Teams that don't spend 20% of their time paying down technical debt will spend almost all their time serving it. Your sprints are where your team defines the work it intends to complete. If you want your team to take real action on feedback captured in your retro, it needs to be in your sprint.
Second, giving honest feedback can be uncomfortable. In your sprint retrospective, you're asking team members to step out of their comfort zone and to not sugar coat things. In exchange for that, they want to see some action taken as a result of their personal risk. If they don't see any action, the'll be less likely to provide honest feedback next time you ask for it. This is a quick way to lose your team's engagement in retrospectives. Trust is easier to lose than it is to earn.
When you add stories to your sprint, based on insights gained during your sprint retrospective, that's powerful. Tag related stories and tasks in your tool of choice, be it Jira, Trello, or something else. Then, talk about the results and ways to improve them during your next sprint retrospective. Your team will appreciate it and is guaranteed to contribute more ideas. You're regularly taking action on their feedback, and you're constantly proving it to them. It's the foundation of a self-reinforcing system of continuous improvement.