Capabilities & Enablers

Eine Capability ist ein übergeordnetes Verhalten der Lösung, das typischerweise mehrere ARTs umfasst. Sie ist das Large-Solution-Äquivalent eines Features – nur größer.

Feature vs. Capability:

• Ein Feature liefert Wert innerhalb eines einzelnen ART. Ein Team (oder einige wenige Teams im selben ART) kann es umsetzen.
• Eine Capability liefert Wert über mehrere ARTs hinweg. Sie erfordert koordinierte Arbeit über Trains hinweg.

Beispiel für eine autonome Fahrzeugplattform:

• Capability: „Fahrzeug kann ein Autobahnkreuz sicher durchfahren"
  • ART 1 Feature (Wahrnehmung): Fahrbahnmarkierungen und Einfädelbereiche bei Autobahngeschwindigkeit erkennen
  • ART 2 Feature (Planung): Sichere Trajektorie durch das Kreuz generieren
  • ART 3 Feature (Steuerung): Spurwechsel mit angemessener Beschleunigung ausführen
  • ART 4 Feature (Infrastruktur): Kartendaten für Kreuztypen

Capabilities leben im Solution Backlog, verwaltet vom Solution Management. Während des Pre-PI Planning werden Capabilities in Features heruntergebrochen, die in das Program Backlog jedes ART einfließen.

Capabilities dimensionieren: Capabilities sollten in ein einzelnes PI passen. Wenn eine Capability mehrere PIs umfasst, ist sie eigentlich ein Epic und sollte auf Portfolio-Ebene mit einem Lean Business Case verwaltet werden.

Genau wie Teams Enabler Stories und ARTs Enabler Features haben, haben Solution Trains Solution-Level Enabler.

Diese adressieren ART-übergreifende technische Anforderungen:

Architecture Enabler: Gemeinsame Plattformen, APIs und Protokolle, die mehrere ARTs benötigen. Beispiel: ein Message Bus, auf dem alle ARTs publizieren und von dem sie abonnieren.

Infrastructure Enabler: Integrationsumgebungen, Testinfrastruktur, Deployment-Pipelines, die ARTs umfassen. Beispiel: eine systemweite Integrationstestumgebung, die alle ART-Outputs kombiniert.

Exploration Enabler: ART-übergreifende Proof-of-Concepts oder Trade Studies. Beispiel: Evaluierung zweier konkurrierender Ansätze für Inter-Service-Kommunikation.

Compliance Enabler: Regulatorische Anforderungen, die die gesamte Lösung betreffen. Beispiel: DSGVO-Compliance, die beeinflusst, wie alle ARTs personenbezogene Daten handhaben.

Solution Enabler verwalten:

Solution Enabler konkurrieren genau wie Capabilities um Kapazität. Solution Management priorisiert das Solution Backlog und balanciert Capability-Lieferung mit Enabler-Investition.

Eine gesunde Allokation hängt von der Lösungsreife ab:

• Neue Lösung: 40–50 % Enabler (Fundament aufbauen)
• Reifende Lösung: 20–30 % Enabler (Runway aufrechterhalten)
• Stabile Lösung: 10–20 % Enabler (inkrementelle Verbesserungen)

Das Solution Kanban verwaltet den Fluss von Capabilities und Enablern durch das System. Es ist ähnlich wie Portfolio Kanban, operiert aber auf Solution-Ebene.

Typische Spalten:

1. Funnel – Neue Capability-Ideen erfasst, aber noch nicht analysiert
2. Analyzing – Solution Management und Solution Architect bewerten Machbarkeit, definieren Akzeptanzkriterien und schätzen Größe
3. Backlog – Analysiert und bereit für PI Planning, priorisiert nach WSJF (Weighted Shortest Job First)
4. Implementing – Aktiv im aktuellen PI, in Features über ARTs hinweg zerlegt
5. Validating – Über ARTs hinweg integriert und auf Solution-Ebene validiert
6. Done – Deployed und liefert Wert

WIP-Limits gelten auf jeder Stufe. Das Solution Kanban hat typischerweise niedrigere WIP-Limits als man erwarten würde – ein Solution Train könnte nur 3–5 Capabilities gleichzeitig in Umsetzung haben, weil jede Capability Koordination über mehrere ARTs hinweg erfordert.

WSJF-Priorisierung: Capabilities werden mit Weighted Shortest Job First priorisiert, was Cost of Delay (Nutzen für Anwender/Business + Zeitkritikalität + Risikoreduktion) gegen Jobgröße abwägt. Dies stellt sicher, dass die wertvollste Arbeit mit der kürzesten Dauer zuerst erledigt wird.