This is the first post in a series of posts about anti-patterns that I have seen in my travels. I thought it is helpful for people to understand what is common in projects that fail so that they can learn from others’ mistakes and failures. Over time I will post more and more patterns and I will also post signs of success in a parallel series of blog posts. While these posts are numbered, they will not strictly be in priority order and will rather follow the same pattern as my other posts, which are timely to discussions I have had close to the point of writing the post. Perhaps later I prioritise them, but for now let’s get them on paper.

The number 1 reason I see in teams that fail is that they don’t have effective retrospectives. This can have many reasons, but the most common one I see is that the team does not have time because delivery is taking all their time. They are already working overtime and now they are asked to spend an hour on a retrospective. Clearly that can wait until next iteration. You might ask: how the next iteration will get any better if there is no time to look at what went wrong this time and to improve it. And you are correct. It is likely that the next iteration will end up consuming all the time and there again wont be time for a retro. In my opinion it is not often the case that there is really no time, it’s just a lack of understanding of the importance of the retro and perhaps the experience that previous retro wasn’t effective. One sure way to get teams out of the habit of running retros is when there is no action out of the retro, the team is bringing up all kinds of challenges they had and everyone is happy to pitch in and perhaps actions are also discussed on how to improve things, but then nothing happens. Sometimes the iteration is already committed and there is no room to action anything above and beyond the committed scope. Sometimes the ScrumMaster is not willing to pursue organisational challenges that require escalation and rather waits it out. Sometimes it is simply that no owner was assigned. Whatever it is, if after a couple of retros the team is still highlighting the same challenges and nothing is being done about it, they will question the value and then find it harder and harder to find the time to even do a retro. So perhaps it is not a time problem after all.
I personally like this cartoon, which pretty much sums it all up:
http://listcrown.com/wp-content/uploads/2013/10/busy.jpg

So how do you avoid this sure way to fail:

Hold regular retrospective – The first remedy is to hold retrospectives regularly and to make sure the team participates. One thing I learned is that there is not one format that works for everyone. You will have to experiment with the team until you find the right duration and activity to get maximum participation. And over time you should mix it up. To put post-it notes under two columns for good and bad can get pretty boring and take away from the value that the retrospectives add to the team.

Follow-up with action – The best retrospective does not help if it is just a session for feedback and then people leave and the system cards and ideas remain in the room. You need to make sure that at least 1-2 actions are taken from each retrospective session and that these actions are visible to the team (ideally on their Kanban wall). If you are the Scrum Master and there have been actions for the organisation that have come up in the retrospective and that the team thinks are important, then you need to make sure that you are accountable for doing something with it. I have attended retrospectives with teams over time and the motivation of the team is proportional to the level of action that comes out of a retrospective.

Bubble up what needs to bubble up – While many actions from the retrospective are internal to the team, there are items that are of interest to the whole organisation and where teams can learn from each other. One risk of the very team focuses ceremonies of Agile is that teams learn but not the organisation. It is therefore that the team and the Scrum Master and any coaches involved make sure that insights from retrospectives are being bubbled up to the organisational level to allow for that exchange of lessons learned and that actions can be taken for things that impact many different teams.

Pictures:
Crossroads: Success or Failure by Chris Potter from www.stockmonkeys.com
License: Creative Commons
Retro-spective is here .. by Paul Downey from https://www.flickr.com/photos/psd/
License: Creative Commons