Don’t Skip the Retro!

The Scrum Guide defines the sprint retrospective as “an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.”

The Sprint Retrospective, or “Retro,” is a Scrum Event that occurs at the end of every Sprint. During this Event, the Scrum team talks about the previous sprint – what went well and what can be improved – and then adapts their team processes, based on what is uncovered in that discussion. It is this consistent cycle of inspection and adaptation that creates a high-performing team. Unfortunately, this is the one Scrum Event that many teams (or worse, leadership) want to skip.

However, I am begging you: Please. Do. Not. Skip. The. Retro. Seriously. Don’t do it!

However, let us consider the common reasons (read: excuses) a team may be given for skipping the Retro.

1: “I don’t have the time.”

This excuse indicates that a team is somehow doing Scrum “wrong.” If the implementation of Scrum is not done “by the book,” the team will always feel like they do not have enough time and they are not focused. While every Scrum team does have the time – it is built into the framework – team members who are being pulled in many different directions have non-Scrum issues which need to be resolved.

A bit of inspection and adaption is exactly what is needed in the case of team members who are not 100% dedicated to your Scrum Team and backlog - no context switching!

As a Scrum Master, you must cultivate relationships with the people your team members report to (more on this later). These managers feel they can pull people off their teams to work on urgent matters (thus, forcing them to context switch). The better the relationship you have with them, the easier it is to have the difficult coaching conversation to let them know how destructive this is for the work being accomplished.

2: “I don’t want to talk about my feelings.”

Scrum Masters have an incredibly important duty to foster trust in the retro itself, ensuring it is not used for gossiping, ambushing, or the solicitation of soliciting information for malicious purposes. The retro can (and usually will) bring up “touchy” subjects. Many people are not comfortable talking about their feelings in the workplace and many organizations are still steeped in a rigid, corporate structure, which can lead to a culture of fear.

In this kind of setting, innovation and experimentation are likely discouraged because they disrupt the status quo. When the desire to express oneself through work is stifled, a reluctance of expression is created. Team members do only as they are told, focusing solely on delivery, throwing their desire to be creative right out the door. The retro is scary since no one is willing to be open about their feelings.

In a culture of transparency, the open discussion of failures should be encouraged. Team members who have each other’s best interests in mind will start holding one another accountable for bad behavior or poor performance. The Scrum Master works hard every day to establish and foster this trust, influencing team members in each Daily Scrum and other event. At the Retro, the Scrum Master should encourage this trust and keep anything and anyone which could potentially impede open and honest communication outside of the Retro (and team events).

3: “My boss said I could skip it.”

Scrum Masters know they are the “boss” since they are responsible for ensuring that the team is optimally practicing the Scrum framework. That means no one on the team should be working on anything outside the product backlog - plain and simple.

When a team member’s resource manager (e.g., boss) asks him or her to work on something that has not been prioritized by the PO and/or pulled in by the team unanimously, it is a Scrum anti-pattern. The first way to remedy this is with education - politely teach the offending manager the principles of PO prioritization.

In this scenario, respect is tantamount because it is imperative you establish and cultivate a relationship with your team member’s manager(s). One suggestion is to setup a coffee date with each manager where you can get to know them. Ask how long they have been immersed in agile culture. Try to get a sense of how supportive (or not) they are of the Scrum framework. Ask if there are situations when it is appropriate to throw process out the window for the sake of [insert reason here]. Let them know you are not there to manage their people but, rather, to help support the Scrum process. Positioning yourself as a partner and not a hindrance will go a very long way. It is your job to coach the people at this level in the organization on how Scrum works and why it works.

This relationship may be critical later, in the case when you may have to deal with a “hero” team member who cannot stop himself or herself from committing to tasks outside of the Product Backlog. In this case, your relationship with that person’s manager can be used to your team’s advantage.

4: “We’re a mature team with nothing else to improve .”

This is most likely a red flag of team immaturity. Any mature Scrum team understands the intrinsic value of the retro and would never suggest to opt out of it. Anyone who believes there are no possible improvements – either at the team or individual level – is delusional. We can always improve our processes. There are situations where teams can become so good at Scrum that they no longer need a Scrum Master, however, at this rare “unicorn” stage, everyone on that team becomes Agile change-agents. In that mindset, not one of them would ever recommend that retro is no longer needed.

If someone on your team suggests this thought, take the opportunity to get to the root of their belief. Ask them why. Ask if they value the Scrum framework and ask the purpose of the Retro in their view. Is it something as simple as the same issues are being reported repeatedly without resolution? If so, identify why the issues are not being resolved and discuss what could be done. If the standard amount of time is too much, perhaps a negotiation on length could be a compromise. Do they just need a change of scenery? Perhaps retros can be held at a different happy hour spot for the next two months.

Take the time to find out why the Retro is not being given the weight of its importance and adapt to that input.

Conclusion

When anyone, at any time, suggests skipping a retro, get to the root of why the suggestion is being offered. There is always an underlying reason why someone wants to skip this valuable event. Once you find out why, use the combination of your Scrum knowledge, plus these suggestions to help that person understand why the retrospective is so important. We are all in this together – it is a journey. Be kind, while being a Scrum advocate and teacher.