Retrospectives - why bother?
High-performing teams value Retrospectives — the information they track, data, gives them critical insight into their agile process and more importantly, how to improve. Well-prepared, data-driven, retrospectives provide the focus for continuous improvement. Imagine if you improved your performance every (2 weeks) Sprint - that’s 21 opportunities to improve every year. And at just 1% improvement each time, it’s 21%. Yet many teams roll aimlessly from one Retrospective to another, never really tackling the issues & productivity drains. Unless you dive deep, it’s really not worth bothering.
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 practices, data and acceptance of failure are crucial!
"If I were given one hour to save the world, I would spend 59 minutes defining the problem and one minute solving it." - Albert Einstein
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. 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.
Performalise does the work for you. It tracks 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, and 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
poor acceptance criteria meant we misunderstood feature X and we have to rework it
What to improve
Check the acceptance criteria as part of D o R 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, so you set your Improvement Goal.
Top Tip: 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 but not Failure
Just as you choose one point as your Improvement Goal, choose one to celebrate. If you’ve had a successful Sprint then enjoy, and celebrate something specific. It’s really important to recognize that you’ve done a great job. Count the team 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 a 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 accept and even celebrate poor performance out of sheer habit, and learn 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!
Performalise – your teams deserve it!