The Software Development Process: SDLC, Agile and Contracts

A circular red ribbon passing through six stations representing the phases of software development — Six phases, run once or run in cycles. The choice is the whole argument.

In short

The software development lifecycle (SDLC) is the sequence every project passes through: discovery, design, build, test, release and operate. Traditional sequential delivery completes each phase once, in order, and suits work whose requirements genuinely cannot change. Agile delivery repeats the whole sequence in short increments, and suits work where the requirements will be discovered while building. The choice is not about fashion, it is about whether your requirements are knowable up front.

Arguments about agile versus waterfall usually generate more heat than insight, because both sides are describing a real project they worked on and generalizing from it. The useful question is narrower: can your requirements be known before the build starts?

This page sets out the phases every project runs through, compares the two delivery shapes honestly including where each fails, and covers the part most articles skip, which is that a delivery method with the wrong contract underneath it will fail regardless of how well the team works.

Key takeaways

Every project runs the same phases. The methodology decides how many times you run them and how early you learn you were wrong.
Sequential delivery is the right answer when the specification is genuinely fixed, for example a regulated replacement of a known system.
Agile is the right answer when you expect to discover requirements. It costs more coordination and buys earlier feedback.
The contract shape has to match the method. A fixed-price contract over an agile scope produces a change request argument every sprint.
Most failures trace to skipped discovery or an untested release process, not to the choice of methodology.

The phases every project runs through

Six stepping stones with engraved phase symbols crossing water, marked by red footprints — Every project crosses all six. Skipping one just moves it later.

These six phases occur in every project, whether or not anyone names them. A team that skips discovery has still made a discovery decision, and it has decided to make its assumptions later and more expensively.

Discovery. What problem, for whom, and what does success look like. Produces scope, constraints and the riskiest assumptions.
Design. Architecture, data model, interfaces and the user experience. See UI and UX design.
Build. Implementation, code review, and continuous integration.
Test. Functional, integration, performance and security testing. See QA and testing.
Release. Deployment, migration, rollback plan. See DevOps and cloud.
Operate. Monitoring, support, and the feedback that starts the next cycle.

Every project runs these phases. The methodology decides how many times, and how early you find out you were wrong.

Traditional sequential delivery compared with agile

A single long staircase to one flag beside a series of small loops each planting its own flag — One big answer at the end, or many small answers along the way.

Sequential delivery, often called waterfall, runs each phase once in order and completes it before the next begins. Its strength is predictability: with a genuinely fixed specification you can plan the whole project and commit to a date and a price. Its weakness is that you learn whether the plan was right at the end, when correcting it is most expensive.

Agile delivery runs the same phases repeatedly over short increments, releasing working software each time. Its strength is early feedback: a wrong assumption surfaces in weeks. Its weakness is that it needs a product owner who can decide, a team that can be trusted to make calls, and a commercial arrangement that tolerates a scope that moves.

Neither is universally better. A payments migration with a regulator-approved specification is a sequential project. A new product whose users have not seen anything yet is an agile one. The expensive mistake is running one and reporting on the other, which is where a great deal of process theater comes from.

Both are correct answers to different questions. The failure mode is running one while reporting the other.

Which one suits your project

A figure at a junction where one road is paved in large slabs and the other in many small bricks — Answer whether the requirements can be frozen, and the branch chooses itself.

Rather than choosing by preference, answer these questions. If most of your answers fall on the left, you have a sequential project. If most fall on the right, forcing a fixed plan onto it will produce a plan that is wrong and a team that knows it.

Can the requirements be written down now? If yes, sequential is viable. If they will be discovered by watching users, it is not.
How expensive is a wrong assumption? If very, buy early feedback with short increments.
Is there a decision maker available weekly? Agile without an available product owner degrades into the team guessing.
Is a hard external date attached? A regulatory or contractual date favors fixed scope with explicit descoping rules.

The methodology decision, as a decision

Can the requirements be written down, agreed and frozen before the build starts?

Yes, and they genuinely will not move

Run sequential delivery with a fixed scope and a committed date.

