Should You Share Details from the Retrospective?

During a sprint retrospective, team members gather and discuss ways in which they can improve. This should include the ScrumMaster and product owner, as each is part of the team. The team is not limited to finding improvements only within their process. They may, for example, decide they need to improve their skills with a given technology and to seek out training in that area.

A concern many teams have around the retrospectives is whether the improvements they identify should be shared with others or kept within the team.

I think it’s ideal when all retrospective results from all teams can always be shared. Transparency is, after all, a pillar on which the Scrum process is built. But as much as I would love a culture of openness to exist such that everything can always be shared with everyone, that is often not the case.

In my experience, most teams will have no issue making public most of the improvements they identify. The items will be predictable things often similar to those being done by other agile teams in the organization: get better at this, learn how to do that, figure out how to do more of this and how to do the other thing earlier each sprint.

Occasionally, however, a team may have something they don’t want to share. Some examples I’ve seen include:

• Learn this new technology that is a bit astray from a stated corporate direction, but which the team thinks may have enough promise that they’d want to use it anyway
• Clean up the code in this part of the system, which the product owner is aware of, but for some reason, they don’t want to advertise is bad enough that it needs significant refactoring
• Find ways to work better with that other group, who if they read this would want to know why they were being singled out for a better relationship

I want to repeat that while transparency is a virtue for agile teams, not all agile teams may be there yet. While perhaps keeping the results of their next few retrospectives private, those teams can work on feeling more comfortable opening up in the future.

Similarly, sometimes making a planned improvement known can impact the ability to make that improvement. I think that’s the case with the last example above.

Posting that you want to work better with the marketing group may make the marketing group either resist the change, or want to know what’s wrong with them that you need to change.

(Of course, they could also be quite open to changing to improving the relationship, so I would always discuss the situation with someone in the other group.)

Making this very practical, at the end of each sprint, the team has a list of changes they have agreed to make. I like to ask the team if there are any objections to making the list public. If there are not, I will hang the list in the team room or add it to the team’s home page.

When there are objections, I will see if we can leave perhaps one item off the publicly displayed list—usually that’s sufficient.

In the end, Scrum teams should have the courage to be transparent about their planned improvements whenever possible. But, occasionally there is more to be gained by keeping a retrospective item or two private.