The Wrong Impression about Retrospectives
People get the wrong impression about retrospectives. They read that it’s a meeting where you list what went well, what didn’t, and what you want to change. They describe it like this:
The Sprint Retrospective is an opportunity for team members to bring up anything about the Sprint they feel needs improvement. For example, a team member might say he felt he had to complete work that should have been completed by another team member. Or a team member might say she received emails constantly which prevented her from getting any work done….
Or like this:
The format is a discussion and brainstorming. The ScrumMaster facilitates the retrospectives and let the team choose what aspect they want to improve for the next Sprint. Because the team is very technical, most of the discussion revolves around improving engineering practices, i.e latest frameworks, continuous integration, BDD, etc. Improvements get accomplished. But the point is the team thinks that rather than allocating special time to do retrospectives, they said why can’t they just do that within the sprint? The team gets the idea from Kaizen that is implemented in Toyota where the team gather in an instance to find a way where they can improve rather than going to a specially allocated sprint retrospective.
I’d like for you to consider that neither of these describe retrospectives. While a retrospective may help you solve a problem or improve the way you work, not all problem-solving or process-improvement is a retrospective. The team described in the second quote above is quite right. This sort of process improvement should happen all the time, as things are noticed. Don’t wait, as does the team in the first quote, until a special meeting to bring up issues that you notice.
Please do discuss improvements within the team as you think of them. But don’t assume that, if you do so, you won’t need retrospectives. The truth is that you’ve probably not experienced a retrospective. If you do retrospectives well, you’re very likely to discover other improvements beyond those that you notice in your daily work.
Great post; it’s one reason I really like using the format laid out in Esther Derby and Diana Larsen’s Agile Retrospectives; it focuses on identifying some root-causes, analyzing what can be done about some of them, and selecting 1-2 for action. If you can’t take action on a root-cause, the action becomes to bubble it up for action and then to still find 1-2 actions you can do.
While I know many use the what we like, what we want to change, and then select 1-2 from those, I personally feel that these forms of retrospectives don’t offer deep enough insight nor commitment on the action(s) to be taken.
If neither of those things (which yes, I hear quite often) describes retrospectives, then what is a better description?
Kevin, check back tomorrow.