SAFe: Wie prüfe ich meine agilen Abläufe auf ihre Effektivität?

Agilität. Dieses Wort hat sich als Buzz-Word in den grossen Organisationen oder im Softwareentwicklungsumfeld fest etabliert. Wir wollen messen, was Agilität wirklich bewirkt.

WRAP UP

  • Agile Frameworks wie SAFe sind weit verbreitet
  • Die Messung der Wirksamkeit dieser agilen Arbeitsmethoden ist jedoch oftmals lückenhaft. Der Erfolg des Vorgehens kann nur schwer nachgewiesen werden
  • Bist du dir unsicher, ob bspw. SAFe in deinem Unternehmen wirklich die erwartete Wirkung erzielt? Dann gibt es hier ein paar Tipps, mit welchen Metriken du das herausfinden kannst.

Trotzdem stellt sich jede Person unter der Definition «Agilität» etwas Eigenes vor: effektives Management der Arbeitsprozesse, Steigerung der Effizienz, strukturierte Organisation der Aufgabenstellungen, Selbstorganisation und Selbstverantwortung, aber auch Chaos, das Fehlen von Regeln oder Hierarchien. Beim Einsatz agiler Praktiken wie SAFe oder Scrum erhoffen sich die Unternehmen jedoch einen positiven Einfluss der neuen Arbeitsvorgänge auf das eigene Wachstum und Rendite erzielen zu können.

Solange das Unternehmen ihren Erfolg sowie die Effizienz und die Effektivität der Arbeitsprozesse nicht misst, können jeglichen Aussagen über die erfolgreiche Einführung der agilen Methoden als reine Interpretation betrachtet werden. Und in der Tat beschäftigen sich nur die wenigsten Organisationen mit dem vollumfänglichen Messen des Unternehmenserfolges – die Messungen beschränken sich dabei in der Regel auf den finanziellen Erfolg der Organisation.

Der finanzielle Erfolg ist wiederum nur ein Resultat der in einem Unternehmen vorher stattgefundenen Vorgängen. Sollten diese Vorgänge rechtzeitig gemessen und angepasst werden, besteht die Möglichkeit dabei auf das Endresultat positiv einwirken zu können.

Aus diesem Grund würden wir dir gerne in diesem Artikel einige wertvolle agile Metriken verraten, welche du in deinem Unternehmen einsetzten kannst, um die gesetzten strategischen und operativen Ziele strukturiert sowie kontrolliert erreichen zu können.

MESSUNG DER ARBEITSFLUSSEFFIZIENZ IM SCRUM-TEAM

Zu einer der wichtigsten Metriken gehört das Messen der Arbeitsflusseffizienz. Agilen Scrum-Teams, welche in Rahmen einer SAFe-Organisation tätig sind und welche mit einem Kanban-Board arbeiten, ist die Problematik bereits bekannt: viele neue Tickets wurden erfasst, ein Anteil der Aufgaben wurde im «Funnel» platziert, eine Unmenge von Aufgabenstellungen und Tasks sind in der Bearbeitung, eine viel zu geringe Anzahl von erfassten Testing-Aufgaben sowie Features und User-Stories, die bereits mittels eines Release bereitgestellt jedoch nicht abgeschlossen worden sind.

Um dieses Problem gering zu halten, eine Übersicht zu bekommen und den Arbeitsfortschritt zu überwachen, stellt sich die Frage nach der aktuellen Anzahl der Items, die aktuell im System erfasst wurden. Denn die Kontrolle über die Anzahl der Items stellt sicher, dass die Systeme und Arbeitsprozesse funktionstüchtig bleiben. Ausserdem, die Verringerung der Anzahl offener Aufgabenstellungen führt zu einem durchgängigen «Flow» der Aufgabenzustände durch das System. Somit können die Features und User-Stories auf eine überschaubare Art und Weise die Schritte im Entwicklungsprozess durchlaufen und resultieren in einem funktionierenden System. Mit dem Lastfluss wird angestrebt, die Anzahl der in dem System aktuell vorhandenen Items zu identifizieren.  

