My colleague Ashwin Raghav wrote a blog post earlier in the week in which he noted some patterns that he’s noticed in retrospectives in his time working in ThoughtWorks.
In it he talks quite generally about things he’s noticed but in my experience one of the areas in which teams typically struggle is when it comes to action items.
We find so many things that we can improve in our team and we want to try and do all of them straight away.
This sounds a little similar to what Dan North has been talking about in his Agile Architecture talk at QCon in San Francisco:
Having any more than 2 or 3 action items probably means that the majority of them aren’t going to happen so we need to prioritise and make sure only the action items we really care about are recorded.
I think this stems partly from the fact that it’s really easy to suggest that something be added to the action items without considering whether or not there is someone in the team that is really passionate about making sure that it happens.
This often happens when we volunteer ‘owners’ for actions rather than someone being enthusiastic enough that they just want to go and fix it.
My current thinking is that if noone really wants to drive forward an action then we should just cross it off the list rather than fool ourselves into thinking it will get done.
A colleague pointed out that if we had group ownership for that action then it would mean that nothing would happen because collective responsibility typically means no responsibility.
He added that it would be useful to have one or two developers paying particular attention to that item until the approach was engrained in the team’s mentality and everyone just did it by default.
In Agile Retrospectives the authors suggest that we ensure our actions are S.M.A.R.T which I think is a reasonably good idea although I’m not a fan of management acronyms!
I prefer to just check that with each action we’ll be able to know by the next retrospective whether or not we’ve managed to do it and if what we did worked.