Catch Small Failures Early with Agile Practices
“I wish we could talk about our small failures instead of having to wait until they are major issues.”
I remember hearing this from a fellow development manager a number of years ago, and it still resonates with me today. We were working in an agile development shop, but we didn’t have the organizational safety needed to discuss small failures.
Large issues were no problem. Leadership would rally the troops, and teams would work late and into the weekend to “save the day.” At the end of the fire drill, the managers could talk about the great effort the team showed to solve a problem, and leadership was satisfied with the commitment the team showed to delivering what they promised.
Small mistakes in this type of environment lead to blame. Major issues could get you promoted.
I know what you’re thinking, and you’re right: This isn’t agile, not even a little. But it is still common, even in agile shops.
Ironically, being able to respond to “small failures” is often what makes the overhead and expense of agile worth it to many organizations.
Let’s use Scrum to frame this idea a little more clearly.
Sprint planning is about figuring out which of the prioritized product backlog items can fit in to a sprint—typically, a two-week period—and then decomposing the first few stories into smaller pieces. We’re intentionally making our work small so that if we do make a mistake, miss a dependency, make the wrong assumption, or flat out mess up, it is small and correctable.
The daily scrum is all about coordinating a day’s worth of work to make sure that the team is on track to deliver on their sprint goal at the end of the sprint. This micro-planning is all about catching small mistakes and correcting them early to keep progress going forward.
At a sprint review, the product owner and the Scrum team inspect the latest increment of working software against the product backlog to see if changes are needed based on what was learned about the product during the last sprint. Delaying this event could cause the team to continue down an incorrect path for many more sprints.
Inspecting how the team did their work and coming up with experiments for how to improve during the sprint retrospective is the heart of agility. It’s essential to be able to talk about small failures and ways to improve during the retrospective so that the team can advance their agile practices.
Agile is designed to keep failures small and manageable, and risk management is a built-in feature of Scrum. If your teams can’t talk about their small failures openly, there is a great risk that bigger troubles are around the corner.
Take time to discuss small failures with your teams and the great learning opportunities that they can bring. After all, these opportunities to learn are one of the major incentives of adopting agile.