Die Werte zur Arbeitsflusseffizienz sollen in erster Linie als Frühindikator für eine übersteigende Anzahl der Items in Arbeit (WIP oder Work-in-Progress) dienen. Wobei die geringe Anzahl der Aufgabenstellungen «in Progress» ebenso auf Mangel in der Arbeitsorganisation hinweisen kann. Beide Phänomene können dazu führen, dass die Aufgabenstellungen sich in der Warteschlange (Funnel) ansammeln und somit den Arbeitsprogress hindern. Aus diesem Grund sollte die Arbeitsflusseffizienz überwacht werden, um geeignete Massnahmen rechtszeitig ergreifen zu können.

Als ein geeignetes Mittel für die Visualisierung der Arbeitsflusseffizienz eignet sich das kumulative Flussdiagramm. Mit Hilfe des Diagramms werden die aktuell im System vorhandene Arbeitsmenge, Anzahl der neuen Items, die in die Warteschlage aufgenommen werden, sowie die Anzahl der abgeschlossenen Aufgabenstellungen dargestellt.

Die Ausführung der Messung des Arbeitsflusses ist für Teams in erster Linie notwendig, um den sogenannten «Health Check» von den Arbeitssystemen durchzuführen. Durch die Auswertung der Messresultate erhält das Team Erfahrungswerte, die den Arbeitsprozess in Zukunft verbessern können. Jedoch sollte hierbei beachtet werden, dass Prognosen für die Zukunft mittels dieser Methode nicht getroffen werden können. Wie bereits erwähnt wurde, befassen wir uns in dieser Analyse vor allem mit den Aufgabenstellungen, Features oder User-Stories, die alle Phasen eines Kanban-Boards zu einem gegebenen Zeitpunkt durchlaufen. Auf der Team-Ebene soll die Beobachtung täglich über die Iteration- Dauer oder über die ganze PI-Dauer stattfinden.

Unter anderem sollte überdacht werden, welche Daten für die Analyse des Arbeitsflusses aufgenommen und wie diese Daten erhalten werden. Als erste geeignete Methode steht hier die manuelle Zählung aller auf dem Kanban-Board vorhandenen Features, User-Stories oder Tasks zur Verfügung. Diese Zählung findet regelmässig auf einer täglichen Basis statt und wird in einer dafür geeigneten Tabelle dokumentiert. Falls die Aufgabenstellungen in einem System verwaltet werden, welches die Abfrage der Reports über alle im System vorhandenen Features, User-Stories und Tasks oder dessen Konfiguration ermöglicht, könnte das Generieren eines Reports die Datensammlung deutlich erleichtern.

Die Anwendung der Arbeitsflusseffizienz-Metrik scheint auf den ersten Blick ein aufwendiges Vorgehen zu sein. Jedoch erlernen die für die Messung verantwortlichen Personen den Prozess meistens schnell und können nach einer gewissen Zeit auch eigene Optimierungen in das Messverfahren einbringen. Die Messung kann unter anderem durch den Einsatz der digitalen Tools wie Jira deutlich vereinfacht und beschleunigt werden.

Vorteile der Arbeitsflusseffizienz-Metrik:

  • Übersicht über den aktuellen Stand des Systems und der dazugehörigen Aufgabenstellungen
  • Kontrolle über die Werte wie «Work in Progress», «Zykluszeit» und «Verarbeitungsmenge»
  • Erhöhung der Reife der Softwareentwicklungsprozesse
  • Frühzeitiges «Eingreifen» bei den mangelnden Vorgängen
  • Regulation der Aufgabenstellungen «Funnel», «Review», «In Progress», «Testing» und «Done»

MESSUNG DES BUSINESS-VALUES

