2

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?

5
  • 5
    It sounds like you want to use the retrospective to present an agenda of process changes. I think the retrospective should be for the team to discuss what's going right and wrong.
    – DaveG
    Jul 4 at 22:36
  • Thanks for your comment, @DaveG. In that case, what steps could I take to encourage discussion amongst the team concerning process changes? I think everyone agrees the process needs to change but we might not agree on how it should change.
    – RoboBear
    Jul 4 at 22:47
  • 2
    "[Inspect] how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done." The agenda itself is provided in the very definition of the Sprint Retrospective. However, implementing the agenda well is more challenging, so while I think your question hints at a bit of an X/Y problem, I think it's a very legitimate (and very common) Scrum implementation issue, and therefore worthy of careful analysis in the answers your question will generate.
    – Todd A. Jacobs
    Jul 4 at 23:12
  • @RoboBear: you mention processes, workflows, and work assignments, but you don't mention how you are currently doing the developments. Are you using a traditional approach? Scrum? Something else? As Todd A. Jacobs mentioned in the comment above, this might be an X/Y problem. You are talking about solutions, but you don't mention the problems you are trying to fix with all of these ideas.
    – Bogdan
    Jul 5 at 9:38
  • @RoboBear the retrospective is a good place to discuss process changes, but it should be a discussion among the team, not a place for one person to lay out an agenda of changes. Everyone should be bringing up what's working and what isn't working, and from that the team can get consensus on changes to make.
    – DaveG
    Jul 5 at 16:54
5

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!

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.