Retrospectives: Keep It Fresh
24 May 2017 |
Shimon Morad | About a 3 minute read
For many who have been working in Agile for a while, they will know that Retrospectives is part of the ceremonies, done on a regular basis within the process. In other methodologies, PRINCE, PMP, etc., it is called Lessons-learnt and is done at the end of each project phase (sometimes just at the end).
Pre Scrum this process was applied once every few weeks or months, if at all. More often than not, the findings were filed away in the project ether and forgotten until the next Project Manager picked them up. That PM may or may not do something with the last finding, as by then the landscape has changed: the people, the business, the environment, etc.
The Lessons-learnt sessions were run like any other meeting, business as usual, and were often quite boring. Partly because everybody knew they were a waste of time and partly because it was only done periodically so there was no need to make them ‘fresh’ and fun. It was OK to be in such a meeting once every few months.
Back in the Agile world where these meetings are meant to run once every two weeks, how often does the following scenario happen:
Just before the end of the sprint, when the team has nearly delivered a story or a bug and they need just that extra little time to achieve the goal, someone says – “let’s delay the retrospectives”.
People do this, not just because they want to achieve the sprint goal, but also because – as within other methodologies – people don’t see Retrospectives as important or adding value.
There are many reasons why Retrospectives are fundamental in Agile. Mainly, without them teams keep on making the same mistakes and never improving. There’s a plethora of info about this out there – search it up if you don’t know!
In order for Retrospectives to keep being engaging and effective, they need to be fresh, fun and make a positive impact. My solution is to use more than one way to run Retrospectives, sure you can reuse – and please do – but try to change the ways it run at least every few sprints, whatever works for the team. There are many techniques that can be applied, from ‘Sailboat’, ‘Team Journey’ to ‘Start, Stop, Continue, More’ etc. See examples here: http://www.funretrospectives.com/
Keeping Retrospectives fresh and lively is only one part. The other part is to implement changes, moving ‘lessons learnt’ to ‘lessons applied’. There is no point saying “get to a meeting on time” without ensuring that the team gets there on time. Or “do more code review” without reducing the velocity – at least to begin with – to allow for more code reviews. We need to make sure that stories are created and prioritised so time is allocated to apply lessons learned.
Going back to the scenario above, if we don’t make this meeting relevant, this is how it plays out:
The Retrospectives are not just delayed, but cancelled, and the sprint goal is not achieved either.
This perhaps is the most important lesson to learn.Read More From This Author
Senior Full Stack Developer (London)
Champion software quality and technical vision for AND and our clients, work on large-scale projects and help junior and mid developers grow in their roles.I'm Interested
Full Stack Developer (London)
Put your development expertise to work, building remarkable, digital products in Agile environments using a variety of languages and frameworks.I'm Interested
Tech Lead (Reading)
Bring your expert tech knowledge to the table to influence the direction of projects, whilst coaching and your team through engineering best practices.I'm Interested