The Software Development Process

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.

The phases every project runs through

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.

Traditional sequential delivery compared with agile

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.

Which one suits your project

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 contract has to match the method

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.

Where projects actually fail

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.