Hard-Agile: Throughput Over Velocity Theater

The Agile Industry Has a Problem

Somewhere in the last ten years, “deliver working software” turned into something else. Something with certificates, happiness surveys and retrospectives where everyone shares their feelings while the backlog rots.

We call it velocity theater.

Teams measure story points. They estimate in Fibonacci numbers. They celebrate sprint closures. And at the end of the quarter, management asks: “Why is the feature still not live?” The answer is a PowerPoint slide with a rising velocity curve that means nothing.

Velocity measures how much a team trusts itself. Not how much it delivers.

We have seen this often enough. At mid-sized software companies, at internal dev teams, at organizations that were “agile-transformed” and ended up slower than before. The problem is not agility. The problem is what the industry made of it.

What We Do Instead

We work according to what we call Hard-Agile. It sounds provocative, but it is simple: we measure what matters. No abstract point systems. No relative estimates that every team interprets differently. Metrics that everyone in the company understands, from developer to CEO.

Throughput. How many tasks leave the system per week? Not how many come in. Not how many are “in progress.” How many are done.

Cycle time. How long does a task take from “started” to “shipped”? Not until “done developing.” Until the customer can use it.

Flow. Where does it stall? Where do tasks wait for reviews? Where does a dependency block everything else?

This is the Kanban method in its pure form. No proprietary framework. No certification. No two-day training before anyone starts working. We look at what is there, find the bottlenecks and make it faster.

Kanban starts with what you have. No big bang. No “first we need to change everything.” We improve what exists.

Why Scrum Ceremonies Often Fail to Deliver

Scrum is not bad. Scrum is done badly.

Two weeks of sprint planning. Daily standups that last 45 minutes. Sprint reviews where the team explains to the product owner why half the stories did not get finished. Then a retrospective where everyone says they need “better communication.”

The problem: the ceremonies become an end in themselves. The team spends 20 percent of its time in meetings about the work and 80 percent on the work itself, if things go well. Often the ratio is worse.

We do not eliminate ceremonies. We ask about each one: Does this contribute to delivery? If yes, it stays. If it is a ritual that nobody questions because “that is just what we do,” it goes.

“Are we doing Scrum right?” is the wrong question. The right one: “Are we shipping faster than three months ago?” If you cannot answer it with numbers, you have a measurement problem. And a measurement problem is a delivery problem.

100-Day Cycles Instead of Endless Sprints

A sprint has no natural endpoint. Sprint 47 looks like Sprint 12. Nobody asks: “What did we actually achieve in the last 47 sprints?”

We work in 100-day cycles with measurable goals. Before day one, success is defined. After 80 days, we measure: goals met or not? No room for interpretation. Numbers.

This changes the dynamic. When the team knows there is a reckoning in 80 days, discussions about velocity points disappear. What matters is: are we delivering what we promised?

What Happened at Novadex

At Novadex, a software company in Baden-Württemberg, we restructured the development organization. SVN to GitLab. Scrum to Kanban. Bare metal to Kubernetes.

The result that counts: Cycle time reduced to 10 days.

Ten days from “task started” to “feature in the customer’s hands.” Measured on the live system, week after week.

That is the difference between velocity theater and Hard-Agile. Velocity would have told us the team “does 52 points per sprint.” What does that mean? Nothing. Cycle time says: in ten days it is live. Everyone understands that, including management, who have no idea what a story point is but know exactly what ten days means.

Before, the team was good. After, the team was fast. And the team internalized the new process instead of merely tolerating it, because the numbers speak for themselves. No change management needed when the results are obvious.

Cutting Through the Noise

The agile industry built a business model out of ceremonies. Certifications. Coaching programs. Two-day workshops after which everyone feels better and nothing changes.

We are not agile coaches. We do not come to run workshops, facilitate retrospectives or teach teams how to sort their post-its better.

We come to measure what ships. To find bottlenecks. To eliminate them. And to leave after 100 days because the team can do it on their own.

Everything else is noise.