The problem I’ve noticed is that people don’t feel comfortable being asked to think about how to improve their way of working at a certain fixed point in time. It’s not natural. So what about being more flexible? Doing retrospectives whenever and wherever the team bumps into problems and improvement opportunities?

The result of forced retrospectives is low interest in the activity, lack of participation, maybe even absenteeism; this results in low quality feedback coming out of the session. Some people don’t talk, some people talk about stuff that has nothing to do with the way of working but with the product itself (”the problem we have is that our code base sucks, we need to refactor”), and in general you as ScrumMaster get the feeling that -even though it was valuable- you could’ve done much more with your team’s time. Like going for a beer.

My initial approach to the problem was to think that my retrospectives sucked. I took it up as my responsibility: I put up a Post-it saying “Organize better retrospectives” and I undusted Esther Derby and Diana Larsen’s book and put it in my to-read pile. Alas, I never got around to doing anything (maybe because we were doing “good enough” or maybe because I had other priorities). The project went on to succeed without any improvements in the retrospectives, so nobody complained too much.

Then I moved to a new project and a new team. Now, when you start coaching an implementation of Agile in a large team, during the first month or two it doesn’t really make a lot of sense to organize a retrospective. Why? Because you are in the middle of changing so many things, that the question “how can we improve” doesn’t make much sense. You (as Agile Coach) have a pretty good idea of what has to be done next, the team is busy doing it, and basically everything is improving so fast already and there is so little experience with the new way of working that most of the questions you would get at a forced retrospective are things that you still haven’t gotten around to implementing yet. Retrospectives make most sense in two situations: when the methodology is relatively stable and teams are seeking ways to improve, and when things are going wrong and people want to be heard out. When a team is at the “Shu” level and you are coaching them, and you are doing a good job, most questions that arise tend to be “coming up” items in your checklist.

But then something happened. During meetings that had other purposes, I noticed that issues would come up and people would start complaining about things. If you think about it, this tends to happen a lot: someone tells a joke about how things work at the company and everyone laughs, or someone complains about something, or gives an excuse and you hear mumbled agreements in the crowd. People were talking about real problems that are not being solved.

My antennas went up. This is the type of feedback you want at your retrospectives! Why wait? My proposal: interrupt the meeting and start discussing the issue. This is the perfect time to do it: you have a person that has openly put it forward, you have a crowd that supports him, and nobody is forcing anybody to talk about this. Leave the original purpose of the meeting aside for a moment, and switch to retrospective mode! The feedback and openness you get from the team at this moment is invaluable. As long as you are there to coach the impromptu retrospective, it should be possible to come up with concrete actions in a short time and still keep the original purpose of the meeting within sight.

And the best thing is that as long as these situations happen often enough, you don’t have to organize a formal retrospective at the end of the sprint… and you can go for a beer with your team instead!