Sprinting through the V

Two calendars run in almost every automotive and EV programme. The first is drawn as a V, anchored to gates, and recognised by your customer, your quality department and your assessor. The second is two weeks long, has a backlog and a board, and is the one your engineers actually live in.

Most organisations run both. Very few run both deliberately. What usually happens instead is that sprints become a reporting layer painted over an essentially sequential process — daily stand-ups about work that can't finish for another eleven weeks, sprint reviews with nothing to demonstrate, and a documentation scramble before every gate. You get the ceremony overhead of agile and the change-resistance of the V, and the benefits of neither.

This 43-page field guide argues that the conflict is largely imaginary, and that it comes from a category error:

The V-model is a structure of evidence. The sprint is a structure of scheduling. They are orthogonal, and the model is what joins them.

Everything else follows from taking that seriously.

Why this book exists

The agile-in-automotive literature splits into two unhelpful halves. One half sells a framework -adopt SAFe, adopt Agile SPICE - without telling you how to decompose a system architecture into sprint-sized work, or what a Definition of Done looks like when an assessor will read it. The other half is honest about the constraints and concludes that safety-critical hardware development simply can't iterate.

This book does neither. It surveys six workflows already in use, states plainly what each one gets right and where it stops, and then specifies the missing parts: how to slice the V vertically into backlog items, how to run a design freeze as a decision rather than a deadline, and how to generate ASPICE and ISO 26262 evidence as a by-product of sprints rather than in a four-week archaeology exercise before the audit.

It is also honest about limits. Hardware fabrication doesn't compress. Homologation is event-based. Supplier contracts freeze scope. The workflow addresses these directly rather than pretending them away.

Written by a practising model-based systems architect working on production automotive programmes, not a consultant selling a transformation.

Who it's for

• Systems engineers and architects under Automotive SPICE and ISO 26262 who have been told to "go agile"
• Team leads and Scrum Masters who inherited a V-model programme and a sprint board and have to reconcile them
• Functional safety and quality managers who need to know what evidence looks like when it's produced incrementally
• Engineering managers weighing up SAFe, Agile SPICE, or something lighter

Who it isn't for

It assumes you already know what SysML, ASPICE, ISO 26262 and a HIL rig are. It is not a Scrum tutorial, not an ASPICE interpretation guide, and not an argument that agile is better than the V. If you want an introduction to model-based systems engineering, start elsewhere.

Who it isn't for

It assumes you already know what SysML, ASPICE, ISO 26262 and a HIL rig are. It is not a Scrum tutorial, not an ASPICE interpretation guide, and not an argument that agile is better than the V. If you want an introduction to model-based systems engineering, start elsewhere.