Predictability is what sequential delivery is for, and a truly fixed specification is the one condition under which it works.
No, and a decision maker is available weekly

Run agile delivery in short increments with a capped time and materials contract.

You are buying early feedback on assumptions that will move, and the contract shape has to tolerate the movement.
No, and no decision maker can attend weekly

Fix the availability problem before choosing a method.

Agile without an available product owner degrades into the team guessing, which is the worst of both worlds.
A hard regulatory or contractual date is attached

Fix the scope, write explicit descoping rules, and rehearse the release early.

A date you cannot move means scope is the only variable left, so the descoping order has to be agreed before the pressure arrives.

Answer the question honestly and the branch chooses itself. Choosing by preference is how projects end up running one method and reporting the other.

What a working agile week actually contains

Five day columns with small ceremony scenes woven together by a single red thread — Every ceremony earns its slot by producing something. Otherwise it is a meeting.

Agile has accumulated a liturgy of ceremonies, and teams often adopt all of them without asking what each one is for. Every ceremony below earns its place by producing a specific output; a ceremony run without its output is a meeting, and meetings are a cost.

The test for each one is simple: if the ceremony were canceled this week, what would go wrong? If the honest answer is nothing, cancel it. The goal is the outputs, not the ritual.

The ceremonies and what each one is actually for

Ceremony	Cadence	The output it must produce	What goes wrong without it
Planning	Each increment	A scoped, agreed slice of work the team believes it can finish	The increment fills with whatever was loudest, and nothing finishes
Standup	Daily, short	Blockers surfaced while they are hours old	Blockers age silently until they surface as missed work
Review or demo	Each increment	Working software in front of the decision maker, and a decision	Feedback arrives months late, at the price of months of rework
Retrospective	Each increment	One named process change, with an owner	The same friction recurs every increment and becomes culture
Backlog refinement	Weekly	The next increment of work made small and unambiguous	Planning becomes an estimation argument about work nobody understands

Each ceremony exists to produce the output in the third column. A ceremony that stops producing its output should be fixed or canceled, not attended.

The process terms this page assumes

Increment (or sprint): A short, fixed window, commonly one to two weeks, that ends with working, reviewable software. The fixed length is the point: it forces scope to be cut rather than dates to slip.
Backlog: The ordered list of work not yet started. Ordered is the operative word: an unordered backlog is a wish list, and a wish list cannot drive planning.
Definition of done: The written standard a piece of work must meet before it is declared complete: reviewed, tested, deployed to a real environment, accepted. Without one, done means different things to different people.
Product owner: The single person empowered to decide what gets built next and to accept or reject the result. Empowered is the requirement; a proxy who must check with a committee is not a product owner.
Continuous integration: Every change merged and automatically built and tested against the whole system within minutes, so integration problems surface one change at a time instead of all at once at the end.
Velocity: A team’s own recent completion rate, used to size the next increment. It is a planning input for that team only; comparing velocity across teams or vendors measures nothing.

Definitions as this site uses them. Vendors use some of these loosely, which is worth knowing when reading a proposal.

The same loop repeats every increment. Each ceremony appears exactly where its output is needed, which is the test for keeping it.

The contract has to match the method

A contract-shaped puzzle piece joining perfectly with a loop-shaped piece, a mismatched pair faint behind — A fixed price over a moving scope turns every discovery into a dispute.

This is the part that sinks projects that were otherwise going well. A fixed-price contract is a commitment to a defined scope, so every discovery becomes a change request, and the vendor is now financially rewarded for saying no to improvements. That is not bad faith, it is the incentive the contract creates.

Time and materials matches iterative delivery because it prices effort rather than scope, but it moves budget risk to you, so it needs a cap, a review cadence and the right to stop. A capped time and materials arrangement with a defined review point is usually the honest middle: the client controls spend, the vendor is not punished for learning.

