5.2 KiB
8 tips for better agile retrospective meetings
I’ve often thought that retrospectives should be called prospectives, as that term concerns the future rather than focusing on the past. The retro itself is truly future-looking: It’s the space where we can ask the question, “With what we know now, what’s the next experiment we need to try for improving our lives, and the lives of our customers?”
What’s a retro supposed to look like?
There are two significant loops in product development: One produces the desired potentially shippable nugget. The other is where we examine how we’re working—not only to avoid doing what didn’t work so well, but also to determine how we can amplify the stuff we do well—and devise an experiment to pull into the next production loop to improve how our team is delighting our customers. This is the loop on the right side of this diagram:
When retros implode
While attending various teams' iteration retrospective meetings, I saw a common thread of malcontent associated with a relentless focus on continuous improvement.
One of the engineers put it bluntly: “[Our] continuous improvement feels like we are constantly failing.”
The teams talked about what worked, restated the stuff that didn’t work (perhaps already feeling like they were constantly failing), nodded to one another, and gave long sighs. Then one of the engineers (already late for another meeting) finally summed up the meeting: “Ok, let’s try not to submit all of the code on the last day of the sprint.” There was no opportunity to amplify the good, as the good was not discussed.
In effect, here’s what the retrospective felt like:
The anti-pattern is where retrospectives become dreaded sessions where we look back at the last iteration, make two columns—what worked and what didn’t work—and quickly come to some solution for the next iteration. There is no scientific method involved. There is no data gathering and research, no hypothesis, and very little deep thought. The result? You don’t get an experiment or a potential improvement to pull into the next iteration.
8 tips for better retrospectives
- Amplify the good! Instead of focusing on what didn’t work well, why not begin the retro by having everyone mention one positive item first?
- Don’t jump to a solution. Thinking about a problem deeply instead of trying to solve it right away might be a better option.
- If the retrospective doesn’t make you feel excited about an experiment, maybe you shouldn’t try it in the next iteration.
- If you’re not analyzing how to improve, (5 Whys, force-field analysis, impact mapping, or fish-boning), you might be jumping to solutions too quickly.
- Vary your methods. If every time you do a retrospective you ask, “What worked, what didn’t work?” and then vote on the top item from either column, your team will quickly get bored. Retromat is a great free retrospective tool to help vary your methods.
- End each retrospective by asking for feedback on the retro itself. This might seem a bit meta, but it works: Continually improving the retrospective is recursively improving as a team.
- Remove the impediments. Ask how you are enabling the team's search for improvement, and be prepared to act on any feedback.
- There are no "iteration police." Take breaks as needed. Deriving hypotheses from analysis and coming up with experiments involves creativity, and it can be taxing. Every once in a while, go out as a team and enjoy a nice retrospective lunch.
This article was inspired by Retrospective anti-pattern: continuous improvement should not feel like constantly failing, posted at Podojo.com.
[See our related story,How to build a business case for DevOps transformation.]
via: https://opensource.com/article/18/3/tips-better-agile-retrospective-meetings
作者：Catherine Louis 译者：译者ID 校对：校对者ID