The Retrospective: Agile’s DNA
If you had to keep just one thing from Agile, keep the retrospective. As a forum for continuous improvement, it paves the way for problem-solving.
The end of the year is approaching 🎊; a cycle is coming to a close, a chance to reflect on your year if you haven’t already, and an opportunity for me to highlight the importance of this Agile practice.
Re-examine your Agile practices
The Scrum framework faces many criticisms. Some of these criticisms are valid, provided, however, that we know exactly what we’re talking about and aren’t just jumping on the bandwagon. Each team is free to depart from the framework as much as it likes, regardless of whether the resulting practice still aligns with it or not: as long as it works!
You could work without doing estimates (No-Estimate); you could even work without doing sprints. The important thing is that, if you do sprints or estimates, you do them for a good reason and not just “because that’s how we’ve always done it.” And you should periodically reevaluate your practices. In the same vein, you could hold Daily Stand-ups just as easily as you could choose not to: there are many ways to stay in sync and manage the sprint as a team. Don’t just follow the rules, think for yourself!
The retrospective: a forum for continuous improvement
However, if there’s one thing you mustn’t give up, it’s the retrospective, because the retrospective is the place for continuous improvement. You know as well as I do the power of compound interest: if your collective efficiency improves by even just 1% with each sprint (say, every two weeks), that adds up to a 30% increase in efficiency by the end of the year.
How should you facilitate it? Again, feel free to do whatever works for you, as long as it works: Keep/Drop/Start, Sailboat, or SWOT, all these approaches essentially convey the same message and are simply tools to support the discussion. Don’t hesitate to mix things up, by the way: it’ll help you avoid falling into a rut. However, I’ve seen teams more than once who, in their eagerness to stick to the formal structure of the retrospective, lost sight of its true purpose. In my opinion, it’s better to tackle a major issue head-on if it’s causing trouble, even if it means throwing the formal structure out the window.
Behind continuous improvement lies problem-solving
At a deeper level, continuous improvement is a mindset: it’s the determination to find the positive in everything. It starts with celebrating successes, even the smallest ones. Then there’s what didn’t work or isn’t working. And here, far more than the formalism mentioned earlier, the ability to get back to the root causes of problems seems essential to me: don’t limit yourself to a superficial explanation; ask yourself “why?” as many times as necessary (the 5 Whys method). As long as the root cause isn’t eliminated, the problem will return.
Example: “We don’t have time to do acceptance testing during the sprint.”
- Why? Because testing each ticket takes several days;
- Why? Because all the tickets arrive at the same time for acceptance testing, at the end of the sprint;
- Why? Because the tickets are too big; we should break them down, but we can’t seem to do it;
- Why? Because we don’t break things down based on the value provided to the user (“tickets” ➡️ “User Stories”);
- Why? Because we don’t know what’s acceptable to users and what isn’t;
- Why? Because we don’t interact enough with users;
And so on.
For all these reasons, the retrospective is truly Agile’s DNA: it is the foundation from which everything else stems.
On that note, Merry Christmas 🎄 and take care of your stomach 😉