Most software teams follow some version of the same lifecycle: gather requirements, design, build, test, deploy, maintain. It is drawn as a tidy sequence, each phase feeding the next, and on a whiteboard it looks like good sense. In practice, each phase has grown a layer of ceremony, and that ceremony pushes the only outcome that matters, working software in front of users, further and further out.
The lifecycle itself is not the problem. The problem is treating its phases as gates you pass through once, in order, when the constraints that made that order necessary stopped existing years ago.
The sequence was built for a world that shipped on discs
The strict phase-by-phase model made sense when releasing software meant burning a master disc, manufacturing copies, and mailing them. In that world you got one shot. A bug found after the discs shipped meant a recall or a printed errata sheet, so it was rational to spend months nailing down requirements and testing exhaustively before committing to physical media.
Almost none of that constraint survives. You can deploy a fix to every user in minutes, roll it back just as fast if it misbehaves, and ship again an hour later. When the cost of being wrong drops from a recall to a redeploy, the logic for front-loading every decision drops with it. Holding to the old sequence now is a habit dressed up as discipline.
Every phase grew a tax
Read each phase as it is practiced and you can see where the weight accumulated:
- Requirements come first, so teams try to write all of them down before anyone builds anything. The document is out of date the moment a user touches the product, because people do not know what they want until they see it in front of them. You are asking for precise answers at the point of maximum ignorance.
- Design runs long because it gets treated as a phase to complete rather than something you learn by building. A diagram that looks clean in a review reveals its bad assumptions the first time someone writes code against it.
- Testing gets pushed to the end, which is the most expensive place to find anything. A defect caught while the code is being written is cheap to fix, a pattern Barry Boehm documented in his work on software economics decades ago. The same defect found after release costs far more, because now it is tangled into everything built on top of it.
- Deployment becomes a rare, dreaded event. Because it is rare it is risky, because it is risky teams do it less, and doing it less makes the next one riskier still. The dread is self-fulfilling.
None of these are failures of the people involved. They are the predictable result of running phases in sequence when the cost structure that justified the sequence is gone.
Small batches beat big ones
The strongest evidence against the big-bang release is how the fastest teams work, and it runs against the intuition. The instinct is that shipping carefully and rarely is safer than shipping often. The data says the opposite. Google's DORA program has surveyed tens of thousands of engineers over more than a decade in its State of DevOps research, and the pattern holds year after year.
The highest-performing teams deploy on demand, often several times a day, and the time from committing a change to running it in production is under an hour. The lowest-performing teams deploy somewhere between monthly and once every few months. Here is the part that breaks the intuition: the teams that deploy fastest are also the most stable. Speed and reliability rise together, they do not trade off. Deploying often does not make you fragile, it makes you practiced, and small frequent changes are easier to reason about and safer to reverse than large infrequent ones.
The mechanism is batch size. A release that bundles three months of changes is a haystack, and when something breaks you search the whole stack for the needle. A release that carries one change tells you exactly where to look when it misbehaves. Small batches turn debugging from an investigation into a glance.
What we do instead
We keep every activity in the lifecycle and change how they are spread out. Instead of a dedicated phase for each, we do a little of all of them, continuously.
Scope stays tight and rolling. We decide what the first version needs, build it, and leave the rest for later rather than specifying a year of work up front. Testing runs next to the code, so problems surface while they are still cheap. Deployment is automated and frequent, so a release is a routine step rather than a milestone with a countdown. Launch is not the finish line, it is the point where the learning starts, because how people use the thing is information you cannot get any other way.
Continuous does not mean half-finished features landing in front of users. Work that is not ready ships behind a feature flag, merged into the codebase and deployed but switched off, so the team integrates in small steps without exposing anything early. That is how you get the safety of frequent deploys without the risk of a visible half-built feature.
For the construction company we worked with, this meant a working portal in four months instead of a signed-off specification for one. For a healthcare provider, it meant a live product in six months where the previous approach had produced half a product in two years. In both cases the gain did not come from working harder inside the phases. It came from refusing to wait for one phase to finish before starting the next.
Which ceremonies to keep and which to cut
Cutting process is not the same as having none, and the goal is not a free-for-all. The goal is that every step earns its place. The test for any given ritual is one question: does this move the product toward users, or only toward more meetings? Run each habit through it.
Worth keeping:
- A short daily check that surfaces blockers, so someone stuck for a day does not stay stuck for a week.
- Code review, because a second set of eyes catches what the author cannot see.
- Automated tests that run on every change, because they are what make frequent deployment safe.
- Enough design thought to avoid the expensive mistakes, done just ahead of the code rather than a year before it.
Worth cutting:
- A standup that exists because the framework calls for one, where everyone recites status to a manager and nobody leaves unblocked.
- A requirements document so detailed it will be obsolete before the first feature ships.
- A sign-off gate whose only function is to record that a gate was passed.
- A release calendar that batches changes into rare events for no reason other than that is how it has always been done.
The line is not process bad, speed good. It is that a step should pay for the time it costs, and most teams have never audited theirs against that standard.
When the heavy process is the right call
There are places where the slow, sequential, document-everything approach is correct, and it would be dishonest to pretend otherwise. If a bug in your software can kill someone or move millions of dollars by mistake, the ceremony is the point. Medical device firmware, avionics, and the core of a payments settlement system are supposed to be hard to change, because the cost of a bad change is catastrophic and hard to reverse in a way a web app's is not.
The mistake is importing that rigor into contexts that do not carry the risk. A patient-facing scheduling portal is not a pacemaker. Most business software sits far on the safe side of that line, and running it with pacemaker-grade process buys you none of the safety and all of the delay.
Start shipping sooner
If your process has a long stretch where nobody outside the team can see anything, that is the first stretch to shorten. Get a small, working version in front of users early, and let what you learn there shape the rest, rather than committing a year of guesses to a specification.
This works best with a small team holding the whole picture, which is the other half of the same story. We cover that in why small teams ship software faster. Both come down to the same idea: the distance between an idea and something a person can use is the number worth optimizing, and almost everything else is negotiable.
