Software development process
A software development process is the overall approach a team uses to plan, structure, and control its way through the Software development life cycle, deciding how much to build at once, in what order, with which meetings, roles, and rules.
If the SDLC is the list of stages (requirements, design, build, test, release, maintain), the software development process is the strategy for moving through them. This article is the untangler: it fixes the vocabulary so that Waterfall, Agile, Scrum, sprints, and “the methodology” stop blurring together.
Also known as
software development methodology · development methodology · process model · software process model · SDLC model · “the way we work” · (very loosely) “the SDLC”
These are used almost interchangeably in industry. Purists draw fine distinctions (a process model is the abstract shape; a methodology bundles it with practices, roles, and philosophy) but you can treat them as synonyms in most conversations.
The vocabulary, from most abstract to most concrete
This is the ladder that trips everyone up. Read it top to bottom:
| Level | Term | What it is | Examples |
|---|---|---|---|
| 1 | Life cycle (SDLC) | The stages work passes through. | requirements → design → build → test → release |
| 2 | Process model / methodology | The approach to moving through the stages. | Waterfall, Iterative, Spiral, V-model, Agile |
| 3 | Framework / method | A concrete, named implementation of an approach. | Scrum, Kanban, XP |
| 4 | Practice / technique | A single activity used within a framework. | pair programming, Sprint, daily standup, TDD |
The four confusions to kill right now
- “Sprint” is not a methodology. A Sprint is a practice (level 4), a fixed time-box used inside Scrum. Saying “we use the sprint methodology” is like calling a single lap “the racing methodology.”
- “Agile” is not a framework, and not a methodology in the strict sense. Agile is a philosophy/mindset (level 2) defined by the Agile Manifesto. You don’t “do Agile”; you use a framework like Scrum or Kanban that embodies agile values.
- “Scrum” is not a methodology; it’s a framework. Its own authors are emphatic about this. Scrum deliberately leaves gaps for you to fill, which a full methodology wouldn’t.
- “Waterfall vs Agile” is not “old vs new tools.” It’s plan-driven vs adaptive, a difference in when you commit to decisions, not in technology.
The family tree
At the top, every approach answers one question: how much do we decide up front versus discover as we go?
flowchart TD SDP["Software development process"] SDP --> PD["Plan-driven / predictive<br/>decide everything up front"] SDP --> AD["Adaptive / empirical<br/>build, learn, adjust"] PD --> WF["Waterfall model<br/>stages once, in strict order"] PD --> VM["V-model<br/>+ a matching test phase per stage"] PD --> SP["Spiral model<br/>Waterfall in risk-driven loops"] AD --> II["Iterative & incremental<br/>the idea agile is built on"] AD --> AG["Agile, a mindset<br/>the Agile Manifesto"] AG --> SC["Scrum<br/>fixed sprints, defined roles/events"] AG --> KB["Kanban<br/>continuous flow, WIP limits, no sprints"] AG --> XP["Extreme Programming<br/>pairing, TDD, CI"] AG --> LN["Lean software development<br/>eliminate waste, optimize the whole"] AG --> SS["Scrumban · SAFe · LeSS<br/>hybrids and scaling frameworks"]
(The process mindmap shows this same tree visually.)
Plan-driven vs adaptive: the core trade-off
| Plan-driven (e.g. Waterfall) | Adaptive (e.g. Agile) | |
|---|---|---|
| Requirements | Fixed early, resist change | Expected to change, welcomed |
| Delivery | One big release at the end | Small, frequent, working releases |
| Best when | Requirements are stable and well-understood; change is costly (e.g. safety-critical, fixed-price contracts) | Requirements are uncertain or evolving; fast feedback matters |
| Biggest risk | Building the wrong thing perfectly, discovered too late | Scope drift; harder to fix a date/budget up front |
Neither is “better.” The industry has largely moved to adaptive approaches for product work, but plan-driven still rules where the cost of change is high. Many real teams are hybrid (“water-scrum-fall”: fixed contract and dates around an agile core).
How to read a job description or standup
When someone at a company says a process word, silently map it to the ladder:
- “We’re an agile shop” → level 2 mindset. Ask which framework. Usually Scrum or Kanban.
- “We do two-week sprints” → Scrum (level 3), using the Sprint practice (level 4).
- “We follow SAFe” → a scaled agile framework (level 3) for coordinating many teams.
- “It’s kind of waterfall” → plan-driven; expect big up-front specs and a late release.
- “We’re agile but…” → almost always a hybrid; find out which agile practices they actually keep.
See also
- Software development life cycle: the stages this process moves through
- Waterfall model · Agile software development · Agile Manifesto
- Scrum · Kanban · Extreme programming
References
- K. Beck et al., Manifesto for Agile Software Development (2001). https://agilemanifesto.org
- ISO/IEC/IEEE 12207:2017, Software life cycle processes. https://en.wikipedia.org/wiki/ISO/IEC_12207
- B. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer 21(5) (1988), pp. 61–72. https://www.cse.msu.edu/~cse435/Homework/HW3/boehm.pdf