Inhalt

Inhalt

Obwohl es bei der Diskussion von Agile- und Lean-Kennzahlen einige Unterschiede zu beachten gilt, spielen diese Kennzahlen letztlich eine ähnliche Rolle. In diesem Artikel geht es darum, wie der bewusste Einsatz von Lean- und Agile-Kennzahlen dazu beitragen kann, dass Agile Release Trains (ARTs) effektiver arbeiten, kontinuierliche Verbesserung vorantreiben und ihre Agile-Programme stützen.

Die sieben Vorteile der Agile-Skalierung

Weitere wichtige Vorteile der agilen Skalierung, einschließlich empfohlener Best Practices für deren Implementierung, finden Sie in diesem E-Book.

E-Book lesen • Die sieben Vorteile der Agile-Skalierung

Erste Schritte mit Lean

Lean ist eine Denkweise, die Ihnen hilft, intelligentere Entscheidungen darüber zu treffen, wie Sie Ihre Zeit, Energie und Ihr Geld investieren können.

E-Book lesen • Erste Schritte mit Lean
Der Flow ist eine Lean-Kennzahl, die sich darauf bezieht, wie die Arbeit in einem System voranschreitet; im Gegensatz dazu analysieren Agile-Kennzahlen die Leistung in zeitgesteuerten Iterationen.
Der Flow ist eine Lean-Kennzahl, die sich darauf bezieht, wie die Arbeit in einem System voranschreitet; im Gegensatz dazu analysieren Agile-Kennzahlen die Leistung in zeitgesteuerten Iterationen.

Was sind Agile-Kennzahlen?

Zunächst: Was sind Agile-Kennzahlen? Um die Antwort auf diese Frage zu verstehen, ist es hilfreich, sich die Ursprünge von Agile anzusehen. Agile fasste vor einige Jahrzehnten Fuß, etwa zur selben Zeit, als die Disziplin der Softwareentwicklung Gestalt annahm.

Softwareentwicklungsteams brauchten eine bessere Methode, um die einzigartigen Herausforderungen im Rahmen ihrer Arbeit zu bewältigen. Bestehende Workflows wie etwa die zur Herstellung physischer Güter eigneten sich nicht gut für den komplexen Charakter der Softwareentwicklung.

Zum einen ist Softwareentwicklung iterativ. Sie ist zyklischer Natur und nicht linear, wie viele der Workflows in anderen Bereichen. Sie ist auch von Haus aus komplex und erfordert verschiedene Arbeitstypen (Planung, Entwicklung, Tests, Support usw.), alle mit eigenen Workflows, alle vom selben Team ausgeführt.

Dem, was wir heute als Agile kennen, gingen mehrere Methodiken voraus, darunter XP, Scrum und andere. Das Agile, das die Grundlage für heutige Agile-Kennzahlen bildet, enthält viele Elemente und Kerngedanken dieser Methodiken. Obwohl Agile speziell für das Management des Softwareentwicklungsprozesses entwickelt wurde, ist es in praktisch allen Disziplinen übernommen worden.

Agile wurde ursprünglich als Methode für Teams entwickelt, ohne wirkliche Anleitung, wie Agile-Praktiken im Unternehmen skaliert werden können. Agile Programm-Management ist die Bezeichnung für die Methoden, die entwickelt wurden, um Agile-Skalierung erfolgreich zu praktizieren.

Der Kern von Agile ist das Bestreben, durch einen besseren Prozess ein besseres Produkt zu entwickeln. Eines der Markenzeichen von Agile sind die zeitgesteuerten Iterationen oder Sprints, die in der Regel zwei Wochen dauern und in denen Teams Arbeit durchführen, die sie als vorrangig eingestuft und zu der sie sich verpflichtet haben. Die Arbeit in Sprints erlaubt Agile-Teams, ein Gleichgewicht zwischen konzentrierter Durchführung, Echtzeitplanung und Entscheidungsfindung herzustellen.

Agile-Kennzahlen geben Einblick in die Leistung eines Teams oder einer Gruppe von Teams und werden in festen Iterationen (Sprints) gemessen und analysiert. Sie sollen Teams helfen, ihre Produktivität und Effektivität in den verschiedenen Phasen des Lebenszyklus ihrer Softwareentwicklung (oder allgemeiner gesagt, Entwicklung) zu analysieren.

Agile-Kennzahlen sollen keine Geschäftskennzahlen ersetzen, sondern vielmehr in Verbindung mit ihnen genutzt werden. Geschäftskennzahlen messen, ob die Lösungen den Marktanforderungen entsprechen. Agile-Kennzahlen messen, wie gut das Team diese Lösungen liefern kann.

