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.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
5 comments… add one
It sounds really nice being able to integrate your retros like that. I guess your team members have gelled really good and that they feel very safe with their team values regarding speaking up and honesty etc. But isn’t it hard to find underlying problems, stuff that is not immediately obvious and requires more thought?
The team is gelled, that’s true. No one is afraid to speak up which is important since we don’t force anyone to share their opinion. We don’t have “now say what you liked and what you didn’t about last sprint” kind of situations. If someone wanted to stay silent they would (which would be a pity of course).
And no, we don’t have problems with finding source problems. Usually during discussions we go through informal “few whys” session (fewer than five usually). “We screwed design of this feature. Why? We omitted this and that scenario when we were planning. Was it possible to avoid it? Yes, probably. How? We should have discussed it with QA folks at the very beginning, they would catch this inconsistency. So maybe next time we start design with discussion with all interested parties, shall we?” You see the pattern.
It takes minutes at best and all you need is a few open minds and supportive atmosphere. Nothing that hard to achieve in good teams.
I’m sure it’s great to work in such a good team.
I wonder why you want to call your meetings “retrospectives”, though, because to me, they clearly aren’t. You have ad-hoc problem solving meetings, which is nice (and which I would recommend anyway) – and perhaps you don’t need retrospectives.
Retrospectives are more than just meetings where you solve problems you are already aware of, anyway. They are meetings where you take a step back and look back as a team to see the bigger picture and identify overarching patterns. The goal is to adapt your process based on a bird’s-eye view – you don’t even need to identify any problem to do that.
I like to compare retrospectives to car maintenance: you do it in a regular intervall – not to fix problems you are already aware of, but to get aware of stuff that you don’t notice in your day-to-day life.
I like your description, and I wouldn’t call it retrospective meetings. What you described is almost what I would call “Stop the Line” http://m.techcrunch.com/2011/09/25/founder-stories-eric-ries-lean-startups-stop-the-line-so-the-line/
@Ilja, @Bernd – Thanks for your comments. Instead of replying you here I wrote the post addressing your doubts on naming. You can read it here.