Join the DZone community and get the full member experience.Join For Free
How do you break a Monolith into Microservices at Scale? This ebook shows strategies and techniques for building scalable and resilient microservices.
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.
Too many action items
I think this is probably the number one mistake that we make in retrospectives and it's really easy to make.
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:
Often you’ll find tens and tens of things to improve, accept the fact that you probably can only change three of them, and focus on that.
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.
Action items that noone is passionate about
Even if we do manage to reduce the number of actions that we list it's often the case that we'll get to the next retrospective and nothing will have been done about many of them.
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.
Group ownership of actions
We recently came up with an action that was applicable to all developers on the team – around recording technical debt while working on stories -and I didn't see the value of assigning an 'owner' to that action.
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.
Action items that are difficult to measure
Another common mistake is to come up with action items which are very difficult to measure i.e. we can't tell whether or not we succeeded in executing the action or not.
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.
Opinions expressed by DZone contributors are their own.