Was sind Lean-Kennzahlen?

In ähnlicher Weise sollen Lean-Kennzahlen in Verbindung mit Geschäftskennzahlen genutzt werden, um einen ganzheitlichen Blick auf den Systemstatus zu ermöglichen. Lean-Kennzahlen messen die Effizienz des Systems und werden in der Regel von Teams verwendet, die eine Lean-Methodik praktizieren, darunter Kanban, Lean und andere.

Das Verständnis der Geschichte von Lean ist auch hilfreich, um nachzuvollziehen, wie Lean-Kennzahlen verwendet werden sollen. Die Praktiken, die wir heute unter Lean verstehen, entstanden in den Werkstätten japanischer Automobilhersteller zu Beginn des 20. Jahrhunderts. In dem Bestreben, den Marktanteil zu dominieren und durchweg ein qualitativ hochwertiges Produkt herzustellen, suchte man nach Wegen, um (sowohl physische als auch prozessbedingte) Verschwendung zu reduzieren, die Effizienz zu steigern, die Variabilität zu minimieren und mit weniger Ressourcen mehr Nutzen zu schaffen.

So entstand das Toyota-Produktionssystem, das iteriert wurde und als „Lean Manufacturing“ oder „schlanke Produktion“ bekannt wurde. Zum Ende des Jahrhunderts begannen viele Softwareentwicklungsteams damit, Lean-Prinzipien und -Praktiken zu übernehmen, und der Einfluss von Lean strahlte auch auf andere Teams aus.

Agile-Kennzahlen versus Lean-Kennzahlen

Da sie viele Schlüsselkonzepte, Ziele und sogar Terminologie gemeinsam haben, überrascht es nicht, dass die Grenzen zwischen Agile und Lean häufig unscharf sind. Es gibt keine Regel, die besagt, dass Sie nicht sowohl Lean- als auch Agile-Kennzahlen verwenden sollten – aber es kann hilfreich sein, die Unterschiede zwischen Agile- und Lean-Kennzahlen zu verstehen, damit Sie sie im Kontext verwenden können.

Der Hauptunterschied zwischen Agile- und Lean-Kennzahlen besteht darin, dass viele Agile-Kennzahlen dazu dienen, die Leistung während zeitgesteuerter Iterationen zu analysieren, während Lean-Kennzahlen dazu dienen, die Leistung in einem System zu messen, das auf einen kontinuierlichen Flow hinarbeitet.
Agile-Kennzahlen Lean-Kennzahlen
Sind im Zusammenhang mit einem kontinuierlichen Flow zu verwenden. Sind im Zusammenhang mit einem kontinuierlichen Flow zu verwenden.

Agile-Kennzahlen versus Lean-Kennzahlen versus Geschäftskennzahlen

Wie bereits erwähnt, sollen weder Agile- noch Lean-Kennzahlen Geschäftskennzahlen ersetzen. Geschäftskennzahlen wie Verkaufserlöse, Bruttomargen, Net Promoter Score usw. helfen einem Unternehmen zu beurteilen, wie gut es den Marktbedarf erfüllt.

Geschäftskennzahlen werden normalerweise auf Unternehmensebene gemessen und gemeldet. Sie werden oft verwendet, um Teams auf bestimmte Ziele auszurichten, und von Führungskräften eingesetzt, um zu beurteilen, wie gut die Teams diese Ziele verfolgen.

Agile-Kennzahlen und Lean-Kennzahlen Geschäftskennzahlen
Helfen Teams und Teams of Teams, die eigene Leistung zu analysieren. Werden normalerweise auf Team- oder Programmebene gemessen und gemeldet. Helfen einem Unternehmen zu beurteilen, wie gut es den Marktbedarf erfüllt. Werden normalerweise auf Unternehmensebene gemessen und gemeldet.

Lean- und Agile-Kennzahlen sind dazu gedacht, von Teams oder Teams of Teams zur Bewertung der eigenen Leistung verwendet zu werden. Sie sollten nicht verwendet werden, um Teams gegeneinander antreten zu lassen. Anders als Geschäftskennzahlen sollten sie von Führungskräften nicht verwendet werden, um Teams „zu überprüfen“.

Wie bei Geschäftskennzahlen ist es wichtig, Lean- und Agile-Kennzahlen immer im Kontext zu analysieren und zu verstehen, wann, wo und warum die Daten gesammelt und weitergegeben werden.

Typen von Agile-Kennzahlen

Bereitstellungskennzahlen: Releasehäufigkeit und Bereitstellungstempo

