4. Agile frameworks in automotive

Automotive development teams rarely adopt a single agile framework wholesale. Instead, they select and adapt practices from Scrum, Kanban, and SAFe to fit the constraints imposed by functional safety standards such as ISO 26262, ASPICE, and ISO/SAE 21434. Understanding what each framework offers — and where it collides with safety-standard expectations — is the prerequisite for designing a compliant yet responsive development process.

Scrum: Iterative Delivery with Safety-Relevant Artifacts

Scrum organizes work into fixed-length Sprints (typically two to four weeks) with defined roles (Product Owner, Scrum Master, Development Team) and ceremonies (Sprint Planning, Daily Standup, Sprint Review, Retrospective). Its core strength for automotive is the incremental delivery of potentially shippable product increments, which aligns well with the safety standard's expectation of progressive verification.

However, ISO 26262 requires traceability from safety goals through technical safety requirements to implementation and test evidence. Scrum's lightweight backlog often lacks the structure to capture this chain. A practical adaptation is to extend the Product Backlog Item (PBI) template with safety-specific fields. For example, a PBI for a lane-keeping assist function might include:

PBI-042: Implement LKA steering torque limiter
  Safety Goal:      SG-03 (prevent unintended steering torque > 3 Nm)
  ASIL:             D
  Technical Safety Requirement: TSR-03.2 (torque limiter shall clamp at 3 Nm ± 0.2 Nm)
  Verification Method:  Unit test + HIL fault injection
  Traceability:     SG-03 → TSR-03.2 → SWC-LKA-007 → TC-LKA-019
  Definition of Done: Code reviewed, MISRA clean, unit test coverage ≥ 95% MC/DC, HIL test passed

The Definition of Done (DoD) becomes the mechanism for embedding safety-standard evidence into each increment. Rather than treating safety documentation as a separate phase, the DoD ensures that traceability links, static analysis reports, and test coverage metrics are produced within the Sprint. This preserves Scrum's cadence while satisfying ASPICE SWE.4 through SWE.6 evidence requirements.

Kanban: Flow Control for Safety-Critical Work Items

Kanban excels where work arrives continuously and priorities shift — common in automotive for defect resolution, change requests, and safety anomaly handling. Its core practices are visualizing the workflow, limiting Work in Progress (WIP), and managing flow metrics such as cycle time and throughput.

For safety-critical items, Kanban's WIP limits must account for the fact that safety analysis and verification activities cannot be parallelized indefinitely. A typical board for a safety-relevant software team might use columns such as Backlog → Safety Analysis → Implementation → Static Analysis → Unit Test → Integration Test → Safety Review → Done, with WIP limits of 3, 2, 4, 3, 3, 2, 1 respectively. The Safety Review column with a WIP limit of 1 ensures that a qualified safety engineer reviews each item before it is considered complete — a bottleneck that is intentional and reflects the reality that safety sign-off is a serialized, expert-dependent activity.

Kanban's flow metrics also provide leading indicators for safety process health. If cycle time for ASIL D items consistently exceeds that of ASIL A items by a factor of three, that is expected. But if cycle time for ASIL D items is increasing Sprint over Sprint, it may indicate that safety analysis is being starved of resources or that requirements are arriving with insufficient safety concept definition.

SAFe: Scaling Across Domains and Suppliers

The Scaled Agile Framework (SAFe) addresses coordination across multiple teams, which is unavoidable in automotive where a single ECU function may involve software, hardware, system, and supplier teams. SAFe's Agile Release Train (ART) and Program Increment (PI) planning provide a cadence for cross-team dependency management and milestone synchronization.

SAFe's compatibility with safety standards hinges on how the PI Planning event and the Program Board are used. Safety dependencies — such as the availability of a safety mechanism from a supplier or the completion of an FMEDA — must appear as explicit dependencies on the Program Board. Without this, safety-critical path items risk being treated as ordinary features and slipping silently.

A practical technique is to tag every feature and enabler on the Program Board with its ASIL level and to require that any dependency involving an ASIL C or D item has a named safety owner on both sides. During PI Planning, the safety manager reviews the board specifically for ASIL C/D dependency chains and flags any that lack a verified mitigation plan.

Compatibility Matrix: Framework Practices vs. Safety Standard Expectations

The table below summarizes where each framework's native practices satisfy, partially satisfy, or conflict with common safety-standard expectations. "Partial" means the practice provides a foundation but requires explicit extension.

The conflicts are instructive. Scrum's self-verifying team model directly contradicts the ISO 26262 requirement for independent verification for ASIL C and D. The resolution is not to abandon Scrum but to introduce a separate verification team or a qualified reviewer who is not the author — a role that can be accommodated within the Scrum framework as a specialized team member or as a shared service.

Similarly, tool qualification (e.g., qualifying a compiler or static analysis tool for ASIL D use) is not a concern any agile framework addresses natively. It must be handled as a separate workstream, often as an enabler in SAFe or as a dedicated Kanban lane, with its own evidence trail.

Choosing and Combining Frameworks

In practice, automotive organizations often combine frameworks. A common pattern is SAFe at the program level for PI planning and cross-team coordination, Scrum at the team level for feature development, and Kanban for safety anomaly handling and continuous improvement. The key is to ensure that safety-standard evidence is not lost at the seams between frameworks.

One effective integration mechanism is a unified Definition of Done that applies across all frameworks. Whether a work item moves through a Scrum Sprint or a Kanban flow, it must satisfy the same safety evidence criteria before it is considered complete. This creates a single quality gate that is framework-agnostic and directly traceable to safety-standard requirements.

The diagram above illustrates the integration pattern: each framework contributes its native strengths, but all work items pass through a unified Definition of Done that serves as the safety evidence gate. This gate is not a framework-specific ceremony — it is a quality criterion that applies regardless of whether the item is delivered through a Sprint, a Kanban flow, or a PI increment.

The choice between Scrum, Kanban, and SAFe is less important than the consistency of the safety evidence gate. A team using Kanban with a rigorous DoD will produce more compliant artifacts than a team using SAFe with a weak DoD. The framework provides the cadence and coordination mechanism; the DoD provides the safety guarantee. Both are necessary, but only the DoD is non-negotiable when safety standards are in scope.