The Development Lifecycle: Agile and Waterfall

Software is planned. The usual name for that plan is the systems development life cycle: requirements, design, build, test, deploy, maintain. The fight in the contract is rarely about the six words. It is about whether the team may change its mind in the middle.

Waterfall

Waterfall moves in one direction. The parties spend months on a scope document. The builders disappear. Months later they present a finished system. By then the business may have changed, or a requirement on page 40 was read two ways. Changes are expensive because each stage was treated as closed. Disputes show up as missed milestones and arguments about a specification nobody can bear to reopen.

Agile

Agile breaks the same life cycle into short iterations, often called sprints, commonly about two weeks. Sprint one might be only sign-in. Sprint two might be only the catalogue. The product grows by slices, and the slice list moves as people learn.

Traditional contract drafting prefers a fixed price, a fixed scope, and a date. Agile prefers a moving scope inside a cadence. If the engineers are working in sprints and the contract is a waterfall template, both sides can be sincere and still be in breach of each other’s expectations. The developers will change a feature because that is the method. The client will point at the original schedule of items and call it a defect.

What to draft toward

You do not have to pretend to run the engineering team. You do have to stop using one method’s contract for the other method’s build. An agile engagement needs a way to record what entered the sprint, what left it, and what “accepted” means for that slice. A waterfall engagement needs a change-control gate that is honest about how hard a late change is.