Was sie ist Was sie misst Was sie aussagt Warum sie für ARTs wichtig ist
Am Ende jedes Sprints sollten Agile-Teams ein funktionierendes Produkt in die Produktion geben. Bei Software kann dies ein Feature oder eine Fehlerbehebung sein. In anderen Disziplinen kann es sich um eine Marketingkampagne, eine Website-Aktualisierung oder ein neues Produktdesign handeln. Die Releasehäufigkeit misst, wie oft Agile-Teams am Ende jedes Sprints tatsächlich fertige Arbeit abliefern können. Das Bereitstellungstempo misst, wie lange es dauert, einen bestimmten Arbeitstyp abzuschließen. Die Messung von Releasehäufigkeit und Bereitstellungstempo kann Teams helfen, zu verstehen, wie gut ihre Planung und Durchführung während der Sprints ist. Für Agile-Release-Teams können diese Agile-Kennzahlen Planung und Kapazitätsmanagement besser und genauer machen.

Geschwindigkeit

Was sie ist Was sie misst Was sie aussagt Warum sie für ARTs wichtig ist
Geschwindigkeit ist ein Maß für die durchschnittliche Menge an Arbeit, die ein Team während eines Sprints absolviert, gemessen entweder in Story Points oder Stunden. Die Geschwindigkeit misst, wie viele Arbeitselemente in einem bestimmten Zeitraum abgeschlossen werden können, etwa Story Points pro Iteration. Die Messung der Geschwindigkeit ist am hilfreichsten, wenn Teams sie über längere Zeiträume analysieren. Neue Teams können mit einem stetigen Anstieg der Geschwindigkeit rechnen, wenn das Team seinen Arbeitsprozess optimiert. Bestehende Teams können ihre Geschwindigkeit verfolgen, um längerfristig eine gleichbleibende Leistung zu gewährleisten, und können sehen, ob eine bestimmte Prozessänderung Verbesserungen gebracht hat oder nicht. Die Geschwindigkeit hilft Agile-Teams zu beurteilen, wie konsequent und effektiv sie ihre Arbeit planen, ausbalancieren und durchführen. Sie ist auch hilfreich für Prognosen, denn mittelfristig können Teams anfangen vorherzusagen, wie schnell sie ihre Backlogs abarbeiten können.

Sprint-Burndown

Was sie ist Was sie misst Was sie aussagt Warum sie für ARTs wichtig ist
Zu Beginn jedes Sprints prognostizieren Agile-Teams, wie viel Arbeit sie in diesem Sprint erledigen wollen. Im Sprint-Burndown-Bericht wird der Abschluss der Arbeit während des Sprints verfolgt. Die x-Achse stellt die Zeit dar, die y-Achse bezieht sich auf die Menge der noch zu erledigenden Arbeit, gemessen entweder in Story Points oder Stunden. Ziel ist, bis zum Ende des Sprints alle prognostizierten Arbeiten abgeschlossen zu haben. Ein Sprint-Burndown-Bericht kann vor, während und nach einem Sprint verwendet werden, um zu messen, wie das Team auf dem Weg zu seinen Arbeitszielen vorankommt. Vorhersagbarkeit ist der Schlüssel für Agilität, und Agile-Kennzahlen wie Sprint-Burndown (neben Epic- und Release-Burndown) können Teams bei Planung, Durchführung und Bereitstellung von Nutzenzuwächsen mit mehr Vorhersagbarkeit unterstützen.

Epic- und Release-Burndown

Was sie ist Was sie misst Was sie aussagt Warum sie für ARTs wichtig ist
Um den Fortschritt bei größeren Arbeitseinheiten zu verfolgen, nutzen agile Unternehmen Epic- und Release-Burndown-Berichte. Diese Berichte verfolgen den Abschluss der Arbeit während einer Reihe von Sprints. Die Messung des Burndowns auf dieser Ebene kann Agile-Teams (und ARTs) helfen, den Scope Creep zu managen – das Hinzufügen neuer Anforderungen, nachdem der Umfang des Epics oder Releases bereits definiert war. Wenn ein ART seine Prognosen konsequent erfüllt, ist dies ein zwingendes Argument für Agile im Unternehmen. Wenn nicht, können diese Agile-Kennzahlen helfen, die Kapazitätsplanung künftig zu unterstützen. Die Verfolgung von Epic- und Release-Burndown kann ARTs helfen, nachzuvollziehen, wie akkurat sie prognostizieren – unerlässlich für Vorhersagbarkeit. Sie kann auch zur Verstärkung des Gedankens beitragen, sich nicht zu ungeplanter Arbeit innerhalb eines Epics zu verpflichten, was Teams weiter ermutigen kann, ihre Agilität zu erhalten.