Eine weitere wissenswerte und teamspezifische Metrik kann die Beurteilung der Zielerreichung in Bezug auf den Business-Value darstellen. Auch wenn die Messung der Metrik auf den ersten Blick sehr einfach erscheinen mag, ist die Erfüllung und Erreichung des geplanten Business-Values für die Organisation unabdingbar. Doch wie geschieht die Festlegung des Business-Values, in welchen Rahmen findet die Definition und wie findet die Bewertung der einzelnen Punkte statt? Um diese Frage zu beantworten, ist es sinnvoll, ein Verständnis für den gesamten Prozess zu schaffen.

Die Ermittlung des Business-Values startet vorerst mit der Ableitung aktueller PI-Objectives (oder PI- Ziele) an einem PI-Planning-Event. Als zentrales Ziel der Festlegung der PI-Objectives kann die Zusammenfassung der technischen und geschäftlichen Vorteile, die das Team im Rahmen eines PI- Plannings zu erreichen hat, genannt werden.

Der Unterschied zwischen einem Feature und einem PI-Objective liegt im Detailierungsgrad der Information, die am Ende der Beschreibung vorliegt, sowie der Zielgruppe, an welche die zusammengefasste Information ausgerichtet ist. PI-Objectives können als eine Zusammenfassung der zentralen Features oder als Business-Outcome bezeichnet werden. Die Anzahl der Features, die das Team in Rahmen eines PIs umzusetzen hat, ist in der Regel deutlich höher als die Anzahl der PI- Objectives, die in der Regel eine Gesamtmenge von maximal sieben festgelegten Zielen erreichen. Die empfohlene Menge für die PI-Objectives ist hierfür zwischen fünf und sieben, wobei weniger als fünf PI-Objectives die Messung der Zielerreichung verzerren und zu einem höheren Abstraktionsniveau führen, wobei eine hohe Quantität der PI-Objectives das Verständnis aufgrund des zu hohen Detailierungsgrads erschweren kann.

Für die Ermittlung beziehungsweise die Vergabe des Business-Values existieren bereits mehrere mathematische Methoden: «Bubblesort» (Sortierungsmethode), «Planning-Poker», «Break-Even- Analyse», «Cost-of-Delay», «Return-on-Investment», «Cashflow-Analysis» oder auch «Net-Present- Value». Der Einsatz und die Messung des Business-Values mittels einer dieser Methoden würde auf einen fortschrittlichen und gründlichen Ermittlungsprozess in einer Organisation hinweisen und ist leider meistens ein unerreichtes Zielbild. Denn die Anzahl der Features und Teams in einem Agile- Release-Train würde die für die Bewertung verantwortliche Ressource überwältigen. Aus diesem Grund wird der Business-Value in einem SAFe-Kontext als eine relative und teamspezifische Zahl zwischen eins und zehn definiert, um den Wert eines PI-Objectives im Businesskontext zu definieren. Der Business-Value kann aus Sicht der Metrik Agile-Teams dazu befähigen, den Fokus bei der Softwareherstellung auf den Wert und nicht lediglich auf die Zielerreichung auszurichten. Sollten Kapazitätseinschränkungen bei einem Team eintreffen, würde das Team sich auf die zentralen und die höchstbewerteten PI-Objectives und Features konzentrieren.

Wichtig ist zu beachten, dass auf die Definition der Business-Values mehrere Kriterien Einfluss nehmen können; geplanter Gewinn, Umsatz, mögliche Einsparungen, Erhöhung der Kundenzufriedenheit, Reduktion von Risiken, Sicherstellung der Compliance-Vorgaben, kontinuierliches Lernen und weitere. Somit kann der Nutzen als mittelbar und unmittelbar monetär ermittelt werden.

Vorteile der Business-Value-Metrik:

  • Kommunikationsgrundlage über die zu erreichenden und gesetzten Ziele
  • Kontrolle des Verständnisses über die gesetzten Ziele
  • Frühzeitiges Erkennen der Abweichungen im Zielerreichungsverständnis
  • Ergreifen der Massnahmen zur Beseitigung der Problemstellungen

MESSUNG DES ARBEITSFORTSCHRITTES UND VELOCITY EINES RELEASE IM SAFe-KONTEXT

