Those of you who read Software Project Management regularly know for sure that I have sort of experimentation attitude. I like to try different things, see how they work and, if they sort of do, share my experience here with you. I’m particularly happy with a bunch of such concepts, one of them being ad-hoc retrospectives.
This story is more than a year old, but recently Bernd and Ilja from it-agile reminded me about it with their comments under the post.
A short version of the idea is that, instead of doing regular retrospectives bi-weekly, monthly, or whatever your cadence for retrospective is, you do a very short and focused ad-hoc discussion on a single problem raised by any team member. The outcome should be similar to what you get from a regular retro – an action point, or a bunch of them, aimed at solving the issue. In my case the whole mechanism proved to work very effectively. If this teaser sounds interesting I strongly encourage you to read the full story.
Both Bernt and Ilja pointed that I shouldn’t call it a retro. As Ilja puts it:
Retrospectives are more than just meetings where you solve problems you are already aware of, anyway.
Well, I guess we are in full agreement on this one. The only difference is I actually believe that even with ad-hoc retrospectives we are (usually) solving problems that we aren’t yet aware of. At least we aren’t when we launch the retro. Pretty often we start with just a symptom. Someone spots something that they think is worth discussing. So here we are – at ad-hoc retro.
First, we don’t have to agree that this is a real problem and often, initially, we don’t. Thus a discussion. Even though we actually are focused on this single starting point, we dig deeper trying to find some common denominator for our views.
Second, as I’ve already told you, we usually start with just a symptom. Quite often we are yet to discover, and address, a root problem.
Finally, we try to come up with some action points to fix a root cause we agree on.
Now, I happen to facilitate a bunch of regular retros recently and all of them seem to follow similar pattern, no matter the team or the organization. We start with a handful of things we like or don’t like, try to cluster them somehow, look for root causes and address them. However, it all starts with observations people make.
It’s not some kind of magic that tells us what we are doing wrong. It’s not an outsider who comes and blesses us with an epiphany. It’s not a scientific process which makes us come up with the right solution. It’s the team that finds it out by themselves.
In both cases: regular and ad-hoc retros the outcome is similar, the process is similar and even the same people do the job. The main difference is granularity. While during a regular retro we try to cover things which happened during a specific time-box, on ad-hoc retrospective we start with just a single idea. An idea we would write down on the on a sticky note at the very beginning of the next regular retro anyway. In other words we would bring it up as well, no matter the process.
I just wanted to add that another difference is, that during typical retros, not every problem is acted on. We usually try to focus just on a bunch of most important things at the moment. However, on a second thought it works the same with ad-hoc retrospectives. Sometimes after a brief discussion we just decide to leave a thing alone for the time being. We either don’t share views of a person who proposed the issue or don’t see any action points that we could agree on or whatever else. So similarly to regular retrospectives the outcome can be “do nothing” too.
If nothing so far convinced you that both concepts are surprisingly similar I have a question about a purpose of retrospectives. It is improvement, isn’t it? We want to do better in future that we’ve just done. If so, we can perfectly do this job using both approaches. Of course, depending on a team’s maturity I would go with one or another, but that’s a totally different story.
Of course we can bring it down to some orthodox discussion over definitions, but don’t count in. I’m more into solving problems than arguing over definitions. It just feels more useful.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
7 comments… add one
Thanks, Pawel, for clearing that up. I do agree: There are lots of similarities between the different approaches, and it’s useful to do them both.
I like that you distinguish between both approaches (ad-hoc and regular retrospectives), and I would find it even better if you’d distinguish it even more by choosing a different name for the ad-hoc type. With the prefix “ad-hoc” I do believe that you are on the right track, since the ad-hoc nature of those meetings is the very difference between them and retrospective, which are planned in intervals, ergo not ad-hoc.
But then again I do agree again: Solving problems is more useful than arguing over [names of] definitions. It got me confused, so I gave you feedback. Thanks for clarifying things!
Pawel, I can see why people might want to protect the term retrospective to refer to deliberately taking time reflect on some event or time period. As you know, deliberately taking time to ask oneself the typical retrospective questions can bring to mind things that can be hovering just below our awareness. That deliberate pause allows us to notice them.
And I also agree with your idea of taking the spirit of retrospectives and applying it differently — having the trigger be that someone notices something that’s not quite right and wants to see if the team can come together to address it. Although this could be seen as nothing more than a problem solving technique, I seems to me it’s the spirit that comes from the retrospective that could give it a different flavour.
I wonder, based on your original post , whether, by not having retrospective meetings at all, the team is missing out on getting into that place that allows a certain type of reflection, and thus surface certain type of issues?
@Colin & Laura – It all depends on people. If you work with people who are aware of different problems and don’t shy out to openly state them omitting specific problems shouldn’t be an issue. If something is painful enough, meaning it would be pointed and upvoted during regular retro someone eventually raise it in ad-hoc manner as well. And usually it happens rather earlier than later.
However, the other end of scale is when you work with people who don’t really see why they should even start openly talking about problems they notice or generally aren’t willing to join discussion or expect someone would magically come up with the right solution telling them what to do. In such situation I would advise to go with more organized approach, as more formal retro sets expectations, brings safety and makes it easier to take part in it.
And of course there’s everything in between and you can perfectly mix both approaches to build on their strengths. By the way, as a rule of thumb: the less your team is familiar and fluent with retros the more formal should be your approach. It takes quite a maturity to base on ad-hoc approach only.
Fully agree :)
Hi Pawel,
I’ve discovered your blog during a search for info on Kanban, in particular its (and more generally Lean approaches) difference from established Agile practices and frameworks. In your Kanban Story there are plenty of useful things. Some I can’t agree as granted, but they are definitely thought provoking, thank you! And this should be very helpful for my team as we consider some process changes. So I’ll challenge some of your points )
Till now most of time we were working in time-boxed iterations. Leaving out all the pros and cons described in your posts, we had a regular retrospective. It had a huge benefit of whole team gathered and focused on reflecting what happened during iteration. You see, if you just pick a person in room to shoot a problem, others may or may not join, someone may be absent or too deep in their task flow. And that matters because during retro they would speak on the topic.
As well during iterations we wrote down action points we agreed upon, especially if it required involvement of people out of team, then we followed it up during next iteration. In the end of the project we had a great overview of things we tuned which acts now as tips & tricks for next projects, keeping a reasoning behind.
Of course we permanently have “ad hoc problem solving” talks. But when the ad hoc problem tends to seem like systematic, we just stop the discussion to have it in dedicated time. It can be the end of iteration retro or some separate but planned talk, as it is not 5-10 minutes anymore. What do you do when problem is too big for ad hoc solution? How do you keep track of action points?
And BTW, how many people are there in your team and how diverse are specific roles (software engineer, analyst, UX, testers, …)?
@Andrey – First of all, I’m always happy to see people challenge my ideas. I learn in the process too. So I’m glad to your attitude.
The team where we started with ad-hoc retros (I’m not with them anymore) was small, 5 people in the same room. On occasions when someone was absent and we needed their insight we just deferred the discussion to this point. When we didn’t and someone still wanted to share their thoughts there was always the occasion to reopen the discussion once everyone was available.
It’s not that different form regular retros. I mean it a common case when not every single team member can join a retro and teams find their own ways to cope with that.
What’s more, I’d say that one approach doesn’t exclude the other. You can perfectly mix both.
One thing I don’t agree with is boiling ad-hoc retros down to problem solving. I mean, you can do it for problem solving and problem solving only, but it’s really up to you to get much more out of such retros. I mean, you can, and should, start asking “why?” Only then you give yourself a chance to get to something meaningful. But the same is basically true for regular, scheduled retros.
The biggest strength you get from ad-hoc, instant retros is, well, their immediateness. It means that you build shorter feedback loops and react faster for the problems. Personally I’m willing to trade a bigger chance that not everyone is in the room for that.
But then, again, I always repeat: do what works for you and your team. If people shy away from raising their pain points, basing simply on such an approach won’t work. If the team is spread geographically, it won’t work either.
However, if the team is co-located I encourage them to try it as another feedback mechanism on the top of what they already have.
@Pawel – Thanks for the answer. Now I see your point. Indeed, while these are not defined as exclusive options, team can benefit from both. Just don’t forget to keep lessons learned in collective knowledge base.
And right you are, that none of options will help, if people shy or are afraid of tackling pain points.