I remember reading about the Lean Coffee movement. Inspired by their totally open meeting format, I figured this could be an excellent alternative for our retrospectives. Lean Coffee meetings use Kanban to structure their meetings, they democratize their meetings to learn and discover things about what they don’t know – as well as exploring further what they already know. Sounds like a good fit for retrospectives to me!
I decided to try this out in our weekly retrospectives. After some research I ended up using Kanban similar to what Benjamin Mitchell described in this post a while back.
Here’s our meeting board.
Gather information
We fill the ToDo column with different types of tasks.
1) Ticket (user story)
An important step for improvement is to analyze the tickets we have completed. We measure our subjective well-being of a particular ticket, simply by adding a smiley (also mentioned in an earlier post). There are no rules to what this smiley actually means, it’s just a personal way of expressing how we feel about a particular task.
Actually, there are two potential smileys on every ticket; the person developing the feature, and the person testing it (and this is not the same person according to our project policies).
Completed tickets are taken into the backlog for the weekly retrospectives. A ticket may look something like this:
2) Actions from last retrospective
Follow-ups, that we have finished since the previous retrospectives, are also put in the meeting backlog. Orange post-its for actions items (as we call them).
3) General topic (idea, problem, etc.)
To capture other topics that might be worth dealing with in the retrospective, each of us use a couple of minutes on our own, brainstorming, writing down ideas or problems that have occurred last week. We use blue post-its for this.
4) Time constraints
In addition, if any time constraints applies during the meeting (such as when a person has to leave early), we put that up in a time constraint column – pink post-its. This might affect the order in which we decide to go through the topics. Completed time constraints are moved to “done” when time has passed.
Running through the topics
With all the topics and time constraints available, each of them are given a brief introduction and put up on the wall. Overlapping topics are grouped together. We prioritize them using dot-voting.
We start off with the highest priority topic, and move on, one topic at the time, until time is up (which is 30 minutes). After a while the Kanban board might look like this.
Every topic is time boxed to eight minutes, but if we’re not finished discussing it by then, we might continue discussing it in a new time box – if that’s what the majority wants. Reordering the topics is allowed as we go along!
At the end of the timeboxed meeting this could be the result.
– Two old (and completed) action items debriefed
– One time-constraint passed
– One ticked discussed and completed
– Two general topics discussed and completed
– Two new action items created
Some topics lead to concrete actions. These post-its are put up on the project’s Kanban wall when the meeting ends. If it’s a small task, we usually fix it right away, if not it’s prioritized along with other normal tickets. We take completed action items back into the next retrospective, at least to give an update on what happened, but maybe also discuss them further.
We have been using this approach for a couple of months now, and it seems to work quite well. The structure is fairly easy to grasp, so that all team members can run the retrospective if necessary. We gather data for the meeting backlog in several different ways; finished user stories, previous action items and general topics. All participants prioritize the meeting backlog together, and we move on, highest priority first, until time is up.
Until now, this method has given us new and valuable input in every retrospective. Nevertheless, we will probably spice things up occasionally by using a different technique, just to get a different perspective on things.
Have you tried using Kanban to structure your meetings? Or are you thinking of it? Please share your experiences or ideas below.
(…and the next natural step would be to start Lean Coffee meetings in Oslo now, right? Give me a hint if you’re interested!)
Update 18/10:
After a twitter conversation with Benjamin Mitchell yesterday, I’ll nuance the picture a bit.
1) Our meetings are very effective, actually almost close to stressful. It takes time to prepare and prioritize the backlog, so 30 minutes every week might be too often – or too short. I guess this depends on the team and the situation, but we consider running the meetings 1 hour biweekly. Or maybe you have other ideas on how we might reduce the time it takes setting the stage?
2) The link between the project’s Kanban and the meeting backlog, lets us delve into more details on completed action items and tickets – and find new ways to improve. Vice versa, new action items from the meeting are followed up in the project. These links, both ways, are probably the best things about this approach. Even though it might be valuable also to discuss items in progress (those are fresh in mind), we wait until they are completed. Reason? Simple. We use a manual board, and if we move ongoing items off the board, we risk messing things up. Keeping track of this should be simple, but we skip it to avoid complexity.
Disclaimer: This blogpost was originally published on a different platform. Formatting may be incorrect, links may be out of date.
Jørn Hunskaar 