The SDLC: waterfall, agile, Scrum and Kanban

What is the SDLC?

SDLC stands for software development life cycle. It is the list of phases that turn an idea into working software and then keep it working. Every team goes through these phases, even if they do not use the names.

Waterfall: one phase after another

In the waterfall model, each phase finishes completely before the next one starts, like water falling down steps. Requirements are written and signed off, then design, then months of coding, then testing, then one big release.

Waterfall works when requirements are fixed and well understood, for example some government contracts or safety systems. Its weakness is late feedback. Users see the product only at the end, maybe a year later. If the requirements were wrong, a lot of work is wasted, and changes late in the project are expensive.

Agile: short cycles and early feedback

Agile is a family of methods that build software in short cycles, often one to four weeks. Each cycle goes through all the phases on a small piece of work and ends with something working that users can see. The Agile Manifesto (2001) values individuals and interactions, working software, customer collaboration and responding to change.

Scrum in brief

Scrum is the most popular agile method. Work happens in sprints: fixed time boxes of one month or less, often two weeks. The Scrum Guide names three accountabilities (roles):

• Product Owner: decides what is most valuable and orders the product backlog (the to-do list of features).
• Scrum Master: helps the team follow Scrum and removes blockers.
• Developers: everyone who builds the product increment, including testers and designers.

Scrum has five events (ceremonies): the Sprint itself, Sprint Planning (choose the work), the Daily Scrum (a 15-minute daily check-in), the Sprint Review (show the result to stakeholders) and the Sprint Retrospective (discuss how to work better).

Many teams estimate work in story points, a relative size such as 1, 2, 3, 5 or 8. Velocity is the number of story points a team finishes in a sprint. Averaging recent velocity helps forecast how many sprints a backlog will take. Story points and velocity are common practice but are not part of the official Scrum Guide.

Kanban in brief

Kanban comes from Toyota factories. Work items are cards on a board with columns such as To do, Doing, Review and Done. There are no fixed sprints: work flows continuously. The key rule is a WIP limit (work in progress limit): a maximum number of cards allowed in a column. If Review has a limit of 2 and already holds 2 cards, nobody starts new work; they help finish reviews first. This exposes bottlenecks and shortens the time each item takes.

User stories and the definition of done

A user story describes a need from the user’s point of view: "As a passenger, I want to download my ticket as a PDF, so that I can show it without internet." Acceptance criteria list the conditions that must be true for that story, for example "the PDF shows the PNR number".

The definition of done is a checklist that applies to every story: code reviewed, automated tests pass, deployed to staging, documentation updated. In a DevOps team, "done" often means "running in production and monitored", not just "code written".

Where DevOps fits

Agile made the build and test phases fast. But many agile teams still waited weeks for an operations team to release their work. DevOps extends agile thinking to the last phases, release and operate, through automation and shared ownership. Agile asks "are we building the right thing in small steps?" DevOps adds "can we ship each small step safely, and learn from how it runs?"