Retrospectives -That one Agile event that’s meant to fix everything. Often however they are run by a tired scrum master or team lead at the end of an arduous sprint & more often than not, it’s a box ticking exercise. It’s meant to be an inspect & adapt event, but its more often a bun fight.

Teams & individuals jockey for position at the moaning table, often the loudest person in the room pontificates over what’s wrong in a statesmen like monologue whilst everyone rolls’ their eyes. Others state the obvious. Many point fingers & those responsible often have shoulders covered in Teflon. We’ve all been there.

Further, when did you last see retro items go into a backlog & be included & measured in the next sprint? Never?

So a retro then. The premise is simple, you all get together, someone fires up a Kanban board with columns such as ‘what went well, what no so well, what can we do to improve’ everyone has a bit of a whinge, post it notes get created & then everyone moves onto the next sprint with nothing really happening in terms of improvement.

People are complex characters. In my time as a DM & working in the digital space doing pretty much every role in the IT industry, I’ve discovered no matter the project, no matter the client, no matter the complexity of team structure, most issues uncovered & subsequently distilled in a typical retrospective are commonly categorised into the following six buckets;

• Problems with people & culture, either not getting on, not understanding, not understanding one another’s needs, not being led, or not being the leader(s) they are meant to be. Toxic landscapes, bad leadership, shadows cast & an unsafe working environment. People not taking account or responsibility for the things they should say or do. You can add politics & lack of sincerity here also. You can apply this to the client too.
• Problems with process, its either convoluted, wrong, inefficient, done because there’s not enough budget to do it better, legacy technology driving the process, lack of skills or no time to change.
• Problems with time, no one wants to slow down to get quicker. We do things this way because that’s how we’ve always done them. We don’t have time to act on retro actions, I don’t have the time. Its not my job. Rinse, repeat
• Problems with (lack of) understanding, I’m always surprised at how many teams don’t fully understand why they are doing what they are doing & the purpose of their work. Whilst often this can come down to bad leadership, a lack of understanding of what is being done & why is a huge issue.
• Problems with communication, one of the biggest challenges, people are quickly losing the skill on how to communicate. Young leaders, young teams, commercial complexity, Chinese walls, lack of time (see above), politics, all contributes to a general lack of ability to communicate & communicate well.
• Problems with tooling, people not having adequate tooling to do their job. Whether that’s an effective development pipeline, high speed network connection, the right laptop, the right software. Nothing kills productivity more than a developer not being able to develop because he’s got to share an Azure license with Steve in another team. Get the man the right tools, c’mon.

But not only the above, the retro itself often stinks like a mouldy sock, I mean how many of these sounds familiar?

• Going through the motions
• Stale facilitation
• Inability to capture any actions
• Unsuitable scheduling
• Nothing happening post-retro, no outputs or actions, just talk

There are so many benefits of running a good retro, yet they are often badly executed as Agile events.

So what?

Now shush, here’s a secret. Are you listening? No matter what, without even polling the people any more, I can often document the anticipated output from any given retro without even doing the retro. Doesn’t matter the project, doesn’t matter the people, problems always the same. Now if I know this, & you probably know this deep in yourself, I’m sure everyone does. So, if that’s the case, why do people, clients & orgs keep making the same mistakes, why do many projects always go south?

We do only what we know, & we know only what we do.

If we don’t give ourselves opportunity to talk in a safe space without criticism & grow together, we often can’t accomplish complex things. Paying lip service to good leadership, or commitment or accountability but not actually doing the thing, is useless. Yet many teams continue on this road of whimsical aspirational intent but failing on a daily basis. Besides, you can always attribute blame to the nearest project leader or manager, right?

If you watch an F1 pit team, they move & function with the grace of a proud Swan. It’s beautiful to watch, each member trusts the person to the left & right of them & the output is a sub 2 second pit stop.

If you watch a part-automated production line on a high technology item like battery or microprocessor production, everyone knows their part, their place, the value they add & the why.

Yet a badly functioning team where everyone has their own singular goals, views & demarcation of responsibility will never get to where they want to be. A retrospective aims to highlight some of those problems within a mis-functioning team.

