Why bother?
High performing teams see the value of Retrospectives — the information they track, data, gives them critical insight into their agile process and more importantly, how to improve. Backed by data, retrospectives are more actionable than subjective and metrics automatically provide a great focus for conversation. Imagine if you improve your performance by just 1% every Sprint (2 weeks) - in a year you could improve by approximately 20 - 25%.
Every team has their own unique style and preferred techniques for facilitating Retrospectives. It's fine to use out-of-the-box models or create one to match the way you work. If you’re new to the technique or simply looking for tips to re-invigorate your current practises, data and acceptance of failure are crucial! Read on…
Transparency rules.
Research demonstrates that teams who share their performance data 24/7 or on a weekly basis are the most satisfied with their communication process. The easiest way to increase your sharing cadence is to create a live, dynamic display of burn-down, recurring impediments and time-to-unblock, high points and low points. It doesn’t have to be elaborate - flip charts on the wall or a Confluence page are fine, just keep it real and current.
Transparency demonstrates your professionalism and commitment to improving. Everyone knows exactly where you are, what great work you’re doing and what challenges you’re dealing with. An event timeline is a simple tool to get started if you’re not keen on sharing too much publicly. You can keep a simple physical version in a high-traffic area (i.e. the canteen wall) that literally plots the Sprint and all its events, good, bad and ugly. It will track the things you forget, want to forget and should celebrate when you have your Retrospective. It will enrich your Retrospective, making sure it stays honest, purposeful and doesn’t turn negative.
Start with the end (Goal) in mind.
The goal here is to find and implement meaningful improvements. It’s easy to set vanity metrics and focus on the easy things that just don’t add value to your team. We see so much focus on the wrong things in Retrospectives that they really can be pointless - don’t fall into the trap of an hour of high-fives and post-its but no tangible outcome.
A simple example might be that we failed our Sprint because we had functional defects that Stakeholders identified at the Review. It would go like this...
What worked ?
We swarmed well, finishing one story before starting the next
We refactored our 10% target tech debt
Because we refactored that first, we could complete feature X
What didn’t work ?
Poor acceptance criteria meant we misunderstood feature X and we have to rework it
What to improve?
Check the acceptance criteria as part of DoR immediately prior to taking into the Sprint
How to improve it?
Improve Backlog refinement to include clarification with end-users, not just the PO
In this example, a simple improvement would reduce your rework which is waste. OK, that’s a very simple example but the point is having identified what to improve, you need to action it in the next Sprint. And the most valuable improvements are often the ones we’re not comfortable with.
To quote Steven Covey “Be honest. Sometimes people find themselves achieving victories that are empty — successes that have come at the expense of things that were far more valuable to them. If your ladder is not leaning against the right wall, every step you take gets you to the wrong place faster”.
Celebrate Success
Just as you choose one point to improve, choose one to celebrate. If you’ve had a successful Sprint then enjoy, celebrate something specific. It’s really important to recognize that you’ve done a great job. Give Kudos. Enjoy the moment.
That said, don’t fall into the bland “beer & pizza” free for all or “hail the superstars” celebration that so many teams have come to expect. Look within your team and at your data. Have you found some hidden gem during backlog refinement? Have you overcome a major tech challenge? What have you learned about this Sprint that will significantly change the way you move forward? Find a genuine reason to celebrate.
And if you’ve failed, don’t celebrate.
There’s a frequently misunderstood saying “fail fast” which sounds like failure is absolutely fine, no problem. We see teams celebrate poor performance out of sheer habit, and learning nothing in the process. Again, data is your friend because you can pinpoint where, how and why you failed. You may find that you failed the Sprint but learned something important or that you even decide to change direction in some way and that’s good. Emphasise teamwork and highlight shared credit, consequences as well as shared learning opportunities. Make sure failure isn’t about blame for sure but accept it. Denial of failure is failing to improve.
Tools & Techniques
There are numerous techniques to facilitate Retrospectives, here’s a summary to get you started.
Fishbone Diagram
5 Why’s
Metrics
Burn-down chart
Team Happiness chart
Events over the Sprint (timeline)
Impediments log review
Leading indicators - where are we heading?
Customer Satisfaction (from the Business Review)
How can we improve our (pick a topic for a 30-minute brainstorm)…skills/product knowledge/quality/collaboration with X department
Remember - Scrum provides transparency to reveal issues in order to organise corrective action. Without meaningful transparency and inspection, you are doing something, but it’s not Scrum, it’s probably just wasting a lot of your precious time!
Resources & inspiration