The software development lifecycle (SDLC) is the sequence of stages software goes through from idea to retirement: planning, requirements, design, implementation, testing, deployment, and maintenance. Every team goes through these stages, whether or not it names them. What differs between models like waterfall, Scrum, Kanban, and DevOps is how the stages are ordered, how much work moves through them at once, and how quickly feedback comes back.
This article explains each phase, compares the main models side by side, and shows what a practical lifecycle looks like in a team of three to eight people.
The seven phases
Sources group these slightly differently. Some merge planning and requirements, others treat testing as part of implementation. The underlying work is the same.
| Phase | Question it answers | Typical outputs | Risk if rushed or skipped |
|---|---|---|---|
| Planning | Should we build this, and is it worth it now? | Goal, rough scope, priority, time or budget limit | Building something nobody needs |
| Requirements | What exactly must it do? | User stories, acceptance criteria, non-functional requirements such as performance and security | Rework when stakeholders finally see the result |
| Design | How will we build it? | Architecture sketch, data model, API contracts, UI mockups, design doc | Expensive rewrites and inconsistent systems |
| Implementation | Build it | Code, code reviews, unit tests | Code that’s hard to review, test, or change later |
| Testing | Does it work, and will it keep working? | Automated tests, exploratory testing, bug reports | Users find the bugs for you |
| Deployment | How does it reach users safely? | Release, migrations, rollout and rollback plan, release notes | Downtime and releases you can’t undo |
| Maintenance | How do we keep it healthy? | Bug fixes, monitoring, dependency updates, eventual retirement | Security holes and slow decay |
Three things the table doesn’t show:
- Maintenance is usually the longest phase. A feature built in a month may run for years. Design and testing decisions should account for the people who will maintain it.
- Security belongs in every phase, not only in a final check: threat modeling during design, dependency scanning during implementation, security tests during testing.
- Phases overlap in practice. Most modern teams design, build, and test a small slice of a feature within the same week, then start the loop again.
The main models
Waterfall
Waterfall runs the phases in sequence. Each phase finishes, often with a formal sign-off, before the next begins. Requirements are fixed early, testing happens after implementation, and the software is delivered at the end.
It gets criticized a lot, but it still fits some situations: requirements fixed by regulation or contract, hardware or embedded work where changes after manufacturing are costly, and clients who expect a fixed scope at a fixed price. Its weakness is late feedback. If the requirements were wrong, you find out after most of the budget is spent.
Agile
Agile isn’t a single process. It’s a set of values and principles published in 2001 as the Manifesto for Agile Software Development, which values “individuals and interactions over processes and tools,” “working software over comprehensive documentation,” “customer collaboration over contract negotiation,” and “responding to change over following a plan.” The manifesto is explicit that the items on the right still have value; the ones on the left are valued more.
In lifecycle terms, agile means running all the phases in short loops, delivering working software frequently, and adjusting based on what you learn. Scrum and Kanban are two common ways to put that into practice.
Scrum
Scrum, defined in the Scrum Guide, organizes work into Sprints: fixed-length cycles of one month or less. A Scrum Team is small, typically 10 or fewer people, with three accountabilities. The Product Owner maximizes the value of the product and manages the Product Backlog. The Scrum Master helps the team and organization use Scrum effectively. The Developers build a usable Increment every Sprint.
Each Sprint contains four events: Sprint Planning, a 15-minute Daily Scrum, a Sprint Review with stakeholders, and a Sprint Retrospective where the team improves how it works. Work counts as done only when it meets the team’s Definition of Done.
Scrum works well when you need regular, predictable checkpoints with stakeholders and can plan a few weeks ahead. It strains when most of the work is unpredictable, such as support tickets and incidents, because the Sprint plan keeps getting interrupted.
Kanban
Kanban has no fixed iterations. The Kanban Guide defines it as a strategy for optimizing the flow of value through a process, built on three practices: defining and visualizing the workflow, actively managing the items in it, and improving it over time. Its central control is limiting work in progress: the team explicitly decides how many items can be started but not yet finished.
The guide names four flow measures to track: work in progress (WIP), throughput, work item age, and cycle time. In practice that usually means a board with columns such as To do, In progress, Review, and Done, plus a rule like “no more than three items in progress at once.” Kanban suits maintenance work, support, platform teams, and small teams whose priorities change daily.
DevOps
DevOps is less a lifecycle model than a culture and set of practices that join development and operations, so deployment and maintenance stop being a handoff to another team. In practice it means continuous integration (every change is built and tested automatically), continuous delivery (every change that passes can be deployed), infrastructure defined as code, good monitoring, and the team that builds a service also running it.
DORA (DevOps Research and Assessment) measures software delivery performance with a small set of metrics: change lead time, deployment frequency, failed deployment recovery time, change fail rate, and deployment rework rate. They’re useful for any team that wants to know whether it’s getting faster without getting riskier.
DevOps combines with Scrum or Kanban rather than replacing them. A Scrum team with a solid pipeline can deploy many times within a single Sprint.
Comparison table
| Waterfall | Scrum | Kanban | DevOps | |
|---|---|---|---|---|
| Rhythm | One pass through all phases | Sprints of one month or less | Continuous flow | Continuous integration and delivery |
| Planning | Detailed, upfront | Every Sprint, guided by a Product Goal | Continuous; new work is pulled as capacity frees up | Comes from the process it’s paired with |
| Handling change | Formal change requests | Mostly between Sprints | Any time, by reordering the queue | Small, frequent releases make each change cheaper |
| Roles | Phase specialists and a project manager | Product Owner, Scrum Master, Developers | None prescribed | Shared ownership of building and running |
| What you measure | Milestones, budget, scope | Sprint Goal met, usable Increment delivered | WIP, throughput, work item age, cycle time | DORA delivery metrics |
| Best fit | Fixed requirements, regulated or contract work | Product work that needs regular stakeholder feedback | Unpredictable, interrupt-driven, or maintenance work | Any team running a live service |
| Watch out for | Discovering wrong requirements too late | Ceremonies without real feedback | Little forward planning; items that never finish | Buying tools without changing how people work |
What it looks like in a small team
A team of three to eight people, say a small company building a mobile app and its back end, rarely needs a formal framework. A lightweight lifecycle that still covers every phase can look like this:
- Planning: a short weekly session to pick priorities from one ordered backlog. One person, often the founder or product lead, has the final say on order.
- Requirements: each item gets a short description with acceptance criteria. Bigger features get a one-page spec.
- Design: anything touching the data model, a public API, or payments gets a brief design doc that someone reviews before coding starts.
- Implementation: short-lived branches, small pull requests, and code review on every change.
- Testing: automated tests run in CI on every pull request, and someone tries the feature on a real device before release.
- Deployment: the back end deploys automatically after merging, with a quick way to roll back. Mobile releases go out on a regular schedule with some buffer, because app store review adds a step the team doesn’t control.
- Maintenance: crash reports and error alerts go to a shared channel, and one person each week owns triage.
Add a simple Kanban board with a WIP limit to keep work flowing, and a short retrospective every two weeks that asks what slowed the team down. That’s Kanban plus DevOps practices plus one event borrowed from Scrum. Mixing like this is normal; few teams run any model exactly by the book.
Example: one feature through the lifecycle
Say users keep emailing support because they can’t reset their password in your app.
- Plan: the support load makes it this week’s top priority.
- Requirements: users request a reset link by email; the link expires and works only once; the response never reveals whether an email address is registered.
- Design: a reset-token table with an expiry time, two API endpoints, and rate limiting on reset requests.
- Build and test: two small pull requests, the API first and then the app screens, with tests for expired and reused tokens.
- Deploy: the API ships behind a feature flag; the app update follows in the next scheduled release.
- Maintain: watch error rates and support emails for a week, then remove the flag.
Every phase happened, none of them took more than a day or two, and nothing needed a heavyweight process.
Common misconceptions
- “Agile means no planning or documentation.” The manifesto values working software more than comprehensive documentation. It doesn’t say documentation is worthless, and agile teams still plan, just in shorter horizons.
- “Scrum and agile are the same thing.” Scrum is one framework for applying agile values. Kanban is another, and many teams use neither in pure form.
- “DevOps is a job title or a tool.” It’s a way of working. Buying a CI service without changing who owns production doesn’t make a team DevOps.
- “Small teams don’t need an SDLC.” Every team already has one. The question is whether it’s deliberate or accidental.
How to choose for your team
- If requirements are fixed by contract or regulation and change is expensive, plan more upfront and use phase sign-offs, even if you build iteratively within them.
- If you’re still discovering what users want and need regular stakeholder feedback, start with Scrum.
- If work arrives unpredictably, or the team is small and wears many hats, start with Kanban.
- Whatever you choose, adopt DevOps practices such as CI, automated deployment, and monitoring as soon as anything is running in production.
Next step: map your current process
Write the seven phases down the left side of a page. Next to each, note what your team actually does today, who owns it, and what it produces. The phase with the emptiest row is where your next improvement belongs. If you’re early in your career, this vocabulary also comes up in interviews and day-to-day team discussions, and it’s part of the skills every software engineer needs to grow.