Erfolg messen

SAFe betont Flow-Metriken gegenüber Aktivitätsmetriken. Flow-Metriken messen, wie Wert durch das System fließt – und das ist es, was Kunden und Unternehmen tatsächlich interessiert.

Die vier Flow-Metriken:

1. Flow Distribution — Welcher Prozentsatz der Arbeit fällt in welche Kategorie: Features, Enabler, Defekte, Risiken? Ein gesunder ART verwendet die meiste Kapazität für Features und Enabler. Wenn Defekt-Arbeit dominiert, müssen Qualitätspraktiken verbessert werden. Wenn Risiko-Arbeit dominiert, gibt es möglicherweise systemische Stabilitätsprobleme.

2. Flow Velocity — Wie viele Elemente (Features, Stories) werden pro Zeiteinheit abgeschlossen? Dies ist die Durchsatzmaßnahme. Steigende Flow Velocity bedeutet, dass der ART schneller mehr Wert liefert. Verfolgen Sie diesen Trend über PIs hinweg.

3. Flow Time — Wie lange dauert es vom Eintritt der Arbeit ins System bis zur Lieferung? Dies ist die End-to-End-Durchlaufzeit. Reduzierte Flow Time bedeutet, dass Kunden schneller Wert erhalten. Lange Flow Times deuten auf Warteschlangen, Engpässe oder übermäßige WIP hin.

4. Flow Load — Wie viel Arbeit befindet sich zu einem bestimmten Zeitpunkt im System (WIP)? Hohe Flow Load erzeugt Warteschlangen, erhöht die Flow Time und verringert die Vorhersagbarkeit. Die Lösung ist fast immer: Beenden Sie, was Sie begonnen haben, bevor Sie etwas Neues beginnen.

Flow Efficiency — Eine abgeleitete Metrik: aktive Zeit ÷ gesamte Flow Time × 100 %. Die meisten Organisationen stellen fest, dass ihre Flow Efficiency 15–25 % beträgt – das bedeutet, dass Arbeit 75–85 % ihrer Zeit in Warteschlangen verbringt. Hier liegen die größten Verbesserungsmöglichkeiten.

Messen Sie diese nicht isoliert. Sie bilden ein System: Die Reduzierung der Flow Load (WIP) verbessert typischerweise die Flow Time, was die Flow Velocity verbessert und die Flow Distribution in Richtung Features verschiebt (weil sich weniger Defekte ansammeln).

SAFe definiert sieben Kernkompetenzen, die ein Lean-Agile-Unternehmen charakterisieren. Die regelmäßige Beurteilung dieser Kompetenzen hilft, Transformationslücken zu identifizieren:

1. Team and Technical Agility — Sind Teams wirklich funktionsübergreifend, selbstorganisierend und praktizieren sie eingebaute Qualität? Integrieren und liefern sie kontinuierlich?

2. Agile Product Delivery — Ist die Organisation kundenorientiert? Baut sie Produkte iterativ mit schnellem Feedback von Nutzern? Ermöglicht DevOps kontinuierliche Lieferung?

3. Enterprise Solution Delivery — Kann die Organisation große, komplexe Lösungen über mehrere ARTs hinweg bauen und weiterentwickeln? Sind Lean-Systems-Engineering-Praktiken vorhanden?

4. Lean Portfolio Management — Werden Portfolios nach Value Stream finanziert, durch Leitplanken gesteuert und nach wirtschaftlichem Wert priorisiert?

5. Organizational Agility — Kann die Organisation schnell auf Marktveränderungen reagieren? Sind Teams um Wert herum organisiert? Ist die Strategieumsetzung effektiv?

6. Continuous Learning Culture — Ist die Organisation der unermüdlichen Verbesserung verpflichtet? Haben Menschen Zeit und Ermutigung zum Lernen? Werden Innovationen gefördert und Fehler als Lerngelegenheiten behandelt?

7. Lean-Agile Leadership — Modellieren Führungskräfte Lean-Agile-Verhalten? Führen sie durch Vorbild, schaffen sie Erfolgsbedingungen und treiben sie organisatorischen Wandel voran?

Wie man die Beurteilung nutzt: Bewerten Sie jede Kompetenz von 1–5 mit evidenzbasierter Begründung. Identifizieren Sie die 2–3 am niedrigsten bewerteten Kompetenzen und konzentrieren Sie Verbesserungsbemühungen darauf. Beurteilen Sie alle 2–3 PIs neu. Die Beurteilung ist keine zu optimierende Punktzahl – sie ist ein Diagnosewerkzeug zur Steuerung von Investitionen.

SAFe-Transformationen scheitern auf vorhersehbare Weise. Die Anti-Patterns zu kennen, hilft Ihnen, sie zu vermeiden:

"SAFe-fall" — Implementierung von SAFe-Mechaniken bei Beibehaltung der Wasserfall-Denkweise. PI Planning wird zu einer detaillierten Vorab-Planungsübung. Teams wird gesagt, was sie bauen sollen. Retrospektiven führen zu keinen Änderungen. Dies ist der häufigste Fehlermodus.

"Fake Agile Release Trains" — Teams werden einem ART auf dem Papier zugewiesen, arbeiten aber weiterhin unabhängig. Es gibt keine echte Integration, keine aussagekräftige System Demo und PI Planning ist nur Statusberichterstattung.

"The Certification Factory" — Alle werden zertifiziert, aber niemand ändert sein Verhalten. Zertifizierungen sind notwendig, aber nicht ausreichend. Training ohne Coaching und Praxis führt nicht zur Transformation.

"Agile in name only" — Führungskräfte verordnen SAFe, ändern aber ihr eigenes Verhalten nicht. Sie verlangen immer noch detaillierte Vorab-Schätzungen, überstimmen Teamentscheidungen und messen Auslastung statt Ergebnisse.

"Over-engineering the framework" — Implementierung von Full SAFe, wenn Essential ausreichen würde. Hinzufügen benutzerdefinierter Rollen, Events und Artefakte zusätzlich zu SAFe. Das Ergebnis ist ein übermäßig komplexer Prozess, gegen den sich Teams wehren.

"PI Planning theater" — PI Planning findet statt, aber Pläne werden ignoriert. Teams tun, was das Management ihnen nach dem Event sagt. Dies zerstört Vertrauen und macht zukünftige Planungsevents bedeutungslos.

"Ignoring technical practices" — Übernahme der organisatorischen Praktiken von SAFe bei gleichzeitiger Ignorierung eingebauter Qualität (kein TDD, kein CI, keine automatisierten Tests). Man kann nicht skalieren, was auf Teamebene nicht funktioniert.

Das Gegenmittel: Kontinuierliche, ehrliche Retrospektion. Wenn das I&A-Event konsistent dieselben Probleme identifiziert, verbessert sich der ART nicht – er wiederholt sich. Eskalieren Sie systemische Hindernisse an die Führungsebene. Wenn die Führungsebene nicht auf Hindernisse reagiert, ist das das zu adressierende Hindernis.