Can retrospectives be made leaner?
The <enter time period> ends and a retrospective is held. The team writes on Post-It notes things that are important to them and they get stuck up on the wall. And maybe they get grouped into similar topics or themes. And then the team vote on them; the topic that has the most votes is the one the group talks about first…. and they talk about that topic at length. (If you were to analyse the signal to noise ratio of the first topic discussed compared with the last topic discussed, you’d find significantly more noise when you start). Actions to resolve the issues are finally addressed and identified. The team then move on to the next topic and so on until all the topics that had votes against them are done. And it’s been a marathon session and we are done.
But what about the topics that no-one voted on? What about the post-it that sits alone? It was important enough for someone to have written it. No votes, no priority, no discussion, no action. Yet mining it might have delivered a diamond action.
I don’t care much for voting in retrospectives. It’s not a particularly efficient way of doing things. For one because the actual process of voting takes up valuable time. Then by the time the issue with the fewest votes comes up, the energy in the room is drained and the discussion is rushed. So why not do away with the voting, and introduce strict time management to the retrospective discussion. Allow five minutes to each topic. Use a stop watch to enforce this. This will allow all the issues that were of importance to someone to be aired. When the five minutes is up, if there is still heat in the discussion, park it and return to it later in the retrospective. Such an approach is more incremental, and dare I say it, Lean.
I agree whole heartedly. Not long ago I was on a project with 30 members, and during the retrospective the team came up with about 30×5 = 150 post-it notes, of course a good number of them were overlaps, but they were at least 50 unique recommendations.
After sorting through the post-it notes, grouping them, and filtering out duplicates we would vote. The entire voting process took a ridiculous amount of time – in the end only 5 of the post-it notes got discussed. And the ones that did get discussed were invariably from teams with more players(members), this leaving the smaller teams (in this case it was the UE team) feeling even smaller.
I think post-it notes for retrospectives doesn’t really work. A better alternative would be to go around the table, letting people voice them instead- for sure, it gets rid of duplicates, and also hearing one persons recommendation can lead to another – helping you collaborate more effectively.
Yeah.
If we are a team and we have a shared goal, then shouldn’t talk in a retrospective be linked to achieving the goal? If so then, votes don’t really count for much. An issue either assists or impedes achieving a goal and that should be the basis of a topic’s worthiness. If you can’t link the topic to the goal, then don’t bring it up. If you care about the topic then have an argument ready to link the issue to the goal.
I can honestly say that every retrospective I have been in on a team of >10 members, >70% of the time has been spend listing issues to discuss and 10 then try to solve that problem first. In small teams that I have been a part of, every day can be a retrospective. If the team is bothered/impeded by something they deal with it over beers that evening, or at lunch or at the stand up.
In bigger teams, you owe it to the team to gather some evidence to support your arguments about what is working or needs to change. There just isn’t time for 30 people to express opinions based on how they feel about acceptence tests or whether or not they like to pair. If you want your issue to carry some weight support it by showing me a chart of data collected on team performance, or canvasing the team before the retrospective, or pointing to some literature.
Maybe I am jaded by retrospectives, but I have have seen too many retropectives come and go with no concrete change to let this post go by without throwing in my 2 cents/pence.
“Lean” isn’t really the right word here. I think “Could retrospectives be made more effective?” is less buzzword-y and therefore has more clarity.
I’m not sure about this as the voting scheme I typically recommend is very fast and I don’t see a need to talk about everything raised in the retrospective (because I don’t see the retrospective as the only medium for improvement).
However, I do have a problem with a tendency to just talk about things and not do anything.
I think the solution lies outside the details of this one ceremony.
I’m with Jason, in that I don’t think of this as “Lean”.
Why must it be exclusive? Why not do both retrospectives and ongoing/continuous improvement?
I think that there are situations that warrant each, and that there are definitely situations that benefit from retrospectives even when the team communicates well and deals with issues and challenges on an ongoing basis.
Sometimes you need the distance and not-in-the-trenches calmness to look at what’s gone on and learn from it as a group.
Most of this seems to me an issue of how to scale Retrospectives. With bigger teams, you certainly need other exercises than with smaller ones. For example, build groups of two or three people to come up with post its. Use a quicker voting exercise (have you tried dot voting?). For discussions in big groups, try a fish bowl, or a circle of questions – just for example.
I also don’t see why every issue needs to be talked about. They certainly aren’t all of the same importance? There actually *should* even be issues that noone wants to talk about, that just got mentioned to share an impression.
I have started encouraging individuals at the end of the retrospectives to sign up for taking care of topics that are important to them, but didn’t get covered yet. That has worked very well.
Also remember that problems don’t need to get resolved in the retrospective – the group “just” needs to decide on the next action to take (for example the next experiment to try to get more data).