Chapters of The Kanban Story are published pretty irregularly these days but it doesn’t mean the story is over. This time, encouraged by Michael Dubakov’s great post on retrospectives, description of our retrospectives.
The first thing is we generally don’t hold meetings. At all. This also means we don’t have retrospective meetings. At all. Also, if you asked the team about retrospectives, you’d get mixed answers. Some would answer positively others negatively. Yet I keep saying we do have retrospectives.
The pattern is very simple: every time someone sees an issue which seems worth reviewing we start discussion. Here and now. Without waiting for a meeting or something. Then people who are interested join the discussion. We also poke people who we need feedback from and they haven’t yet joined us. We try to finish this retro with some action points, but sometimes our action point is “do nothing” as we agree we have no quick idea how to do things better than we already do.
Doing nothing about the issue isn’t a big deal since when it is important it’s going to come back soon.
These retrospectives are, by design, very short as they touch only one problem each. We usually finish in less than 5 minutes; hardly any of them lasted longer than 10 minutes.
Retros are done on the fly. On one hand we don’t prepare ourselves to the discussion but on the other we start talking when the problem is fresh which compensates lack of preparation.
Prerequisite to this approach is co-location. If you start talking and expect to be heard, everyone should be in the same place.
Now, the tricky part: interruptions. Sometimes it happens we interrupt others when launching retro. We all know it is costly. However, an interesting thing I’ve noticed is that we’re pretty good at “turning ourselves off” when we’re in the zone. It happens over and over again that we need to poke someone to get him involved in discussion as voices in the room aren’t enough to break into the zone. This means we limit a number of interruptions only to those situations when we really need someone’s input.
I’m not sure why it works that way. I don’t know if we worked that way from the beginning or I should attribute that to maturity of the team. The trick is it works.
Of course this is only one of many possible approaches to retrospectives in Kanban. I recommend reading Michael’s article along with comments if you want to learn others.
Read the whole Kanban Story as well.