Using Kanban in retrospectives

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.

Visualizing project policies in Kanban

When David Anderson visited us last month, he mentioned that we must make sure project policies are explicit by writing them down. Recently, I had a some sort of epiphany that some of these policies could be visualized as well – directly up on the wall.

I prefer a whiteboard and post-its for our Kanban wall, at least as long as the team is co-located. This gives us an instant overview of the flow, and we gather around it to discuss how to optimize the throughput. It’s simple, but flexible.

To keep track of lead time and cycle time we update the tickets with important dates as we move the tickets across the board. However, I noticed that tickets weren’t always updated with necessary information for my statistics, so we needed a better approach.

First we standardized the way the tickets look, with fixed places for different items, but routine glitches still happened every now and then. Then we started to visualize the criteria for moving a ticket to a new state.

First arrow in the image above shows the transition when the ticket is prepared and moved into the backlog. The person moving the ticket fills in the current date in the upper left corner (the red square). Similar happens in the next transition from backlog to analysis.

When moving from development to test, another person must test the new feature (or defect).

When tickets are done, the completed date is added, accompanied by a subjective well-being using :-), 😐 or :-(. The latter is later used in the retrospective.

Most of these visual elements were added just a couple a weeks ago, but so far the notation seems to be easily understood and effective.

Are you visualizing any of your project policies?


P.S.: Thanks to Jim Benson for a great tip on how to measure the subjective well-being, as an input to the retrospective.

Improve team performance – seek inspiration elsewhere

As a teacher, my wife had to step in to avoid a conflict among sixth graders at school. She told me that she would let her students come up with different solutions on how to solve this conflict the following day. I mentioned briefly that she, in this particular case, could use a retrospective technique I have used in several occasions, prioritizing with dots, and let her students vote for the solution they would prefer. 

It slipped my mind for a while, I didn’t even go into details when I mentioned it, but a couple of days later she told me she actually had tried this technique out on her students. Some minor adjustments was necessary to make it more suitable for sixth graders and a chalkboard, but in essence it was the same technique.

She found the results surprising. While she expected the majority to vote for asking an adult for help, and at lower age they probably would, the majority voted for a certain way of solving this on their own – without adult intervention.

Instead of taking the answer for granted she generated new valuable insight of how her students think – and she only spent a few minutes totally. In addition she might have found the tipping point when children start behaving like adults in terms of conflict resolution.

For those of us who embrace agile development, we might find some inspiration in this to bring back to your workplace.

Retrospective can be successfully applied at any age and with all kinds of people, just remember to adapt it to your audience. Even the smallest effort can generate valuable feedback, and you might be surprised of what you find. This can help you improve your team.

My wife tested a new retrospective technique amazingly fast – with almost no preparation. It seems to me that they have a great environment allowing them to experiment. If they make a mistake, they get immediate feedback from theirs students and take a different approach next time. This is an important agile principle, find a faster way to fail, recover, and try again.

Create a climate in your organization that allow people to experiment and innovate, make sure there’s time to do this. Break a few rules. Take a step outside your normal boundaries and seek inspiration elsewhere, for instance see how they use visualization in a first grade classroom – the prototype for a creative learning environment. Some elements might be useful for your agile wall.

Question: Have you ever been inspired by something you have discovered elsewhere, outside your normal domain, and brought it back into your team? And how did it go?

Further reading: