V-Model vs Agile in Automotive: Six Hybrid Workflows Compared
Six ways automotive teams combine the V-model with agile, and what each one actually covers.
Search for "V-model vs agile" and the same comparison table appears everywhere: sequential against iterative, documentation against working software, predictability against flexibility. For a web application that framing is useful. For an automotive programme under Automotive SPICE and ISO 26262 it misses the point, because the programme does not get to choose. The customer, the assessor and the safety case need the V's evidence structure, and the engineers need short feedback loops, so every real team ends up running some combination of the two.
Welcome to MBSE Explained. Several such combinations already exist, at different levels of formality, and your organisation is probably running one of them already, possibly by accident. This post compares six, says plainly what each gets right and where it stops, and ends with a way to choose. It draws on Part II of my field guide, Sprinting through the V.
Both Sides, Fairly
The V-model's strengths are real. Bidirectional traceability links every requirement to its realisation and verification. Each specification level has a corresponding test level. Level discipline keeps the record navigable. Automotive also has genuine sequential forces behind it, from hardware lead times measured in weeks per spin, to supplier contracts signed against frozen baselines, to certification events that are expensive to repeat.
Agile's strengths are just as real, and they come down to feedback latency. A strictly sequential V can leave six to twelve months between an architectural decision and the integration result that tells you whether it was right. Incremental delivery, planning from observation and short feedback loops all exist to shrink that interval while decisions are still cheap to change.
The two operate on different layers. The V describes what evidence must exist and how it connects, and the sprint describes when work is planned and inspected. Once that is clear, "versus" stops being the question, and the practical question becomes which combination to run. The method itself is covered in How to Run the V-Model and Agile Sprints at the Same Time; this post is about the landscape.
1. Water-Scrum-Fall, the Accidental Default
Requirements and architecture happen up front, implementation happens in sprints, and integration and verification happen at the end, so Scrum occupies the middle third of the lifecycle. Nobody chooses this. It is what an organisation gets when it introduces Scrum to its development teams and changes nothing about how requirements arrive or how releases are governed.
It works when requirements are stable and the software is a well-understood re-application of an existing platform, such as a facelift reusing most of a proven inverter software stack. Everywhere else it fails in two ways. Architectural feedback still arrives at integration, and verification is still a phase, which makes it the phase that absorbs schedule pressure. If your sprint reviews have no executable content and your requirements were written by another group before sprint one, this is what you are running.
2. The Agile-V Hybrid
This is a family of practitioner models that keep the V as the overall lifecycle and traceability structure while executing each phase iteratively. Sprints become the execution mechanism and gates remain the commitment mechanism. Its appeal is low adoption cost. There is no reorganisation, no new set of role names, and the artefacts are the ones assessors and customers already recognise.
Its weakness is that it is under-specified. "Run each phase iteratively" leaves the hard questions open. How do you slice a system architecture into sprint-sized items, what does Done mean for an architecture increment, and what happens when a sprint invalidates an earlier baseline? Left unanswered, teams drift back to Water-Scrum-Fall. It is the right starting frame, and insufficient on its own.
3. SAFe
The Scaled Agile Framework organises multiple teams into an Agile Release Train of roughly 50 to 125 people, planning together in Program Increments that typically run eight to twelve weeks, with a large cross-team planning event at the start of each. Automotive adopted it because it solves something team-level Scrum never touches, which is dependency management at the scale of a vehicle programme. The increment boundary maps naturally onto sample builds and milestone deliveries.
The cost is weight. SAFe brings a substantial vocabulary and role structure, so adopting it is an organisational change programme in its own right, and it says little about engineering itself: how to decompose an architecture, maintain traceability, or produce safety evidence. Teams sometimes adopt SAFe and find their ASPICE findings unchanged, because SAFe never addressed them. It is excellent at the programme layer for large programmes. With three teams it is overkill, and with fifteen you will end up building something like it anyway.
4. Agile SPICE
Agile SPICE is published by intacs, the body that certifies Automotive SPICE assessors, as a process reference and assessment model designed to work alongside ASPICE. It adds three agile processes, AGL.1 Agile Work Management, AGL.2 Partner Collaboration Management and AGL.3 Agile Quality Assurance, and maps everyday agile practices such as sprints, backlogs and retrospectives onto ASPICE base practices and work products. It is aligned with Automotive SPICE 4.0.
Its biggest contribution is political. It dismantles the belief, held sincerely at many Tier 1s, that agile and ASPICE are incompatible, and it comes from the same community that trains assessors, which gives it credibility in exactly the room where credibility matters. AGL.2 also covers something no general agile framework does, the OEM to Tier 1 to Tier 2 supply chain. Its limit is that it is an assessment model. It describes what good looks like when assessed and leaves you to work out how to run a Tuesday. Adopt it as the compliance layer, whatever execution workflow sits underneath. How to produce the evidence it expects inside the sprint is covered in agile ASPICE and ISO 26262.
5. Harmony aMBSE
Bruce Powel Douglass's agile model-based systems engineering process is the most engineering-specific of the six. Its defining idea is three nested cadences. A nanocycle of thirty minutes to a day verifies every model change immediately, ideally by executing it. A microcycle runs one to four weeks, and a macrocycle spans the project. It rejects big design up front in favour of developing and verifying the design work needed now.
It is the only one of the six that operates at the granularity engineers actually work at, and the only one that treats executable models as the verification mechanism. If your SysML model can be simulated, verification stops being a downstream phase. The catch is that it assumes mature modelling and tooling that supports execution, which is a large assumption in an organisation still arguing about whether the architecture lives in Cameo or in PowerPoint. It is also quiet on the commercial side of automotive, meaning supplier interfaces, sample milestones and customer change management.
6. The W-Model
The W-model is less a workflow than a change to the V's shape. It runs test activities in parallel with each development activity, so test planning and test case design happen alongside the specification they verify. Writing system qualification test cases at the same time as the system requirements exposes an unverifiable requirement the moment someone tries to test it.
It is the cheapest meaningful improvement available to a sequential organisation, because it changes when an activity happens without changing who does it. It does nothing for planning, prioritisation or change management, so it shortens one feedback loop and leaves the others alone. Every hybrid should absorb it, ideally as a Definition of Done rule.
Side by Side
| Water-Scrum-Fall | Agile-V hybrid | SAFe | Agile SPICE | Harmony aMBSE | W-model | |
|---|---|---|---|---|---|---|
| Primary layer | Team | Programme + team | Portfolio + programme | Assessment | Team + engineering | Verification |
| Multi-team scaling | No | Weakly | Yes, its main purpose | Partly (AGL.2) | No | No |
| Engineering method | No | Partly | No | No | Yes | Partly |
| ASPICE evidence | No | No | No | Yes, its main purpose | Partly | No |
| Needs MBSE maturity | No | No | No | No | Yes | No |
| Adoption cost | Zero | Low | Very high | Low to medium | Medium | Very low |
| Typical failure | Ceremony without feedback | Drift back to sequential | Overhead exceeds benefit | Compliance without agility | Stalls on tooling gaps | Solves too little |
Reading down the columns, a pattern appears. No single framework covers the whole problem, and the gaps are complementary. SAFe owns multi-team coordination, Harmony owns the engineering method, Agile SPICE owns the evidence layer, the W-model owns verification timing, and the Agile-V hybrid supplies the overall frame.
Which One Should You Pick?
If you would rather pick one than assemble your own, two variables decide most of it: how many teams you have, and how mature your modelling is.
- One to three teams with strong modelling: Harmony aMBSE plus the W-model verification rule, adding Agile SPICE once an assessment is scheduled.
- One to three teams with weak modelling: the Agile-V hybrid plus the W-model rule, investing the difference in building the model backbone. Skip SAFe entirely.
- Four to ten teams: the Agile-V hybrid with a programme-increment layer for cross-team planning. SAFe's PI planning event is worth borrowing on its own, without the rest of the framework.
- More than ten teams across sites: SAFe, with an explicit engineering method underneath, because SAFe will not supply one.
- An assessment within twelve months: Agile SPICE first and the workflow second, because the assessment will not wait for your transformation.
The Variable That Matters More Than the Framework
One factor predicts success better than any choice in that table, and it is whether the organisation is willing to change its gate criteria.
If gates still demand complete artefacts across full scope, every one of these workflows degrades into Water-Scrum-Fall within two or three programmes, because the documentation push before each gate consumes whatever slack the sprints created. If gates are redefined around committed scope, with the remainder explicitly deferred and tracked, almost any of them produces an improvement. That change sits with programme management and quality. It is why so many agile transformations in automotive stall even when the engineering teams do their part.
Building a Composite Workflow
Because the gaps are complementary, the workflow in Sprinting through the V is a composite. It takes the three-cadence structure from Harmony, the milestone-facing programme increment and its planning event from SAFe without the rest of SAFe, the evidence discipline from Agile SPICE, and the parallel-verification rule from the W-model. Then it adds the two parts none of the six specify well, namely how to slice V-model content into backlog items and how to handle the mismatch between hardware and software cadence.
The overview of that method is in How to Run the V-Model and Agile Sprints at the Same Time. The full version, with a twelve-week worked example on an EV traction inverter, is in the book.
That's the mission here at MBSE Explained, simplifying systems for smarter EVs. Which of the six is your team running today, and was it a choice?