February 9, 2025
Despite its near-ubiquitous presence in the tech world, Scrum often fails to deliver the promised efficiency in practice. Endless meetings, inaccurate estimates, and relentless pressure—rather than fostering creativity, they drain motivation. These challenges are well known to anyone working with Scrum, but there’s an even more troubling issue, one deeply tied to estimation: the persistent feeling of failure at the end of nearly every sprint.
Estimating the time required for tasks in a small software project is relatively simple. There are fewer features, and the team has a solid understanding of the codebase and business rules. Challenges are easier to predict, and uncertainty is minimal when implementing new features or fixing bugs.
However, as projects grow, complexity increases exponentially. Many variables come into play—obscure business rules, legacy code written by people who have long since left the company, and uncertainty about the full extent of necessary changes make estimation a daunting task.
In this environment of uncertainty, teams are expected to precisely estimate the time for each small task and fit everything into the next two-week sprint. The result? They get the estimates wrong.
It’s natural to feel disappointed when a project is poorly executed. If there’s a valid reason, you should reflect on it and aim for improvement. However, it’s concerning to see teams that worked tirelessly for two weeks, delivering 95% of the planned work with high quality, yet still feel like they failed—just because the remaining 5% wasn’t completed.
In most cases, taking an extra day or two to finish that last 5% has no real impact on the end user. But flawed planning does have a significant impact on the team.
I've lost count of how many sprints ended with teams feeling demoralized over minor unfinished tasks, despite having put in tremendous effort. They shouldn’t feel that way. There’s always room for improvement, but it’s equally important to recognize and appreciate the hard work and progress made—even in the face of unexpected challenges.
There’s a popular saying: "Focus on the process, not the outcome." This is great advice when building habits, like exercising regularly or learning a new skill. In those cases, sticking to the process naturally leads to results over time.
But in software development, the opposite is often true. A team's success shouldn’t be measured by how strictly it follows a process, but by the value it delivers. Processes should adapt to the company size, culture, and team structure. What works well in one setting might be a disaster in another.
The real issue with Scrum isn’t just its meetings or flawed estimates—it’s the way many teams follow it blindly, without questioning whether it actually helps. The goal should never be "doing Scrum correctly." The goal should be delivering meaningful results in a sustainable way.
So don’t let rigid processes stifle your team or drain its motivation. Challenge them, adapt them, and most importantly—focus on delivering real value.
#work