Before writing this, I naively thought the biggest difference between ASPICE and Agile was documentation vs. itemization. The biggest fusion challenge: how to convert automotive engineers' documents into itemized structures for atomic task assignment and tracking. But after in-depth discussions with over 100 customers, I realized this is only one challenge—there are deeper cognitive-level conflicts.

ASPICE Version Management: Intention vs. Reality

In ASPICE, version management's core goal is ensuring development stability and traceability. By strictly controlling versions of requirements, design, and code, ASPICE establishes clear baselines so problems can be traced to root causes quickly. This is theoretically sound.

So far, the process runs perfectly. Most teams execute it smoothly. Next comes the hard mode.

After setting a baseline for the coming period, the team enters development—say, one month until release. If the baseline doesn't change at all, everything is perfect: just execute the requirements, architecture, and test cases from the baseline.

But in real engineering, this "calm sea" development mode never exists. Within that month, many changes happen: incomplete design docs, new customer requirements, modifications to existing requirements, competitor features that product managers want to chase...

Teams have two choices: execute the change immediately on the current baseline, or wait until this baseline ends and add changes to the next one.

Version Management Hell

If the team chooses immediate change execution, there are 3 approaches:

Option 1: Copy entire baseline v1 to v1.1, modify files directly, invite CCB review

Pros: easy operation—just copy the whole thing.

Cons: each change copies the entire baseline—version proliferation slows the system; hard to diff any two baseline versions; identifying affected documents requires manual effort—high risk of missing something.

Option 2: Take only the changed document v1.0, modify to v1.1, review, and attach as supplement to baseline v1

Pros: only modified documents change—no version explosion.

Cons: hard to ensure implementers notice the supplement alongside the baseline—causing implementation mismatch; same challenge of identifying affected documents.

Option 3: Modify changed document v1.0 to v1.1, and within baseline v1, users see v1.1 first, v1.0 is hidden

Pros: implements Option 2's advantages while fixing the visibility issue—implementers see the latest content first.

Cons: hard to diff baseline versions; a requirement now has multiple versions (v1.0 at baseline + v1.1 after change), making status tracking and ownership management difficult.

Either way, change management is challenging. Plus another issue: documents that pass review and get archived into baselines continue evolving afterward. Each document now has multiple entities: the living, changing version, plus frozen copies in various baselines. The same requirement has different owners and statuses in different baselines. Which one defines the "true" owner and status?

This is why teams that strictly follow ASPICE either resist changes subjectively or struggle with them objectively. So they don't change—changes wait for the next baseline. And that baseline cycle? 3 months or more. Meaning: for 3 months, minimize response to change!

German OEMs and suppliers did exactly this 10 years ago. This analysis explains why "classic" ASPICE theory and toolchains actually fail to support change well.

What Is a "Fake Baseline"?

I'm sure many readers are now terrified by the baseline and change process described above. So someone thought of a clever workaround: if change is so painful after pulling a baseline, why not pull the baseline after development is done?

Say release is May 30. From March 1 onward, requirements, architecture, detailed design, test cases, and code keep changing. On May 28, the integration engineer compiles a build, testing finds no major issues, and only then do you package requirements, architecture, design, test cases, and all other documents into a baseline.

This so-called "baseline" should be renamed a "staged snapshot." It's not for teams to develop against—it's for viewing staged implementation status. It has no "Baseline" meaning and no change execution on it.

I call this a "fake baseline." It exists only to appease customers and auditors—it has zero role in guiding development.