Retrospectives: one of the first terms you’ll encounter in the weird and wonderful world of Agile delivery; but what are they and why are they important? Didn’t we cope well enough before without them?
So first a little definition, the term really entered our lexicon through the widespread adoption of the Scrum framework, in the scrum guide it is defined as follows:
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
I am increasingly finding that Agile-y terminology is a barrier to understanding and adoption. Unfamiliar terms can make us feel inferior or foolish, and new “In Vogue” practices can feel threatening because we may feel judged for not being part of the “In Crowd” which in turn can result in people rejecting these ideas as a matter of principle to avoid loss of face. Whilst this definition is technically correct, Retrospectives are far too useful to be constrained within the Scrum framework, and can be beneficial to people not in Scrum teams and not doing things in Sprints, or even in Software delivery….
Retrospectives are really just an agreed time to focus on improving. Taking a step back from being down in demands of delivery to consider how things are being done; look up for a while. This could be alone, reflecting on how you are responding to your situation; something that is significantly undervalued, but typically, retrospectives are a group activity, an opportunity for a group to reflect on how they interact.
To start it is helpful to discuss what a Retrospective is not, to clear up common misconceptions you’ll encounter. It is not to decide how to deliver a specific output, that would be a planning or design session. It is not to review something we’ve done, that would be a review. It is not about WHAT are we doing; it is very much focused on the HOW are we doing things.
It is important to appreciate why we need them now, when we didn’t really need them before, and really this is a recent solution to a recent problem. Historically organisations had strong hierarchies that existed to “command and control” large workforces; to ensure everyone did as they were instructed. As the work became harder to define and understand, we moved away from structured formulaic industries and towards an adaptive creative economy. We’ve seen the fundamental principles of scientific management collapse as we’ve delegated the decision making to where the information lies – which is rarely at the top. However, if those operating practices have been delegated to teams, then they need some opportunity to define and refine those practices. Put simply, we didn’t need retrospectives before because we told people what to do.
Any group of people that are engaged together, with collective ownership and responsibilities to deliver something, that requires a degree of creative thought will benefit from Retrospectives.
I still regularly encounter teams of people working together that resist having anything akin to a retrospective. If you are free to choose how you work and the work is in any way creative then I am going to stick my neck out and say there is no good reason not to have one. The two most common defences I hear are:
“We are too busy”
“We don’t need to change”
I will rephrase the first as “we are running so fast we have no time to reflect”, which clearly is an unsustainable business model.
The second is also rather short sighted, we don’t need to change means we don’t need to improve. Either improvement, hence performance, doesn’t matter, or maybe, just maybe your delivery unit or team and the interactions you have with your wider context is perfect. Perfect… Maaaaaaybe.
Usually though, these defences are excuses for something much more troubling. I don’t want a Retrospective because I don’t want the team to think for themselves, because I want to retain control. If you are in this situation then you need to engage at a level higher and talk about principles.
When it comes to retrospectives there are three things I recommend:
- Have it on a cadence as frequent as pragmatic
- Try to make the attendance as consistent as possible
- Try to make the retrospective as different as possible each time within the two previous constraints
A regular cadence (the regular interval they are scheduled for) will ensure that they actually occur, Like the difference between saying you’ll go for a run, and actually going for one… Retrospectives are playing the long game, immediate return is unlikely – but in the long term beneficial. It also helps to keep the conversations balanced and not drift into crisis management. You really want to be talking about the way we do things under normal circumstances, on boring Tuesday afternoons in March, rather than be overly influenced by extreme isolated incidents. The frequency will dictate the topics you are needing to cover and needs some balance; infrequent retrospectives can be overwhelming because of the amount of content that comes up, too frequent and the administrative overhead starts to creep up.
Consistency is important, you want everyone’s opinion but also the ways of workings you are trying to optimise will be related to the relationships within your delivery. If you keep changing those relationships then you keep changing the target you are trying to hit and you’ll forever fall short.
My third recommendation is where I see the biggest opportunity to improve with most of the teams I encounter. They have tried something, and it worked, so they have repeated it. There is merit to this normally, we practice and refine until we perfect. Retrospectives are curiously different and the expression, “if you always do what you’ve always done, you’ll always get what you’ve always got” is more appropriate. The principle is that by approaching the challenges the team faces in new and interesting ways each time, then the results and the suggestions you are going to get are likely to be different. Many retrospective techniques pull on expressing issues through different mediums, imagery or metaphor, this is to try to stimulate different neural pathways which will enable new viewpoints. There are many great retrospective techniques that you can use, and for me the best one, is the next one. I have a few that I fall back on when asked at short notice, but for a team I have worked with a lot, I typically try to do something different each time.
I am often asked to work with a new team and I only ask for one thing to be present before I accept, that the team is willing to run Retrospectives. If that is declined then I would strongly suspect that my involvement with the team will not delivery the results that are expected.
So, if you are a team, and you are not running retrospectives, why not? What are you afraid of?
Comments are welcomed – even criticism. It is only through feedback that we learn.
Follow me on twitter: @philagiledesign
or reach me on LinkedIn here
philagiledesign 