Zu der zentralen Aufgabe eines Release-Train-Engineers gehört die Sicherstellung der Durchführung des geplanten Releases im Rahmen eines PI-Zyklus. Somit bedeutet diese Herausforderung eine ständige Kontrolle des Arbeitsfortschrittes aller an einem PI-Zyklus beteiligten Teams sowie der reibungslosen Erledigung, unter anderem auch der bereichsübergreifenden Arbeiten unter den Teams. Am Ende eines PI-Zyklus stellt der Release-Train-Engineer die Release-Ausführung sicher. Doch wie kann die für das Release-Management auf der Agile-Release-Train-Ebene verantwortliche Person die Einhaltung der Release-Daten und Release-Einheiten sicherstellen oder auch auf mögliche Verzögerungen Einfluss nehmen?

Zu der wirkungsvollsten Vorgehensweise gehört in erster Linie die ständige Überwachung der Umsetzung der geplanten Arbeiten über die Zeitachse hinweg. Am besten findet die Überwachung der Umsetzung mittels der während des PI-Planning-Events geplanten und geschätzten Story-Points statt. Die Story-Points können sowohl auf der Ebene der User-Stories als auch auf der Ebene der Features kontinuierlich überwacht werden. Wichtig ist bei der Beobachtung des Arbeitsfortschrittes zu beachten, dass die Kontrolle über die erledigten Items oder die Items im «Funnel» oder «in Progress» regelmässig stattfinden sollte, da die Visualisierung und Auswertung erst am Ende des PI-Zyklus zu negativen Symptomen des zu entwickelnden Systems führen und die Einhaltung der Release-Planung nicht wünschenswert beeinflussen kann.

Die Metrik des Release- Arbeitsfortschrittes kann zudem dazu benutzt werden, die Anzahl der benötigten Sprints für die Umsetzung vorherzusagen und weist uns damit auch darauf hin, ob die Planung überhaupt eingehalten werden kann. Scaled-Agile-Framework sieht unter anderem die Ausführung eines Releases in Rahmen des sogenannten «Release-on-Demand». Release-on-Demand ist ein Teilschritt aber auch ein finaler Schritt der Continuous-Deliver-Pipeline. Release-on-Demand darf jedenfalls als Prozess verstanden werden, welcher sicherstellt, dass die neuen entwickelten Funktionalitäten sofort und inkrementell an den Kunden bereitgestellt werden. Release-on-Demand besteht aus vier Aktivitäten. Eine dieser Messaktivitäten sieht vor, dass untersucht wird, ob die neuen Funktionalitäten die erwarteten Werte auch mitliefern.

Hier beschäftigen wir uns nun mit einem Messverfahren, mittels welchen der rechtzeitige Release sichergestellt wird. Für die Messung der Release- Zielerreichung der geplanten User-Stories oder Features eignet sich eine Überwachung der für die Ausführung des im PI-Zyklus geschätzten Story-Points am besten. Selbstverständlich kann die Messung auch in Stunden ausgewertet werden. Dieses Vorgehen würde jedoch bekanntlich (unter Berücksichtigung jedes Teams) zu einem höheren Aufwand führen. Die Release-Burn-Down-Chart ist ein Visualisierungsinstrument, welches seine Anwendung in Scrum bereits seit mehreren Jahren gefunden hat. Mittels der Unterstützung des Release-Burn-Down-Charts kann beobachtet werden, wie viele Items durch das Team bereits erledigt worden sind und wie viele Items noch zu erledigen sind. Zudem kann durch die Überwachung des Arbeitsfortschrittes eine weitere Metrik wie die Arbeitsgeschwindigkeit gemessen werden. Das Release-Burn-Down-Chart unterstützt den Release-Train-Engineer dabei Annahmen zu treffen, wann die geplanten Anforderungen an das Produkt (Items) umgesetzt werden. Auf der Ebene eines Agile-Release-Trains stellt ein Release-Burn-Down-Chart die Zusammenfassung der verbliebenen Story-Points dar, welche jeweils pro Sprint und zusammenfassend von allen Teams noch zu verarbeiten sind. Jeder Sprint in einer Grafik repräsentiert die Anzahl der umzusetzenden Story-Points. Auf der Ebene eines Agile-Release-Trains werden die Story-Points aller an dem PI-Zyklus beteiligten Teams zusammengerechnet und grafisch auf einer passenden Skala visualisiert. Der Sprint mit der Nummer «1» beinhaltet die komplette Anzahl der Story-Points, welche in einem gegebenen PI-Zyklus umgesetzt werden sollten. Während des Bearbeitungsprozesses werden bei den umgesetzten User-Stories die Story-Points entfernt und somit bildet sich im nächsten Sprint in Bezug auf die Anzahl der Story Points ein neues Bild. Die Anzahl der umgesetzten Story-Points kann parallel als Sprint-Geschwindigkeit interpretiert und gemessen werden. Durch die konstante Messung der Sprint-Geschwindigkeit wird mit der Zeit eine Vorhersage möglich, wie viele Story-Points durch die Teams in einem Sprint durchschnittlich umgesetzt werden können.

