Alright team, let’s talk about Scrum. For years, it’s been the holy grail of agile development, promising faster delivery and happier teams. You know the drill: sprints, stand-ups, story points, and a whole lot of post-it notes. When someone asks me if I use Scrum, my answer is “Yes, but…” The truth is, a rigid, dogmatic adherence to it often falls flat in the real world.
So if we don’t use it, is Scrum dead? My short answer is no, it’s not. But a blind adherence to it? That’s definitely a zombie. It looks alive, but it lacks a pulse and a brain. The biggest issue isn’t the framework itself, but how we apply it.
The Disconnect: Testing Without Deployment
This is the big one. Scrum, by the book, focuses on delivering a “potentially shippable increment” at the end of each sprint. But in the real world, especially for B2B or complex products, a two-week sprint often ends with something that is potentially shippable but never actually ships.
This cycle can go on for months. Teams are busy, the burndown charts look great, and everyone feels productive. But if you aren’t actually releasing to users and getting feedback, what’s the point? This creates a massive disconnect. Developers are testing in a vacuum, without the pressure of a real-world deadline. The product manager is left with a pipeline of “done” features that are collecting dust instead of collecting user data.
In the real world, value is only delivered when a feature is live and being used by a customer. A rigid, two-week sprint cadence that doesn’t align with a realistic deployment schedule is a recipe for wasted effort and a slow path to market. Remember, don’t let great get in the way of good. Getting a working product in the hands of users is better than a “perfect” one that never ships.
The Story Point Fallacy: Estimation without Commitment
Let’s talk about story points. They’re supposed to be a tool for relative sizing—a T-shirt size for your work, not a hard-and-fast time estimate. The idea is to avoid the pressure of saying “this will take 8 hours” and instead say “this is a 5-point story.”
But in practice, this often goes sideways. Story points become a nebulous unit of currency that allows developers and teams to avoid making real commitments. The conversation shifts from “When will this be done?” to “How many points can we get this sprint?” Points become an output to be measured, not a tool for prediction.
This isn’t about micromanaging. It’s about accountability. We’ve found that for internal teams, a simple shift can make a world of difference: estimate in hours. A feature will take 20 hours to build. That’s a clear, transparent commitment. It forces a more rigorous discussion during planning and provides a shared understanding of what “done” truly means. It moves the team from a feeling of being busy to a sense of being accountable for the work.
What Works Instead: A Hybrid Approach with Commitments
So, if rigid Scrum isn’t the answer, what is?
The solution isn’t to throw out agile, but to build a more robust, hybrid model that connects the tactical work to a strategic roadmap. This approach combines the best of Scrum’s rhythm with the discipline of continuous delivery and clear commitments.
Here’s how it works:
- Iterate and Test: Use an iterative approach. You build a piece, you test it, and you gather customer feedback immediately. This feedback is critical. It helps you see what’s working and what isn’t, so you can adapt and improve in the next cycle. You’re not just iterating on code; you’re iterating on the product itself based on real-world use.
- Define the Roadmap with Clear Deadlines: Instead of vague backlogs, establish a high-level roadmap with specific, committed delivery dates for major features or product launches. This isn’t a waterfall plan; it’s a series of agreed-upon milestones.
- Break Down Work into Hours, Not Points: Within this roadmap, break down each major feature into smaller tasks. The team estimates these tasks in hours, providing a clear, transparent view of the effort required. This moves the team from a feeling of being busy to a sense of being accountable for the work.
- Run Sprints to a Deadline: Use sprints or weekly cycles to manage the flow of work, but the goal is to hit the roadmap’s deadlines. If a sprint needs to be a week long to get a feature out the door, that’s the sprint length. If a feature needs three weeks, the sprint is a “mini-milestone” within that larger timeframe.
This is the real world of agile. It’s about moving from a rigid framework to a flexible mindset. The most successful teams don’t worship the framework; they use its principles as a starting point, adapting and evolving as needed to deliver what actually matters: real value to real users.