Before agile, there was the V-Model — still taught, still used across industry and regulated projects. Every design phase has a mirrored test phase, planned from the very start.
The V-Model is an evolution of the waterfall model: every design phase (going down) is paired with a symmetric test phase (going up) defined at the same time, not as an afterthought. Requirements define acceptance tests, architecture defines integration tests, code defines unit tests — hence the diagram's V shape.
Unlike agile, every phase must be validated before moving to the next: scope is locked in from the start, which makes the V-Model rigid against change but highly predictable in terms of timeline and budget.
Aerospace, medical devices, rail: full traceability from requirement to test is often a legal requirement.
When scope won't change along the way, the V-Model's rigidity becomes an asset, not a flaw.
Physical deliverables that are hard to change once built demand upfront validated design.
Where an error found late is extremely costly or dangerous to fix.
| Criteria | V-Model | Agile |
|---|---|---|
| Handling change | Hard, costly | ✅ Native |
| Timeline/budget predictability | ✅ High | Medium |
| User feedback | Only at the end | ✅ Every sprint |
| Requirement ↔ test traceability | ✅ Native | Must be built |
Many large organizations today use a hybrid approach: a V-shaped frame at the program level (milestones, compliance), agile execution inside each phase. See the PMI and APM frameworks on choosing a project life cycle.
Milestone-based Gantt, sprints, and compliance tracking — adapt the method to each project. Free.