Um die Verarbeitung der Story-Points vorhersagen zu können, ist es möglich im Diagramm die Sprint- Prädiktion-Line zu definieren, mittels welcher festgelegt wird, wie viel Story-Points durch das Team verarbeitet werden mussten, um die Items für den Release rechtzeitig zu liefern. Wichtig ist zu beachten, dass das Release-Burn-Down-Chart nur die Anzahl Story Points aufzeigt, welche am Anfang eines Sprints zur Umsetzung oder Bearbeitung verfügbar sind. Aus diesem Grund darf im Diagramm auch der siebte Sprint geplant werden, in welchem die für den Release nicht bereiten Story-Points und User- Stories platziert würden.

Vorteile des Arbeitsfortschrittes und der Velocity eines Release im SAFe-Kontext:

  • Der Rückstandszustand eines Releases kann rechtzeitig festgestellt werden
  • Basierend auf den erzielten Erkenntnissen können die für die Verbesserung notwendigen Massnahmen jederzeit und frühzeitig ergriffen werden
  • Feststellung der Teams, welche die Umsetzung der Release-Ziele verzögern
  • Schaffung der Erfahrungswerte, welche für die nächstfolgenden Release verwendet werden können
  • Vorhersage, ob die Release-Ziele in dem gegebenen PI-Zyklus umgesetzt werden
  • Das Treffen der Vorhersagen in Bezug auf die Verarbeitung der Story Points
  • Übersicht über die gesamte Anzahl der Story-Points und dessen Umsetzung
  • Velocity-Metrik als ein zusätzlicher Nebenwert

ALLES KLAR? ODER KÖNNEN WIR DIR HELFEN?

Neben den ausgeführten Metriken existieren noch viele weitere Möglichkeiten, den effektiven Erfolg im agilen Umfeld zu messen. YOUNITY kann dich dabei unterstützen, dein aktuelles Framework unter die Lupe zu nehmen, passende Messverfahren zu entwerfen und auszuwerten. Damit du jederzeit weisst, ob die Agilität in deinem Unternehmen wirklich das leistet, was sie sollte. Entdecke auch noch weitere spannende Leistungen unserer Project Force:

BUILD

MARKETING PROJECT FORCE

Die Marketing Project Force ist voll und ganz für die methodische Vorbereitung und Realisierung deiner Massnahmen, Epics und Projekte da. Sie stellt jederzeit eine vollumfängliche Umsetzung sicher.

Mehr erfahren

Visualisierungen: Nataliia Vidanova, Beitragsbild: Fauxels, pexels.com

Kommentar schreiben
Dieses Feld kann nicht leer sein.
Dieses Feld kann nicht leer sein.
Diese E-Mail-Adresse ist ungültig.
Sie müssen die Datenschutzbestimmungen akzeptieren.