The other day I facilitated a retrospective for a fellow team. My goal, as a facilitator, was basically to help them to suck as much value out of the meeting as possible.
Now, before we move on, a picture from a past. I recall a bunch of retrospectives which looked like this: a whole project team met for a longer time and everyone was asked what was good about the project and what needed improvements. Then, one of project leaders wrote it down in a document uploaded the document to a server and finally everyone could just happily forget about the whole thing.
Does it sound familiar? It probably does for many of you. Does it add any value? Um… next question, please. Isn’t it a complete waste of time? Oh well… If you don’t plan to make any use out of retro, don’t even start it.
So the question is: what makes a retrospective valuable?
The answer is actually pretty simple.
Value of retrospective can be measured in terms of changes sprung by it.
It basically means that the team decided to act, to try something new, to deal with a problem. It doesn’t necessarily mean that it will be an overnight success. Most likely it won’t. But at least they gave themselves a chance. They might even totally fail with the first approach, but they kept trying.
Note: when I say changes I think about things which are really changing, not about those we just say we’re going to change but don’t do so.
Anyway, another problem pops up. We want changes, but how to make them happen?
Um, that’s sort of easy. Remember about a few simple rules:
- Don’t chase too many goals. It’s usually tempting to cover each and every issue we spotted. After all we have all the enthusiasm and we want to improve. The problem is that when we commit to too many tasks we’re going to fail at many of them. Then, we’ll get discouraged that we don’t see any results of retro and our enthusiasm won’t be that enthusiastic next time. If there’s going to be the next time, that is.
- Assign people to tasks. Task with no individual attached to it isn’t really assigned. A decision that the team would do something means that, well, someone else can do it, not necessarily me, right? Tasks assigned to everyone most likely end up not being done by anyone.
- Have deadlines. Ask when you’re going to be done doing this or that. Keep your deadlines possibly short, yet definitely reasonable and achievable. Stating that something will be done in 6 months is meaningless. In 6 months I can work in the other place of the planet. A couple of weeks are a time frame we understand way better than a few months. If tasks don’t suit short time frames, chop them to smaller ones.
- Verify outcomes. When deadlines pass remember to discuss with the team what was done, what was the outcome, what else, if anything, has to be done about discussed issues. Again, I don’t assume that all the problems are solved. You may end up with a solution, which didn’t work, and will to try something different. You can also end up with solved problem but the least you should do is saying so. Starting the next retro with such a summary of outcomes from the previous one is a good practice.
- Repeat. One retro is just a quick fix. If you need sustainable change do retrospectives regularly. I don’t believe you are so perfect that one retro is enough to solve all the issues you might possibly have.
In short you want to end up with a short list of actionable work items assigned to people and then check how you’re dealing with them.
Of course sometimes it just sounds that easy. Sometimes you need to work hard to avoid blame game, get focused on specific issues, cut out longish but pointless discussions, learn to accept things you can’t change etc. Sometimes you will need to try different formats to animate communication or build basic trust between team members or change their attitude to anything positive. Sometimes it may be damn hard work to do.
But as long as you aim for the goal and your actions help in achieving it, you should do pretty well.
Subscribe RSS feed
Follow on Twitter
Subscribe by email
7 comments… add one
Hey, interesting post – just wanted to make a quick observation – assigning tasks goes quite against the grain of self managing teams.
I’d want to look into the standups that you are holding to make sure the teams are communicating properly, and rather than assigning tasks, making sure they all feel empowered to complete the work that they have committed to. Perhaps you should advise them to complete stories in priority order so the highest priority work is consistently getting ‘done’.
The other thing I’d be curious to know is if they are over committing and hence why they aren’t completing all their tasks, or if perhaps their task writing or definition of done aren’t up to scratch so work isn’t being completed…
Just my two cents anyway. Good luck, and thanks for sharing.s
I fully support your statement that you shouldn’t start a retro if you’re not planning to make any use of it. If made a similar statement for (CMMI or other) assessments: “Only assess where you can and want to improve”.
In an earlier post (http://www.benlinders.com/2011/getting-business-value-out-of-agile-retrospectives/) I also stated that it should be actions that the team members can do themselves, and that it’s better to go for some high value action iso a lot of actions that will not be done anyway. Sometimes it helps to do a Root Cause Analysis in a retro, to really understand the causes and come up with preventive actions.
Thanks Pawel for sharing your insights on retrospectives!
@Jacob – I should have been more specific. When I think about assigning tasks I don’t say that someone, meaning manager, retro facilitator, whoever else, needs to literally assign every action point to someone. Actually what I expect is people volunteering to do tasks and this is exactly how we addressed all the tasks during last retro.
Actually if no one is willing to volunteer to perform task agreed among all the retro attendees it means that there’s no real will to change the issue. You may reconsider leaving it as it is, doing nothing, and then verifying on the next occasion whether it is still considered a problem.
The reason for explicit task assignment is to state explicitly what we plan to do about the issue. It’s about commitment, as I say in front of everyone that I’m going to have this done before the end of the next week which is specific, measurable, actionable, etc.
Regarding over-commitment I believe it is, at least to some point, the role of facilitator to keep the number of tasks low. You also have a mechanism of reviewing action points from the previous retro so you can verify whether you over-committed heavily, lightly or none at all.
@Ben – Definitely, it is better to address just a couple, or even a single, high-value issues than a bunch of random ones. However, my observation is that, especially in teams where retro is done after longer time, many problems are interconnected. In such cases it may be a good idea to have one-off initiative to address more problems and then follow up with smaller batches of changes.
Hi Pawel – good posts – retrospectives are my favourite thing about agile development.
The way that we try to run our retrospectives is simple. Iterations are 2 weeks long, so for the last half hour at the end of the iteration we have our retrospective – timeboxed to half an hour. Each person gets 2 minutes to give their two pros and two cons for the 2 week period. After that we discuss the top two most common negative points. Actions aren’t assigned out as such, instead the team tends to agree to just make a more concerted effort to do it. Say a problem was “Reviews aren’t done quickly enough and this halts testing as testing can’t start properly until the review has been done”. The team may decide to just make a concerted effort to do reviews ASAP. The solutions are usually that simple and can be implemented immediately. As the meetings are regular, problems are identified quickly and dealt with. It actually works really well for us, and I find it helps morale as there is never a large period of time where problems keep growing before being dealt with.
@Rory – Definitely frequent and regular retrospectives allow you to put less stress on taking direct responsibility for a task by a single person, meaning that you can say that everyone would try to fix this or that issue.
However, even with such approach I would say that everyone should have clear vision what is expected from them. From this point of view it still should be an actionable point and if it’s my responsibility to act over it I should be aware of that.
Either way, from my experience, stating clearly who commits to do what always help.
Just wanted to let you know I enjoyed this article. A lot of what’s written focuses on how to elicit feedback and discussion; I like that you also focused on how to convert insights to committed action.
–mj