Jeff Sutherland recently tweeted:
“My AI Scrum team is 30 times faster than a human team. Grok 3 just became the lead programmer to take it to the next level.”
It’s an impressive claim—one that plays into the long-standing obsession with velocity in software development. First, Scrum promised we could be 4x faster. Now, AI is 30x faster. Soon, we’ll be told we can code at the speed of light. But what problem are we actually solving? Faster doesn’t mean better. If you’re headed in the wrong direction, more speed just means getting lost faster.
The real cost of prioritizing speed over everything else? Wasted resources, mounting technical debt, and teams stuck in endless cycles of rework.
Worse, when speed is the only metric that matters, teams are pressured into delivering quickly rather than delivering right, leading to poor product-market fit, decreased morale, and ultimately, missed market opportunities. The faster you move, the harder it becomes to change direction when you realize you’re headed off a cliff.
After three Scrum implementations and 15+ years of chasing development velocity and the improvements it promised, I’m done. Speed doesn’t matter if you’re not making the right decisions. The real challenge isn’t just cranking out more software—it’s ensuring that what we build actually matters. Yet, our industry keeps doubling down on development velocity as if speed alone will magically produce better outcomes.
Speed doesn’t matter if you’re not making the right decisions
Jeff Sutherland, the co-creator of Scrum, argues: “The speed of innovation is the primary factor in business success, particularly in the technical field.”
I agree—speed of innovation is critical. But the problem is that Sutherland tends to equate development velocity with speed of innovation, overlooking another crucial velocity: the speed of learning and building things right (not just building the right thing).
Speed without proper direction amplifies the underlying problem. The real issue isn’t that teams are too slow, it’s that they lack the mechanisms to prioritize, validate, and align their efforts effectively before they start moving at breakneck speed.
AI is here, but isn’t the Silver Bullet
AI-assisted development tools like GitHub Copilot and ChatGPT claim to make engineers exponentially more productive. And it’s true—AI can churn out code in seconds. But here’s the catch: AI accelerates execution, not decision-making. It doesn’t know whether what it’s building is valuable. It doesn’t validate assumptions. It doesn’t replace deep customer understanding.
So, yes, we can build 60x faster. But if we’re building the wrong things, all we’re doing is accumulating tech debt at an unprecedented pace. Imagine assembling a car in record time—only to realize halfway through that you forgot to include brakes. More speed doesn’t prevent bad decisions; it amplifies them.
The real challenge is decision velocity
If development velocity isn’t the problem, what is? Decision velocity.
The ability to make the right decisions quickly is far more valuable than simply executing those decisions faster. Teams don’t fail because they can’t write code quickly enough; they fail because they build the wrong things.
Decision velocity can be measured by the time it takes to validate key assumptions and the confidence level in those validations. How quickly can a team go from hypothesis to confirmation? How much evidence supports their product decisions? The faster a team can test, learn, and pivot, the more effective their development process becomes—not because they’re moving fast but because they’re moving in the right direction.
Scrum’s blind spot: It only guides delivery and neglects discovery
Scrum is an exceptional execution framework. It tells you how to structure standups, how to run retros, how to refine backlogs—but it assumes that the backlog is already filled with valuable, well-prioritized work. There’s no ceremony for validating that what’s in the backlog is the right thing to build in the first place.
The root cause of backlog issues is often poor user research, lack of product strategy, and a disconnect between business goals and development efforts. Rushing through development without addressing these factors doesn’t create innovation—it creates a backlog of rework.
If Scrum leaves decision-making gaps, what do we replace it with? Complementary frameworks like:
- Continuous Discovery (Teresa Torres) – Helps teams validate backlog items by embedding user interviews and testing into the daily workflow, ensuring that feedback is obtained when we’re making decisions, not after.
- Jobs to Be Done (Clayton Christensen) – Focuses on the real problems customers need solved instead of blindly iterating on features.
- Outcome-Driven Roadmapping – Aligns team efforts with business impact rather than just delivery cadence.
Develoopment velocity without strategic intent is just blind acceleration. The real winners in the AI era won’t be the teams that simply code faster. They’ll be the teams that:
- Make better decisions, faster.
- Continuously validate their backlog with real user needs.
- Focus on adaptability, not just velocity.
Jeff Sutherland sees speed as the priority, but without alignment, speed is just a high-speed train headed off a cliff.
Development velocity should be the byproduct of clarity and alignment, not the primary goal. It’s velocity toward a goal that’s interesting - not just any velocity. At the end of the day, shipping the wrong thing faster doesn’t make it any less wrong.
- Torres, T. (2021). Continuous Discovery Habits. O'Reilly Media.
- Christensen, C. M., Dillon, K., Hall, T., & Duncan, D. S. (2016). Competing Against Luck: The Story of Innovation and Customer Choice. Harper Business.
- Ries, E. (2011). The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses. Crown Business.
- Tweet by Jeff Sutherland on AI and increased development velocity by Jeff Sutherland at x.com
- LinkedIn post by Anders Toxboe on why development velocity is not the problem by Anders Toxboe at LinkedIn
- Don’t trust agile alone to build successful products by Anders Toxboe at UI-Patterns.com
