We hold lots of meetings with the intent to gather feedback from members of a
team. These can be architecture reviews, requirements walkthroughs, sprint or
release retrospectives, and others. How do you conduct meetings like these in
an efficient and productive way?
Some challenges that arise in meetings like these are:
- People come unprepared, whether because they’re overloaded, forgot about the
meeting until their calendar reminded them, or for whatever reason.
- Some people have a tendency to talk a lot and dominate the conversation.
- Some people have a tendency to be quiet and not share potentially valuable
- The meetings can run longer than seems valuable.
I think that the principles of formal code inspections can help in all kinds of
meetings. These days people often use online code review tools, but when I’ve
done formal inspection meetings, they’ve gone like this:
- Participants prepare in advance and bring issues categorized as
- There is a designated moderator, and their first question to reviewers in
the meeting is, “Are you ready?” Based on their answers, the meeting can
proceed or be rescheduled rather than muddling through and wasting people’s
- Next, the moderator gathers a count of issues by severity
(major/minor/other) from each reviewer. This not only gives a concrete
indicator of readiness, but can also be an interesting metric to track when
deciding the value of reviews.
The game begins
- The moderator goes around the table taking major issues, one per
- If someone doesn’t have any, or any more major issues, they pass.
- Once all the major issues are gathered, the moderator switches to minor
issues, then other issues, going around the table again as with major
- The objective is to clearly understand and record the issue, not solve it.
- The moderator helps make it clear whose “turn” it is and encourages others
- Participants don’t repeat issues that have already been raised. They
might participate in any discussion that leads to clear understanding of the
issue, but that’s it. This is a tough one since people want to feel like
they’re contributing. One way to address this is to let people with the
fewest issues go first.
- The game stops when all issues are understood and
noted, or the meeting time expires.
- If metrics are interesting, it can be good at this point to note the number
of unique issues there were.
- If there is still meeting time left, and the participants are interested,
there might be some discussion about how to solve some of the issues.
- If there isn’t time or interest in the meeting, people can still have
smaller discussions later about how to solve issues.
This approach to meetings helps ensure that people are prepared, get fair time
to speak, that the discussion moves along efficiently, and that the most
important things are covered. It does, despite me referring to it as a “game”,
promote a more “closed” mode of thinking (see John Cleese’s talk on
creativity), so it is more
appropriate for identifying issues rather coming up with creative solutions for
For something like a sprint retrospective, it can be effective to devote
the first part of the meeting to this closed mode of gathering items, then
switch to an open mode for creatively solving the issues the team decides are