There are lots of ways to do Sprint Retrospectives (I still like the old Post-Mortem name myself) — what did you learn, what did we do well, what should we do in the next sprint — or there is also the 3L what did we Love, what did we learn, what do we Lack?
Whichever model you subscribe to, they all follow the same pattern— look at what you did, decide whether you should change anything, and apply those changes.
Unfortunately, none of those structures make for a good sprint retro, let alone a great one. They structure the discussion but they don’t ensure that it generates any value to the team and that is the number one goal of any activity in your software delivery practice — do things that generate value.
A Great Sprint Retro is one that the team wants to have, is there to discuss, and the team doesn’t want to see it drop off their calendar.
Instead of focusing on the structure, what we need to focus on are the behaviours we want to see each and every time — Honesty, Trust, and Humility.
That’s it — if I could make it into a cool acronym, I would, but I can’t (HTH sounds like I’m spitting it out).
Think back to when you did your first Sprint Retro it was probably your longest one as the team “figured it all out” and got all that structure…