Typen von Lean-Kennzahlen

Anders als Agile-Kennzahlen messen Lean-Kennzahlen wie erwähnt die Leistung in einem System, das auf einen kontinuierlichen Flow hinarbeitet.

Zykluszeit

Was sie ist Was sie misst Was sie aussagt Warum sie für ARTs wichtig ist
Ein Maß dafür, wie lange Arbeit im Prozess des Teams von Punkt A nach Punkt B braucht. Die Zeit, die ein Arbeitselement benötigt, um zwei bestimmte Punkte in einem Prozess zu durchlaufen. Beim Kanban die Zeit, in der eine Karte von einer bestimmten Bahn in die nächste gelangt (welche, hängt davon ab, welchen Teil des Prozesses das Team zu messen versucht). Wie lange bestimmte Teile des Prozesses dauern könnten; daher wird ein Einblick gegeben, wo Arbeit im Prozess des Teams steckenbleibt und wie der Flow verbessert werden kann. Sowohl Durchlauf- als auch Zykluszeit helfen Teams zu verstehen, wie lange die Arbeit für das Durchlaufen ihrer Workflows braucht, aber sie messen verschiedene Segmente des Prozesses. Während die Durchlaufzeit die Gesamtzeit misst, die ein Arbeitselement im System verbringt, misst die Zykluszeit, wie lange ein Arbeitselement braucht, um von Punkt A nach Punkt B zu gelangen. Je nach wirtschaftlichem Nutzen, den Teams messen wollen, können sowohl Zykluszeit als auch Lead Time bzw. Durchlaufzeit direkt auf das Team angewandt werden. Wenn das Team beispielsweise die Bereitstellungskapazitäten des Softwareentwicklungsteams verbessern möchte, kann die Zykluszeitmessung die Zeit verfolgen, die ein Arbeitselement vom Zeitpunkt des Code Commit bis zum Deployment benötigt. Die Messung der Zykluszeit ist ein guter Ausgangspunkt, da sie verwertbare Einblicke liefert, egal wie klein der Datensatz ist. Sie ist eine effiziente und flexible Methode, um die Prozesse eines Teams zu verbessern, da die Ergebnisse von Änderungen fast sofort erkennbar sind, sodass direkt weitere Anpassungen möglich sind. Das Endziel ist eine konsistente und kurze Zykluszeit, unabhängig vom Arbeitstyp (neues Feature, technische Schulden usw.).

Lead Time

Was sie ist Was sie misst Was sie aussagt Warum sie für ARTs wichtig ist
Die Lead Time bzw. Durchlaufzeit misst die Gesamtzeit, in der Arbeit den Value Stream durchläuft, vom Zeitpunkt der Anforderung der Arbeit bis zu ihrer Bereitstellung. Die Lead Time misst die Dauer von Anfang bis Ende. Das beinhaltet die Prozesszeit ebenso wie die Zeit, die Arbeit in Warteschlangen oder im Wartezustand verbringt. Die Zeit, die ein Arbeitselement benötigt, um den gesamten Prozess von Anfang bis Ende zu durchlaufen. Beim Kanban die Zeit von der Erstellung einer Karte bis zu ihrem Übergang in die Spalte „Erledigt“ (gemeldet in Lead-Time- und Zykluszeitberichten). Die vermeintliche Zeit, die eine Arbeit in den Augen des Kunden (intern oder extern) beansprucht hat. Durch Verfolgung von Lead-Time-Kennzahlen in einem bestimmten Zeitraum können Teams die Auswirkungen aller von Ihnen vorgenommenen Änderungen ermitteln – ob sie dazu beitragen, Kunden schneller Nutzen zu erbringen oder dem im Weg stehen. Die Lead Time hilft Teams, vorhersagbarer zu werden, da sie die Wahrscheinlichkeit des prozentualen Anteils der Arbeit quantifiziert, die in einem bestimmten Zeitrahmen erledigt wird.

Kumulativer Flow

