The most recent white paper by Niels Pflaeging and Sebastian Kubsch, “Time-Oriented Software Development” or TOSD for short, lays out an audacious challenge to Agile orthodoxy. Having spent more than two decades building and managing software systems-including leading the full Core Banking platform development for private banking-I found the paper both invigorating and frustrating because it strikes at the very heart of what is broken in many Agile implementations today-particularly around sprints-but misfires by carrying its manufacturing analogies a bit too literally onto the complex and creative domain of software development.

Let me be blunt: sprints, as commonly practiced, are broken. I have watched too many teams spend more time planning, estimating, and aligning their sprint work than actually delivering software. Rigid sprint boundaries and the consequent planning theater often stifle flow and frustrate developers. In that sense, TOSD’s critique is right on the money. On the other hand, the alternative which the paper proposes-that is to say, an extreme application of manufacturing principles including strict timeboxing and the suggestion that teams are optional-ignores some key realities of software work.

The Manufacturing Metaphor: Where the Analogy Breaks Down

TOSD leans on Ernst Weichselbaum’s Time-Oriented Work Systems and the Toyota Production System, using those models to make a case for fixed 1-to-3-day realization timeboxes and a push toward what’s basically flow manufacturing in software. There is value in borrowing from Lean principles, but to equate software development with car manufacturing is a category error.

When Toyota builds a Camry, the specifications are stable, the process is known and the goal is to minimize variability. But in software, variability is the norm. Requirements shift. Users change. Architecture evolves. During the Core Banking build we saw regulatory changes mid-sprint that rendered carefully planned work obsolete. Technical discovery during implementation regularly reshaped our understanding of what was needed. In short, the act of building software is a knowledge-generating process, not a repeatable manufacturing one.

TOSD’s idea that all conceptualization should be done upfront and all realization so perfectly specified as to raise “no further questions” is pure waterfall thinking with new branding. Even with highly mature teams, discovery happens during development. Often we don’t know what questions to ask until we’re knee-deep in the code.

Do We Really Not Need Development Teams?

The most provocative TOSD claim is that software development doesn’t require teams—just one or two people working on a job-sized chunk. That may be an intellectually intriguing assertion, but it’s practically dangerous.

Software teams exist not for efficiency but for resiliency, quality, and collective ownership. I’ve seen firsthand how knowledge silos cripple organizations. When one key developer left the Core Banking project, we lost weeks of momentum recovering undocumented design rationale. Teams spread knowledge, cross-pollinate ideas, and offer diverse perspectives that sharpen decision-making.

Good software design rarely emerges in isolation. Some of our best architectural leaps came from spontaneous whiteboard sessions where three or four engineers challenged assumptions and aligned on strategy. Peer review is another team-based practice that has improved quality and continuous learning. Even support and maintenance benefit from the team structures: software systems live for years, and continuity matters.

The real problem is not the existence of teams; it is how we misuse teams: fragmenting work across narrow roles, imposing rigid processes, and disconnecting teams from outcomes. TOSD rightly critiques this, but discarding the team model altogether is overcorrecting.

Where TOSD Gets It Right: Sprint Dysfunction

TOSD is at its best when diagnosing what’s broken about sprints. The dysfunctions are real, and I’ve lived them.

Over-Planning and Estimation Theater

Sprint planning sessions devolve into hours of estimation debates that serve no one. I’ve watched teams argue if a task is a 3 or a 5 while the really important uncertainties are ignored. Our planning sessions for Core Banking routinely dragged on 4+ hours. And, after all that effort, many estimates were obsolete in a matter of days. The cost of planning outweighed the value.

Rigid Boundaries Impede Flow

Fixed-length sprints force work into arbitrary timeboxes. When a story is ready on Thursday but we wait until Tuesday’s demo to deploy, we’re not optimizing for customer value–we’re optimizing for ceremony. I’ve watched critical regulatory changes sit in limbo because they didn’t align with our sprint calendar. That’s process dogma getting in the way of delivery.

Retrospective Theater

TOSD says it is not needed to do retrospectives if we talk to each other daily. I would not go that far, but surely many retrospectives have become an empty ritual. Teams are going through the motions without really changing anything. Continuous reflection should be just that: continuous, instead of biweekly theater.

What to Keep, What to Rethink: Flow Engineering as a Better Path

Instead, it calls for embracing the principles of Flow Engineering and Value Stream Thinking rather than throwing out teams or imposing hard 3-day boxes.

Focus on Cycle Time, Not Velocity

It is misleading to measure how many points a team completes. Instead, track how long it takes for customer requests to reach production. On the Core Banking project, shifting our focus to cycle time uncovered hidden delays and drove dramatic improvements in delivery.

Right-Size Work, Don’t Standardize It

TOSD prescribes 1-3-day realization jobs. It’s too rigid. The better goal is to reduce variability and risk by using smaller, more predictable chunks of work-but not by imposing uniformity. Some features take hours; others take a week. Clarity, not conformity, is the key.

Enable Continuous Flow

We replaced our sprint planning meetings with rolling backlog refinement. Developers pulled in the next high-priority item as they had capacity. We deployed to staging multiple times a week. Production deployments became event-driven, not sprint-driven. The outcome? More satisfied developers, fewer blockers, and a 40% reduction in cycle time.

Keep Teams – Redesign Structures

Organize teams around value streams, not tech layers. Give full end-to-end ownership to the teams. Minimize handoffs. Make collaboration easy and frictionless. This is where TOSD’s emphasis on reducing artificial boundaries aligns well with modern team design.

Practical Recommendations for Agile Practitioners

If you’re struggling with sprint dysfunction, here’s what I’d recommend:

1. Time-box your ceremonies, not your work: Limit sprint planning to one hour. If you can’t get through it, your backlog isn’t ready—that’s a refinement problem, not a planning problem.
2. Measure cycle time religiously: Track how long items take from “started” to “in production.” Make this metric visible and discuss it constantly.
3. Reduce work in progress (WIP): Nothing kills flow like too much concurrent work. Limit WIP strictly, even if it means developers occasionally wait for capacity.
4. Deploy continuously: If you’re batching deployments to sprint boundaries, you’re creating artificial delay. Automate your deployment pipeline and push to production whenever work is complete.
5. Keep teams, fix their structure: Instead of eliminating teams, organize them around value streams rather than technical layers. Give them end-to-end ownership and autonomy.

Conclusion : Nuance Over Dogma

TOSD is a valuable provocation. It reminds us that much of Agile today is stale and ritualistic. But replacing one dogma with another doesn’t help. Software is a uniquely complex, creative endeavor. It demands flexibility, experimentation, and empathy – not one-size-fits-all solutions borrowed from manufacturing. Agile at its best is not about sprints, points, or ceremonies. It’s about delivering value faster, learning continuously, and collaborating deeply. Flow Engineering, value stream mapping, and outcome-focused teams offer a better path forward than either traditional Scrum or TOSD’s radical manufacturing model. Let’s keep the conversation going.

What’s working in your context?

Where do sprints still serve you, and where do they hinder you?

How are you moving toward flow? I’d love to hear your story.

https://nielspflaeging.substack.com/p/sprints-were-never-a-path-to-agility

https://betacodex.org/white-papers/paper/introducing-time-oriented-software-development-26