Lifecycle Models

The phases that always exist

Every project does the same things: understand the need, design a solution, build it, verify it, release it, and support it. What differs between models is the sequence, the batch size, and how late you can change your mind.

Waterfall

Sequential phases, each completed and signed off before the next begins. Its virtues are real: clear documentation, defined scope, straightforward contracting, and a natural fit for regulated and safety-critical work where the specification must be approved and traceable.

Its weakness is equally real: it assumes requirements are known and stable at the start. Where they are not — which is most business software — errors made in the first phase are discovered in the last, when they are most expensive. It also delivers nothing usable until the end, so there is no feedback until the whole investment has been made.

V-model

A waterfall variant pairing each development phase with a corresponding test level: requirements with acceptance testing, system design with system testing, detailed design with integration testing, and code with unit testing. Widely used in regulated, automotive and safety-critical development because the verification traceability is explicit.

Iterative and incremental

Build in repeated cycles, each producing something that works. Incremental means delivering functionality in pieces; iterative means refining what exists through repeated passes. Most modern approaches do both.

Agile

Agile is a set of values rather than a method: working software over comprehensive documentation, customer collaboration over contract negotiation, responding to change over following a plan, and individuals and interactions over processes and tools. The clause people forget is the qualifier — there is value in the items on the right; the claim is only that the left has more.

• Scrum — fixed-length sprints, a prioritised backlog, defined roles (product owner, scrum master, developers), and the events: planning, daily coordination, review and retrospective.
• Kanban — continuous flow, visualised work, explicit limits on work in progress, optimising cycle time. No fixed iterations.
• Extreme programming — the engineering practices: test-driven development, pair programming, continuous integration, refactoring, simple design.

What agile requires to work

Agile without its engineering practices produces short deadlines and accumulating defects. It depends on automated testing, continuous integration, the ability to release small changes safely, and a genuinely available business representative who can decide. Organisations that adopt the ceremonies and not the practices get the overhead without the benefit — and then conclude that agile does not work.

Choosing

Sequential approaches suit stable, well-understood requirements, regulatory traceability, fixed-price contracts and physical integration deadlines. Iterative approaches suit uncertain requirements, evolving products, and anything where early feedback changes what should be built. Most real organisations run a hybrid, and the honest question is not which is fashionable but how much the requirements are likely to change.