A good retrospective is like a mirror. It holds a mirror up to every facet of the project & team in an honest & safe, practical way. Its articulately presented, it is backed with empirical evidence & it’s committed to. You see, there’s a responsibility with holding a retro. For the begrudging teams who have heard it all before, this is your opportunity to hold your leaders accountable. And for those leaders who want sh*t done, this is for you to prove you’re a good leader. Atlassian make a fantastic point about a retro being a ‘a reflection of the past to improve the future’. So at four years old, we learn this by only ever touching a hot kettle once, yet as an adult we make the same mistakes.

Why I run my retro’s the way I do

I don’t care about your sprint velocity, bugs-squashed report, your burndown or story points completed. The quality of your definition of ready is not my concern, Sure, these are things which should be discussed in a retro but could also just be operationally improved through general excellence. What I care about is the six themes I mentioned earlier.  You see, everything else is superficial, it’s about doing the difficult things first (something I promote in project management) and that means fleshy complex emotional human beings – my favourite piece of technology!

A retro should be;

• Well run & facilitated, – it’s not a Kanban & post it notes as much as its about knowing how to read a room, give people a space & draw out conversation. A bit like a Saturday night chat-show host, it should be comfortable, genuinely safe & well run.
• Summarised, what good is a retro if it’s not summarised? Proper sentiment analysis & grouping into themes to then play back to everyone if not done, makes the whole thing worthless. You should budget 40% of your time on top of the retro to synthesise meaningful output.
• An anchor for a story, the retro tell’s a story of the past, & a good leader contributes to the narrative change to improve the future. If leadership stinks, hold the mirror up. If Steve (with that borrowed Azure license) isn’t writing well documented code, hold the mirror up. If the clients being an ass, hold the mirror up. No exceptions.
• An opportunity for people to commit, I put a lot into my retro’s. But I expect a lot from the people who attend them. I’m going to ask you to switch your camera on if we’re doing it remotely. I’m going to encourage those not talking to speak, & those speaking too much to pause, & I honestly don’t give a monkey if you’re the CEO or the employer, we’re all just humans & we’re one team. So I’ll hold you accountable for being transparent, honest & then your commitment to improve.

The biggest problem I see with retro facilitation is not enough put into the pre & post work needed to make it impactful. I often synthesise the results into an output which can be consumed as a story. Grouped into sentiment, core issues, & practical recommendations for where & how to improve. This provides a useful punctation after each retro & gives everyone a core message to swarm around, rather than a bunch of post it notes which don’t make sense after you’ve come back to them after a week.

The other issue is a fear to have someone external run it. I’m asked to facilitate many retro’s where I’m an independent external. Naysay’ers will often rebut to say it needs to be someone in the team, or that by being external I’ll have no contextual knowledge. But often, the real reason is because no one wants to get called out by someone who doesn’t have skin in the game. You see, that is what makes external facilitation of a retro valuable. That person will often see things & be able to talk unconstricted from the political shackles of a project.

What YOU can do to make your retro better

• Contribute, but not in an overly negative way. Think practically, be transparent & give the process a chance. If your retro has become a talking shop, say so.
• Acknowledge you may not perfect yourself, are you really doing as much as you can to help improve the project? Maybe you are, but really?
• If you’re a leader, own it, one of your many jobs is to galvanise the team, tell them what they need to do, why they need to do it & provide that vision.
• If you’re a team member, own it. You either live in a world where you suffer the problem, or you’re a contributor to the solution. A retro won’t answer that question of which to be, or which you are, but watch out for that mirror!
• Help make the retro a success by showing vulnerability, one of the biggest & most successful elements of these types of sessions is showing a bit of humility by putting your hand up & saying ‘I got it wrong’ or ‘I could of done that better’ or ‘how can I help you with what you need in a better way’ – this alone is massively valuable.

If you want an externally facilitated retro run with your team, by me then visit http://www.creativepixel.me.uk/ or contact me on Twitter https://twitter.com/mariodc https://twitter.com/deliverynotts or https://twitter.com/dm_daily for the podcast, The Delivery Manager Daily.