FrankSazamaIch weiß noch genau, wann ich den Satz zum ersten Mal gesagt habe:
👉 „Automotive SPICE ist nichts weiter als Erwartung.“
Ein provokanter Einstieg – ich weiß. Aber genau darum geht’s. ASPICE ist keine Bürokratiehölle, kein „Muss wegen der OEMs“, kein agiler Killer. Es ist – im Kern – eine Bündelung von Erwartungen: an gute Prozesse, an verlässliche Ergebnisse, an nachvollziehbare Qualität.
ASPICE – das Unsichtbare sichtbar machen
In meinen Trainings und Assessments stelle ich oft fest: Viele Teams empfinden ASPICE als etwas „Fremdes“.
Etwas, das „von außen“ kommt, nicht zum agilen Alltag passt und oft erst „am Ende“ wichtig wird.
Doch ASPICE wirkt anders:
💡 Es ist immer da – in jedem Commit, jeder Anforderung, jeder Entscheidung.
📌 Es beschreibt Prozesse – ja. Aber nicht „wie du es tun musst“, sondern was am Ende sichtbar sein soll: Zweck + Ergebnis (Outcomes).
Diese zwei Elemente sind verpflichtend. Alles andere – Work Products, Base Practices – sind Hinweise, keine Dogmen.
ASPICE + Agil = kein Widerspruch
In einem unserer Projekte haben wir das Zusammenspiel genau untersucht.
Frage: Können wir mit rein agilen Methoden die Erwartungen von ASPICE erfüllen – oder sogar übertreffen?
Unsere Antwort:
✅ Ja – wenn wir Verantwortung klar verankern, agile Events gezielt nutzen und klassische Engineering-Disziplinen integrieren.
Ein agiles Team mit Scrum-Rollen (PO, SM, Devs) kann vieles abdecken:
- Product Owner: Versteht das „Was“ – die Kundenperspektive, die Vision.
- Scrum Master: Entwickelt das „Mit wem und wie“ – befähigt das Team.
- Developer: Tragen das „Wie“ – sie verantworten Architektur, Design, Tests, Umsetzung.
Und genau hier erfüllt sich ein zentraler Gedanke:
👉 Die Verantwortung für ASPICE liegt dort, wo auch die Umsetzung passiert.
Beispiel: Projektmanagement im Lichte von ASPICE
Ein Beispiel macht es konkret.
Der Prozessbereich „Projektmanagement“ in ASPICE fordert unter anderem:
- Geklärter Scope
- Machbarkeitsanalyse
- Aufwandsabschätzung
- Klare Schnittstellen
- Pläne und Fortschrittsüberwachung
- Korrekturmaßnahmen bei Abweichungen
Klingt nach klassischem PM? Ja.
Aber im agilen Setting finden wir diese Elemente wieder:
- Vision + Backlog Refinement → Scope
- Planning Poker, Epics, Story Points → Aufwandsabschätzung
- Sprint Review + Retros → Fortschritt + Korrektur
- Scrum Events + Artefakte → Pläne, Koordination, Anpassung
Was fehlt?
➡️ Oft die Mittelfristplanung (3–6 Monate)
➡️ Synchronisation mit anderen Projekten
➡️ Verbindliche Schnittstellendefinition und Projektführung über ein einzelnes Team hinaus
Hier helfen klassische Tools & Denkmuster.
Nicht als Widerspruch – sondern als sinnvolle Ergänzung.
Engineering-Prozesse: Die wahre Herausforderung
Systemanforderungen, Architektur, Testdesign, Traceability – hier wird’s komplex.
Nicht weil ASPICE kompliziert ist. Sondern weil Konsistenz und Nachvollziehbarkeit über viele Ebenen hinweg erreicht werden müssen.
Wir stellten fest:
💬 „Nicht das Agile steht im Weg – sondern das Fehlen von Struktur im Engineering.“
Ein gut geführtes Backlog, das Anforderungen auf System- und Softwaresicht herunterbricht.
Ein Testansatz, der Verifikation und Validierung als festen Bestandteil jeder Iteration verankert.
Ein Reflektionsraum, in dem wir Qualität sichtbar und steuerbar machen.
Dann wird ASPICE nicht mehr zur Hürde, sondern zum Navigationssystem für gutes Engineering.
Was wirklich zählt: Das Ergebnis
Am Ende ist es ganz einfach – und genau darin liegt die Stärke von ASPICE:
➡️ Was ist das Ziel dieses Prozesses?
➡️ Welche Ergebnisse müssen sichtbar sein?
Und hier zeigt sich die Brücke zur Agilität:
Denn auch im agilen Arbeiten geht es nicht um Methoden – sondern um funktionierende, wertvolle Ergebnisse.
Das ist die verbindende Perspektive.
Das ist die Chance für echte Transformation.