Retrospectives must produce change

Aired on A Journeyman’s Travels Podcast on March 31, 2023
These are the notes from which I recorded the show. They’re a little unpolished since the original audience was just me. But I’ve added some of the reference material that I allude to in the podcast and post it here, should anyone want to ‘see how the sausage is made’.

Show Notes

Intro

• Welcome
• Last time we discussed that Retrospectives must be intentional, which encompassed BOTH pillars of Scrum (Inspection and Adaptation)
• The next principle of Retrospectives is that Retros must produce Change

Change Occurs outside of the Retro

• Now when we say change, let’s be clear: By change, we mean a change in performance or behavior of individuals or the team.
• But that points to two curious elements: the change produced by a retrospective actually occurs OUTSIDE the retro, and while the TEAM might select Changes to pursue, the actions are actually taken by the individuals.
• Firstly, whatever we choose, those behaviors happen outside the meeting where the idea came up.
  • these behaviors will have to occur either in place of existing behaviors or in addition to them , during normal day-to-day work.
  • As a result, we need to keep in mind the capacity these new behaviors will take from our team to adapt to them.
  • We also need to think about how we’ll monitor, and check on them again next time. That is the improvement today, must be checked in the NEXT retro.

Experimentation does not always produce positive results

• The model I’ve used for this comes from the idea of Hypothesis testing.
• Since Scrum rests on the idea of evidence based management, the idea discovering improvement by hypothesis testing seems a natural fit.
• Most Action items naturally flow into this: ‘Let’s try this’ almost always comes from some thing the team wants to fix
  • Just capture some of the details in writing:
    • What are you trying to improve
    • What are you trying
    • How long will you try this new action?
    • How will you know you made it worked?
• But lets walk into this idea with eyes wide open: Not all of our changes are guaranteed to be improvements.
  • Certainly MOST of them should be.
  • But the idea that we’d only hit endless peaks is naïve, and sets us up for a lot of disappointment.
  • Moreover, a change could produce positive results, but be so difficult to keep up that it wasn’t worth the trade. And that’s ok!
  • So the nature of the results, AND the cost to achieve them should BOTH be monitored

Change won’t be the same for each member

• Speaking of monitoring and evaluating changes, How can we tell if a change was positive or negative?
  • We need to evaluate it against SOME standard, some Goal out in the distance to measure our position against.
  • If my goal is ahead of me and to the right, moving forward is ok. Moving ahead and to the right is better, but moving to the left is not good!
  • … But who is it we’re trying to moving?
• The TEAM needs to progress towards the goal.
  • Certainly that means that the individuals are moving towards that goal too…
  • But if a Change is an altered behavior… do ALL the members of the team make the same change?
  • Absolutely Not!
    • Everyone on the team has contributions they make, most often defined, at least initially, by their role: Dev, QA, PO etc.
    • The TEAM needs to get where they’re going, but for us all to get there, every INDIVIDUAL must be accountable for their own work, and actions.
    • Now stuff happens, and so team mates can jump in to help the critical work get through on time.
    • But thinking of changes in behavior, especially when it comes to changes about how the team works together, there will always be complimentary behaviors being discussed.
      • For example, if a team wants to improve throughput, by reducing the burden of testing on QAs, so that things flow smoothly, the team MIGHT have the QA focus on setting up test document templates to improve their work. AND the team might at the same time shift some of the burden of TESTS into Unit Testing, which would be carried by the developers.
      • The Team goal of Flow and Throughput produced 2 different actions for different groups, which when executed TOGETHER would yield the change in the TEAM’s performance, moving towards the goal.

Outro & Summary