vs. Scrum

Let's be fair to Scrum. The 2020 Scrum Guide is grounded in empiricism: transparency, inspection, and adaptation. It doesn't mention velocity anywhere. Progress in Scrum is measured through Sprint Goals and Increments that meet the Definition of Done. The "velocity with story points" practice was bolted on by the industry, not prescribed by the framework.

So the real question isn't "Scrum measures the wrong thing." It's: where does Scrum's empiricism stop?

Empiricism about process vs. empiricism about value

Scrum's empiricism is focused on the work process. Did the team meet the Sprint Goal? Does the Increment meet the Definition of Done? What should we adjust about how we work? The Sprint Review inspects the outcome. The Retrospective inspects the process. Both are valuable.

But neither asks the harder question: did users care? Was our assumption correct? Should we double down on this direction, pivot, or abandon it entirely?

Scrum trusts that the Product Owner knows what's valuable and orders the backlog accordingly. The team's job is to deliver Increments toward the Product Goal. Whether those Increments actually solve the user's problem is outside the framework's scope.

LDD extends the empiricism to include the user. Every loop ends with validation against reality (not just the Definition of Done) and a decision based on evidence. The question isn't "did we build it right?" but "did we build the right thing?"

Sprint Goal vs. hypothesis

Both Scrum and LDD start with intent. In Scrum, the Sprint Goal communicates why the Sprint is valuable. In LDD, the framed hypothesis states what you believe and how you'll know if you're wrong.

The difference is in what happens next. A Sprint Goal guides the team's work for the sprint, and at the end you inspect whether you met it. A hypothesis guides the loop, and at the end you inspect whether reality confirmed or denied it. The Sprint Goal asks "did we accomplish what we set out to do?" The hypothesis asks "did we learn what we needed to learn?"

This is a subtle but important shift. A team can meet every Sprint Goal for a year and still build a product nobody wants. The goals were met, the DoD was satisfied, but the underlying assumptions were never tested.

Fixed sprints vs. variable loops

Scrum uses fixed-length Sprints (one month or less) to create consistency and limit risk. This is a reasonable trade-off when the primary risk is execution risk: will the team be able to deliver?

LDD lets the learning horizon determine the timescale. Some hypotheses close in a day. Some take a week. Some take longer. Forcing everything into a two-week sprint either stretches small work to fill the container or compresses meaningful learning into an artificial deadline.

Variable loop lengths also mean there's no sprint commitment event. You frame a hypothesis, set its learning horizon, and work until you have evidence. If the evidence comes in two days, you decide and move on. You don't wait for the sprint to end.

Scrum events vs. embedded practices

Scrum defines five events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and the Sprint itself as a container. These events create structure and cadence for inspection and adaptation.

LDD embeds the same functions into the loop itself. Framing is the planning. The build is the execution. Validation is the review. Decide is where adaptation happens. The same purposes exist, but they're not separate events. They're phases of the same continuous activity.

This matters most when loops are short. If you're closing a loop in two days, holding a sprint planning event and a sprint review on top of that is overhead that adds no value.

The role question

Scrum defines three accountabilities: Product Owner, Scrum Master, and Developers. The Product Owner is accountable for maximizing value and managing the Product Backlog. The Developers are accountable for creating Increments that meet the DoD. The relationship is clear but separate: one side decides what's valuable, the other side builds it.

LDD doesn't assign accountabilities to roles. In a learning loop, everyone contributes product thinking, technical thinking, and design thinking. The engineer who understands the customer frames better hypotheses. The PM who understands the codebase designs better slices. There's no backlog to own because there is no backlog. There are hypotheses to test, and everyone is in the same boat.

For solo builders, this distinction is even clearer: you are all three Scrum roles at once. LDD gives you a structure that doesn't require the role separation to function.

Scrum is still very relevant

LDD doesn't replace Scrum everywhere, and it shouldn't try to. Scrum remains highly relevant in contexts where teams build products at human speed, without AI-assisted engineering. That's still the reality for most teams in most organizations today. Scrum's events, accountabilities, and artifacts solve real coordination problems for teams doing complex work where execution is still the primary challenge.

LDD is designed for a world where building is fast and cheap because agents do most of the execution. When that's your reality, the constraint shifts from delivery to learning, and Scrum's delivery-focused model starts to feel like the wrong optimization. But if your team is still building at human pace, Scrum's structure gives you something LDD doesn't: a proven rhythm for coordinating human work in predictable cycles.

The honest framing: LDD is for teams (and solo builders) who have crossed the threshold where AI-assisted building has made execution cheap. For everyone else, Scrum remains a solid approach. The two serve different realities.

Can they coexist?

Some teams use Scrum events for coordination (Daily Scrums, Retrospectives) while running learning loops inside sprints. This works when the organization requires Scrum but the team wants to be more learning-oriented.

As a team adopts more AI-assisted building, the Sprint container may start to feel less useful. If your loops close in two days, a two-week sprint is just overhead. If your loops take a week, the sprint boundary is arbitrary. The transition from Scrum to LDD can be gradual: start by adding hypothesis framing and validation to your existing sprints, and let the process evolve as your build speed changes.

LDD shares Scrum's empirical values but applies them differently. It keeps the parts that are really just good teamwork (regular check-ins, reflecting on how you work together) and extends the empiricism to include the user.