Using Retrospectives to Influence Process

Question

I've been encouraging my current team to adopt process and workflow changes to be more agile. We have our first retrospective coming up and I'm looking for some advice on how to conduct the retrospective in an encouraging way that influences people to adopt at least some changes.

I've spoken to other devs and our QA guy and the team manager about their thoughts and experiences. So far there seems to be some common agreement on positive changes but also not a lot of experience with Agile process or workflows.

Among the suggestions I think have common ground with multiple teammates are:

• using tickets for assignments, where tickets are prepared with all required information before assignment
• adding more statuses to our JIRA tickets so that anyone can reference a ticket to get the status appropriate to our workflow
• limiting work assignments to the current sprint except for emergencies (emergencies are defined by PMs or team lead)
• setting up more than 1 staging environment for concurrently testing features

Aside from talking to teammates about common ground and their concerns and experiences, how should I go about conducting the actual retrospective with the rest of the team?

Assuming we can keep doing periodic retrospectives, what is some advice for making the best use of retrospectives to push even incremental changes to our process?

Answer 1

Successful Retrospectives are for Communication and Collaboration

Setting aside the fact that at least some of your agenda items seem like they are intrinsically Scrum anti-patterns (please ask why in a separate-but-linked question if you really want to know), you and the team are approaching the Sprint Retrospective event incorrectly by treating it primarily as a procedural or tool improvement exercise. While that's sometimes the end result, it's not quite the point of the event.

The 2021 Scrum Guide explains the purpose of the retrospective quite clearly, but I've bolded some elements for emphasis:

The Scrum Team inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done. ...Assumptions that led them astray are identified and their origins explored. The Scrum Team discusses what went well during the Sprint, what problems it encountered, and how those problems were (or were not) solved.

In other words, the goal of process improvement doesn't start with a bulleted list of fixes. Instead, it's an exploration of the whole-team process, where the team strives to identify what went well (so they can do more of those things), and what didn't go so well, so that the whole team can collaborate on process solutions that can be agreed upon, tested, and measured.

While it's certainly a good idea to try to identify something actionable in a retrospective that is likely to lead to tangible process improvement, it's actually the communication and collaboration within the team that creates the opportunity to learn, grow, and continuously improve as a team. By going into the Sprint Retrospective event with a list of potential solutions, rather than a format where the team feels safe in honestly and collectively identifying muda, mura, and muri, you've already hijacked the real value of the event (whole-team collaboration and a willingness to inspect-and-adapt together) and replaced it with a pre-digested solutioning exercise. Don't do that!

Answer 2

I'm assuming you are using Scrum.

For a team that is relatively new to Scrum, the initial few retrospectives are more about learning to solve problems themselves than actually solving lots of problems.

Are you in the Scrum Master role? If you are, then you could research some potential retrospective formats. Probably the most common of these is to gather feedback on the sprint from the team, group similar feedback together and then have the team vote on which topics they want to discuss first.

The key here is for the team to develop a pattern of identifying their problems and then proposing solutions for them. In the Scrum Master role you can often help with this by providing them with information. For example, you might say something like:

"We've had quite a few issues with the staging environment this sprint, I counted 4 and they were disruptive. It may be worth considering this with your feedback."

To be clear here, you are not setting the agenda for the meeting. Instead you are providing input for the team to consider. It is important the team gets good at recognising problems, so having issues spoon-fed to them isn't ideal.