Was sie ist Was sie misst Was sie aussagt Warum sie für ARTs wichtig ist
Ein Cumulative Flow Diagram (CFD) ist eine grafische Darstellung dessen, wie der Umlaufbestand (Work in Process, WIP) des Teams durch das Kanban-System fließt. In einem CFD stellt jedes Farbband eine Bahn auf dem Board dar, und die Breite (vertikal) der Bahn stellt die Anzahl der Karten in dieser Bahn dar. Wird der WIP auf die Zeit (horizontale Achse) aufgetragen, kann das Team sehen, wie er sich in dieser Bahn verändert. Wird der WIP weniger, verengt sich die Bahn; nimmt er hingegen zu, beginnt sich die Bahn zu „wölben“. Durch Ziehen einer vertikalen Linie vom Rand der „Erledigt“-Bahn bis zum Rand der obersten Bahn erhalten Teams den gesamten WIP zu diesem Zeitpunkt. Ein CFD bietet einen schnellen, visuellen Einblick in den gesamten WIP in einem System und darin, wie er durch das System fließt. Es kann verwendet werden, um Burnup-Verläufe für die Arbeit zu berechnen und eine schnelle visuelle Identifizierung der Stellen zu ermöglichen, an denen Prozessengpässe entstehen können. Die Kennzahl hilft Teams, den Status der aktuellen Arbeit nachzuvollziehen und zu verstehen, was möglicherweise getan werden muss, um das Bereitstellungstempo zu erhöhen. Ein Cumulative Flow Diagram hilft Teams sicherzustellen, dass der Arbeitsfluss überall im Team (oder Team of Teams) einheitlich ist. Es vereinfacht das Erkennen von Engpässen, insbesondere wenn es in Verbindung mit WIP-Limits verwendet wird.

Über Betriebskennzahlen hinaus vorankommen

Sowohl Lean- als auch Agile-Kennzahlen sind Tools, die dazu dienen, die Teamleistung zu quantifizieren und handlungsrelevante Einblicke für Verbesserungen zu liefern. Doch ebenso wie man mit einem Hammer ein Baumhaus bauen oder eine Vase zerstören kann, müssen diese Werkzeuge bewusst und korrekt eingesetzt werden, um den beabsichtigten Zweck zu erreichen.

Bevor sich Teams in die Sammlung von Daten und die Implementierung von Änderungen stürzen, müssen sie verstehen, warum diese Kennzahlen wichtig sind und wie sie zu kontinuierlicher Verbesserung beitragen können. In herkömmlichen Unternehmenskulturen wurden bzw. werden Kennzahlen oft immer noch verwendet, um die Teamleistung genau und auf eine Weise zu überwachen, die echter Innovation abträglich ist.

Es ist davon auszugehen, dass es in jedem Team Personen gibt, die sich gegen die Idee des Sammelns, Analysierens und Diskutierens von Lean- und Agile-Kennzahlen sträuben. Es ist wichtig, den Gedanken zu verfestigen, dass diese Kennzahlen nur für Teams (und Teams of Teams) gedacht sind, um die eigene Leistung zu verbessern, denn das ist der Kontext, in dem sie wirklich nützlich sind.

Ebenso ist es wichtig, nicht die Kennzahlen selbst zum Ziel werden zu lassen: Das Ziel ist, durchgehend Nutzen zu erbringen und dabei die Vorhersagbarkeit und Gesundheit des Systems zu erhöhen. Das Ziel ist nicht die schnellste Zykluszeit oder der präziseste Sprint-Burndown – sie sind Mittel zum Zweck. Doch wenn das Endziel unklar ist, sind diese „Errungenschaften“ vergeblich.

Anders gesagt, geht es nicht nur darum, Dinge zu tun – es geht darum, die richtigen Dinge zu tun. Alle Lean- und Agile-Kennzahlen sollten in der Produkt-Roadmap verankert werden. Für jede Initiative auf der Roadmap sollte es mehrere Leistungskennzahlen geben, die den Programmzielen entsprechen.

Es muss auch Erfolgskriterien für jede Anforderung geben, etwa die Akzeptanzquote bei Endbenutzern oder der Prozentsatz des Codes, der durch automatische Tests abgedeckt wird. Diese Erfolgskriterien fließen in die Agile-Kennzahlen des Programms ein. Je mehr Teams lernen, desto besser können sie sich anpassen und weiterentwickeln.

Der erste Schritt besteht darin, die gewünschten Ergebnisse (OKRs) zu definieren und die richtigen Kennzahlen auszuwählen, um den Fortschritt bezüglich dieser Ziele zu messen. Der nächste Schritt besteht darin, es Teams einfach zu machen, diese Daten zu sammeln und zu analysieren.

Lean- und Agile-Kennzahlen sollten häufig überprüft und diskutiert werden. Mit der Zeit häufen sich diese Daten an, und Teams können sie nicht nur nutzen, um ihre bisherige Leistung zu verbessern, sondern auch, um genauer vorherzusagen, wie sich heutige Veränderungen auf künftige Leistung auswirken.