The contract mistakes that actually recur are avoidable in the drafting, and they are worth naming because every one of them is discovered on the worst possible day. Signing a fixed price against a scope that is still moving, which converts every discovery into an adversarial change order. Leaving intellectual property assignment until final acceptance instead of tying it to payment, which makes ownership of the completed work contestable exactly when the relationship is ending. Accepting vendor-side repositories and infrastructure, which hands the vendor leverage no clause can claw back. And omitting a defined exit: without named handover artifacts and a stated block of transition hours, handover is a promise from an organization that has just lost your account. The clause-by-clause version of this list, with what a refusal of each one usually means, is in our guide to evaluating a software development partner.

Nobody removes risk, the contract only decides who carries it. Capped time and materials with a review point is usually the honest middle.

The definition of done, written out

Three figures from different roles all looking at one monolithic checklist board with six checked lines — The value is not the items, it is everyone using the same list.

Of everything on this page, this is the artifact that costs the least and prevents the most. A definition of done is a short written standard that every piece of work must meet before anyone calls it complete. Without one, complete means compiled to one engineer, demoed to another, and shipped to the person paying, and the gap between those three definitions is where late projects live.

The list below is a working default. Adjust it to your context, but adjust it in writing, and make it the standard the vendor accepts in the contract, because a definition of done that lives only in a slide deck binds nobody.

A working definition of done

Reviewed by a second engineerEvery change read by someone who did not write it, with the review recorded where it can be found later.
Tests written and passingAutomated tests covering the behavior that was added or changed, running in continuous integration, not on one laptop.
Deployed to a production-like environmentThe change running somewhere that resembles production closely enough that deployment itself has been rehearsed.
Documented where the next person will lookNot a manual, a paragraph: what changed, why, and anything the operator or the next engineer needs to know.
Accepted by the product ownerThe person who asked for the work has seen it working and said yes, in writing, against the acceptance criteria.
Observable in monitoringIf the change can fail in production, there is a signal that will say so before a customer does.

A piece of work meets this standard or it is not done. The value is not in the items, it is in everyone using the same list.

Where projects actually fail

A hand placing a small red wedge that stops a run of dominoes from falling — The recurring causes are mundane, and all cheaper to prevent than to fix.

In our experience the methodology is rarely the cause of death. The recurring causes are more mundane, and all of them are cheaper to prevent than to fix.

Discovery skipped to save time. The assumptions are still made, just later and in code.
No definition of done. Work is declared complete at different standards by different people.
Testing deferred to the end. Defects found after integration cost multiples of what they cost at the unit.
An untested release process. The first real deployment should not be the first deployment.
A contract that fights the method. Fixed price over an exploratory scope guarantees an adversarial relationship.

Frequently asked questions

What are the phases of the software development lifecycle?

Discovery, design, build, test, release and operate. Sequential delivery completes each once in order; agile delivery repeats all of them in short increments.

Is agile better than waterfall?

Neither is universally better. Sequential delivery suits work whose requirements are genuinely fixed and known, such as a regulated replacement of an existing system. Agile suits work where requirements will be discovered during the build. The mistake is choosing by preference rather than by whether the requirements are knowable up front.

Which contract type suits agile development?

Capped time and materials with a defined review point and a right to stop. A fixed-price contract over an exploratory scope turns every discovery into a change request and financially rewards the vendor for resisting improvement.

Why do software projects fail?

Most often because discovery was skipped, there was no shared definition of done, testing was deferred until after integration, the release process was never rehearsed, or the contract shape fought the delivery method. The choice of methodology is rarely the primary cause.

What is a definition of done in software development?

A short written standard every piece of work must meet before it is called complete: reviewed by a second engineer, covered by passing automated tests, deployed to a production-like environment, documented, accepted by the product owner, and observable in monitoring. Its value is that everyone, including the vendor, is using the same list, which is why it belongs in the contract rather than in a slide deck.

Do we need all the agile ceremonies?

You need the outputs, not the rituals. Planning must produce an agreed slice of work, the standup must surface blockers while they are hours old, the review must put working software in front of a decision maker, and the retrospective must produce one named process change. A ceremony that stops producing its output should be fixed or canceled, and the test is to ask what would go wrong if it were canceled this week.