On Lean and Agility

Grafik: Itimar Gilad - CC BY-SA 4.0

Würde man die Entwicklungsteams dieser Welt diejenigen Fragen nennen lassen, die am schwersten zu beantworten sind, würde eine mit ziemlicher Sicherheit weit oben landen: "Wie sicher seid Ihr, dass Euer Produkt am Markt erfolgreich sein wird?" Vor allem wenn etwas neu entwickelt wird (also in der IT eigentlich immer) ist eine wirklich sichere Antwort aufgrund fehlender Erfahrungswerte kaum möglich, gleichzeitig ist die Antwort "Kann man nicht sagen" natürlich auch unbefriedigend, schliesslich müssen Investitions- oder Abbruch-Entscheidungen ja irgendwann getroffen werden. Ein Dilemma.

Ein Weg um aus diesem Dilemma zu entkommen und zu realistischen Zuversichts-Werten zu kommen ist das Confidence Meter von Itimar Gilad. Mit seiner Hilfe lässt es sich die Bewertung aus verschiedenen Einfluss-Faktoren ableiten, und das nicht etwa nur auf Basis von Bauchgefühl, sondern auf der Grundlage überprüfbarer und in ihrer Gewichtung abgestufter Erkenntnisse, bzw. Ergebnisse. Dadurch ist dieser daraus summierte Wert nicht nur differenzierter, er ist auch weniger anfällig für unrealistisch optimistische Selbsttäuschungen und Manipulationen. Die (vereinfachten) Faktoren sind:

Individuelle Überzeugungen (Zuversichtswert 0,1)

Damit fängt alles an. Irgendjemand (Person oder Gruppe) hat die initiale Idee und glaubt daran, dass aus ihr etwas Grosses werden kann. Das ist wichtig und darf nicht geringgeschätzt werden, eine auch nur irgendwie geartete Erfolgswahrscheinlichkeit lässt sich aber kaum daraus ableiten.

Ein Pitch Deck (Zuversichtswert 0,1)

Sich selbst überzeugt zu haben ist ein erster Schritt, als nächstes gilt es andere zu überzeugen. Überlicherweise geschieht das mit einer Präsentation der (angenommenen) Potentiale und Vorteile. Die zu erstellen verhilft zu strukturierteren Annahmen, zu mehr aber noch nicht.

Aktuelle Trends, Moden und Buzzwords (Zuversichtswert 0,1)

Man kann hier einen beliebigen Hype einsetzen: Digital, Mobil, KI, was auch immer. Darauf aufzuspringen erscheint naheliegend und verlockend, eine auch nur irgendwie geartete Erfolgswahrscheinlichkeit lässt sich aber noch immer kaum daraus ableiten.

Unterstützende Meinungen (Zuversichtswert 0,5)

Ab hier wird es schon ein ganz kleines bisschen objektiver. Wenn auch andere Personen der Meinung sind, dass die Idee Potential haben könnte, ist das eine erste Bestätigung. Und wenn diese Personen auch noch über Budgets oder sonstige Ressourcen verfügen, um so besser.

Schätzungen und Planungen (Zuversichtswert 0,5)

Nehmen wir an, dass Budget da ist, jetzt kann überlegt werden, wie und wann es investiert wird. Das kann sehr dabei helfen, die Umsetzbarkeit zu beurteilen (ein durchaus wichtiger Punkt), ob das Produkt am Markt erfolgreich sein wird, ist aber noch immer sehr ungewiss.

Anekdotische Evidenz (Zuversichtswert 1)

An dieser Stelle gibt es zum ersten Mal eine kleine empirische Validierung. Irgendwo ist ein (angeblich) vergleichbares Vorhaben erfolgreich gewesen. Darin steckt im Zweifel noch viel Hören-Sagen, aber zumindest ist es zum ersten Mal etwas, das über Vermutungen und Hoffnungen hinausgeht.

Marktforschung (Zuversichtswert 3)

Mit Marktforschung wird Hören-Sagen durch eine erste, noch abstrakte, Bedarfsermittlung ersetzt. Ob die potentiellen Kunden und Nutzer aus diesem möglichen Bedarf eine konkrete Kaufentscheidung ableiten werden ist unklar, zumindest hat man sie jetzt aber erstmals überhaupt befragt.

Kunden-, bzw. Anwender-Wünsche (Zuversichtswert 3)

Ab hier wird es konkreter. Konfrontiert mit den ersten Entwürfen des zukünftigen Produkts können potentielle Kunden und Nutzer Wünsche, Erwartungen und Nutzungs-Absichten äussern. Noch keine Erfolgsgarantie, aber ein starker Indikator.

Ergebnisse von Kunden-, bzw. Anwender-Tests (Zuversichtswert 5)

Aus dem starken wird an dieser Stelle ein sehr starker Indikator. Test- und Focus-Gruppen bekommen Prototypen oder MVPs zur Verfügung gestellt und können Rückmeldung zur Benutzungs-Erfahrung und zum wahrgenommenen Mehrwert geben, ggf sogar schon zur Kauf-Absicht.

Echte Verkaufs- und Nutzungsdaten (Zuversichtswert 10)

In diesem letzten Stadium hat der Verkauf bereits begonnen und die ersten Zahlen zu Absatz und Nutzung wurden bereits ermittelt. Die Indikatoren werden jetzt nach und nach durch Beweise abgelöst, die Erfolgswahrscheinlichkeit ist klar abzusehen oder sogar bereits ermittelt.

Wie oben gesagt, diese Übersicht ist etwas vereinfacht, hinter den einzelnen Faktoren stecken nochmal Bandbreiten und Gewichtungen. Die Details dazu (inclusive einer Tabelle mit Berechnungsformeln) hat Itimar Gilad freundlicherweise auf seiner Website zur Verfügung gestellt. Wichtig ist aber, dass sich am Ende aus den Ausgangswerten der einzelnen Faktoren eine Gesamtsumme bildet, die einen realistischen, kaum verfälschbaren Zuversichtswert auf einer Skala zwischen 1 und 10 abbildet.

Was bei näherer Betrachtung dieses Modells auffällt ist, dass sich hohe Zuversichtswerte erst relativ spät, bzw. kurz vor dem Markteintritt ergeben können. Das ist für alle, die möglichst früh möglichst viel Sicherheit haben wollen, natürlich ärgerlich. Auf der anderen Seite ist es aber auch die harte Wahrheit - frühe Sicherheit gibt es bei neuen Produkten nicht. Wer nicht bereit ist das zu akzeptieren, dem werden auch Tools wie dieses hier nicht helfen.

Noch einmal zum Thema Velocity. Obwohl diese Metrik kein offizieller Teil von Scrum ist, ist sie in vielen Teams ein wesentliches Element der Umsetzung dieses Frameworks. Was dabei im Mittelpunkt steht, ist in der Regel der Planungs-Aspekt, also die Ableitung zukünftiger Arbeitsleistung aus der durchschnittlichen Story Point-Menge der letzten Sprints (siehe hier). Es gibt aber auch einen zweiten, seltener thematisierten Aspekt: eine Velocity erzeugt auch ein Work in Progress Limit (WIP Limit).

WIP Limits kennt man eigentlich aus Kanban und anderen Lean-Ansätzen, wo sie verwandt werden, um Überlastung und Multitasking zu vermeiden und den Arbeitsfluss zu verbessern. Die Idee ist eigentlich einfach: dadurch, dass eine Obergrenze für gleichzeitig bearbeitete Aufgaben eingeführt wird, werden weniger Arbeitspakete gleichzeitig begonnen, Multitasking und Koordinationsaufwände gehen zurück und Ergebnisse werden schneller fertig.

Das klingt erstmal gut, in der Realität kommt es allerdings regelmässig dazu, dass diese Obergrenzen zu hoch angesetzt werden. Wenn ihre Festlegung durch das Management erfolgt kann das z.B. daran liegen, dass die Kapazität der Umsetzungsebene zu optimistisch eingeschätzt wird (oft verbunden mit Wunschdenken in Bezug auf Fertigstellungstermine), oder dass möglichst vielen Stakeholdern das Gefühl gegeben werden soll, dass ihre Anliegen bearbeitet werden.

Aber auch wenn die Verantwortung für das Setzen der WIP Limits bei den jeweiligen Umsetzungsteams liegt, sind diese häufig zu hoch. Auch das kann daran liegen, dass versucht wird, möglichst viele Stakeholder zu befriedigen, mindestens genauso häufig ist aber eine unrealistisch optimistische Einschätzung der eigenen Leistungsfähigkeit oder eine Unterschätzung des mit bestimmten Tätigkeiten verbundenen Arbeitsaufwands.

Die Verwendung der Velocity sorgt dafür, dass die WIP-Obergrenzen realistischer werden. Wenn der durchschnittliche  Output der letzten Sprints (Yesterdays Weather) bei 18 Punkten liegt, und demzufolge auch maximal diese Menge für den nächsten eingeplant werden soll, dann verschwinden "politische" Handlungsmotive und unsichere Faktoren wie die Selbst- und Fremdeinschätzung der Leistungsfähigkeit eines Teams aus dem Planungsprozess. Alleine dadurch werden die Planungen besser.

Der Vollständigkeit halber sei noch angemerkt, dass Scrum Teams die Planung ihrer Sprints eigentlich nicht an einem Output (in diesem Fall der Velocity) sondern an einem Outcome orientieren sollten, also an dem fachlichen Sprint-Ziel, dessen Umsetzungsaufwand eine gewisse Variabilität haben sollte, um auf ungeplante Entwicklungen reagieren zu können. Wenn aber (warum auch immer) eher Outcome-orientiert gearbeitet wird, kann ein auf der Velocity beruhendes WIP Limit eine gute Idee sein.

Grafik: Wikimedia Commons / Daniel Penfield - Public Domain

Dritter Teil der Übersicht über die Lean-Metriken. Nach einer allgmeinen Übersicht über die Typen von Durchlaufzeiten im ersten Teil (zu finden hier) und die einer Einführung in die Flusseffektivität im zweiten Teil (zu finden hier) soll es heute um die Flusseffizienz gehen. Um diese ähnlich klingenden Begriffe zu unterscheiden: während es bei der Effektivität darum geht die eigenen Tätigkeiten auf Sinnhaftigkeit zu optimieren (→ wenig Waste) hat Effizienz die Leistungsfähigkeit als Ziel (→ hoher Ausstoß). Zu beachten ist dabei natürlich, dass beides angestrebt werden sollte, hier soll es aber jetzt nur um Metriken für die Flusseffizienz gehen.

Takt Time

Die Takt Time bezeichnet die (anzustrebenderweise) immer gleich bleibende Zeit die zur Fertigstellung eines Liefergegenstandes benötigt wird, beispielsweise die 30 Sekunden die für einen Stanz- oder Fräs-Vorgang nötig sind. Eine der Lean-Metriken die nur schwer in die Software-Entwicklung übertragbar sind, wenn überhaupt eher auf automatisierte Prozesse als auf Programmiertätigkeiten.

Throughput Time

Auf Deutsch der Durchsatz. Bei ihm wird nicht mehr die Dauer einzelner Arbeitsvorgänge gemessen, sondern die Anzahl der erzeugten Ergebnisse (Produkte, Features, etc.) pro Zeiteinheit. Ein Beispiel wären 500 Autos die pro Tag in einer Fabrik gebaut werden. Aus dem Versuch die Throughput-Messung in die Software-Enwicklung zu übertragen ist das Konzept der Velocity entstanden.

Maintenance Time

Eine Metrik die leicht für einen Teil der Blocked Time gehalten werden kann, da Maintenance (Wartung) ähnlich wie diese dafür sorgt, dass die eigentliche Arbeit nicht stattfinden kann. Die Differenzierung: statt die Gesamtzeit der Nichtverfügbarkeit zu messen geht ist hier um die Durchschnittsdauer eines Wartungsintervalls, die idealerweise möglichst kurz sein sollte.

Recovery Time

Dieser Metriken-Typ ist von Bedeutung wenn es trotz Wartungen zu unfallbedingten Ausfällen kommt und misst die Durchschnittsdauer der Reparaturen und und der anschliessenden Wiederinbetriebnahme. Diese Dauer möglichst kurz zu halten ist nochmal wichtiger als bei der Maintenance Time, da das Eintreten von Zwischenfällen und Recovery-Phasen meistens unvorhersehbar und nicht planbar ist.

Flusseffizienz

Sowohl in Bezug auf die Produktion von Ergebnissen (Produkte, Features, etc.) als auch in Bezug auf Wartungen und Wiederinbetriebnahmen ist es das Ziel, die durchschnittliche Erstellungs- oder Bearbeitungszeiten so kurz wie möglich zu halten. Mit Hilfe der hier genannten Metriken darauf zu optimieren ermöglicht eine höhere Effizienz im Arbeitsfluss, die aber nicht ohne Risiko ist.

Eine ausschliessliche Fixierung auf Flusseffizienz macht vor allem in der Serienfertigung Sinn, in der Produktentwicklung besteht das Risiko, dass man in der Build Trap landet, also versehentlich das Falsche produziert, davon aber sehr schnell sehr viel. Hier solte also regelmässig überprüft werden, ob man noch immer in der richtigen Richtung unterwegs ist.

Bild: Pixabay / Prawny - Lizenz

Zweiter Teil der Übersicht über die Lean-Metriken (Teil 1 ist hier). Auch mit dieser Erweiterung ist die Aufzählung sicher noch nicht vollständig, irgendwann kommt mindestens noch ein dritter Teil (Nachtrag: hier ist er). Zunächst aber soll es hier um die Fluss-Effektivität gehen, also um Metriken, mit deren Hilfe sich erkennen lässt, ob überhaupt die richtigen Tätigkeiten stattfinden oder ob gerade unnötig Geld und Zeit verbraucht werden. Wichtig ist dabei, dass sie im Zusammenhang mit den Durchlaufmetriken des ersten Teils gesehen werden können, und zwar sowohl für die Lead Time/Gesamtdurchlaufzeit als auch für ihre einzelnen Teilstrecken (dazu am Ende mehr).

Value Adding Time

Der Idealfall. In etwa als "Wertschöpfungszeit" übersetzbar sollte die Value Adding Time eigentlich den grössten Teil der Durchlaufzeiten ausmachen. Was dort geschieht kann je nach Art des Produkts oder der Dienstleitung sehr unterschiedlich sein, im Normalfall sind aber Tätigkeiten enthalten, die zur Erstellung, Vermarktung und Inbetriebnahme von Produkt oder Dienstleitung gehören, ggf. einschliesslich von Vorarbeiten wie dem Einkauf oder nachgelagerter Tätigkeiten wie dem Kundenservice. Die Wichtigkeit ergibt sich daraus, dass es im Wesentlichen diese Tätigkeiten sind, für die Kunden Geld bezahlen.

Transportation Time

Der erste zu vermeidende Typ und gleichzeitig ein alter Bekannter. Transporte sind eine der klassischen Mudas des Toyota Production System (TPS), also eine nicht gewinnbringende aber Ressourcen verbrauchende Tätigkeit. Je nachdem, in welchem Rahmen sie gemessen wird, kann auch die Transportation Time sehr unterschiedlich aussehen, angefangen vom Werkstoff-Transport zum anderen Ende der Firma bis zum Containerschiff, dass das Produkt rund um die Erde fahren muss. Eine weitere Variante wäre das langsame Herunterladen eines digitalen Produkts durch eine schlechte Telefonleitung.

Waiting Time

Ebenfalls eine Muda, und dazu die vielleicht die am weitesten verbreitete. Überall dort, wo die Menschen oder Maschinen mehr Arbeit zu erledigen haben als sie bewältigen können, werden sich Aufgaben aufstauen und auf ihre Erledigung warten, was in grossen Organisationen auch Monate und sogar Jahre dauern kann. Als Zusatzeffekt erzeugen Wartezeiten, sobald sie auftreten, noch weitere Aufwände, da die wartenden Aufgaben aktuell gehalten und ggf. verworfen, neu formuliert, neu verhandelt oder repriorisiert werden müssen.

Blocked-Time

Die Blocked Time wird häufig mit der Waiting Time verwechselt, hat aber eine andere Natur. Wartende Aufgaben könnte man selbst erledigen, wenn man denn die Zeit hätte. Geblockte Aufgaben müssen durch jemanden anderen erledigt werden, der dafür zuerst seine gegenwärtige Tätigkeit abschliessen und sich die Aufgabe erklären lassen muss (ggf. kommen noch Preisverhandlungen und Beauftragungen dazu). Besser wäre es, diese Tätigkeiten selbst erledigen zu können, wodurch die Blocked Time verschwinden würde.

Repair Time

Noch eine Muda. Wenn man Repair Time nicht als den Reparaturaufwand nach einem Unfall versteht, sondern als die Zeit die für die Behebung von Hardware-Produktionsfehlern und Software-Bugs nötig ist, ist klar, dass sie so gering wie möglich sein sollte. Auch hier kann es zu negativen Zusatzeffekten kommen, da auch Reklamationen und Umtausche Aufwände erzeugen und die mit den Reparaturen betrauten Menschen dadurch aus ihren aktuellen Tätigkeiten herausgerissen werden, mit Verlangsamungen durch Context Switching und Rüstzeiten als Folge.

Red Tape Time

Hinter der Red Tape Time verbirgt sich die letzte Muda dieser Übersicht, das Overprocessing. Red Tape ist im Englischen ein Sammelbegriff für unnötig komplizierte Prozesse und unnötig bürokratische Vorschriften, und wer bereits in grossen Organisationen gearbeitet hat wird wissen, dass sie dort weit verbreitet sind (hier ein besonders verstörendes Beispiel aus einer deutschen Behörde). Und dass derartige Tätigkeiten nichts zur Wertschöpfung beitragen dürfte ebenfalls offensichtlich sein.

Process Effectivity

Setzt man jetzt die Value Adding Time und die ressourcenverbrauchenden aber nicht wertschöpfenden Varianten Transportation Time, Waiting Time, Blocked Time, Repair Time und Red Tape Time in Verhältnis zueinander, erhält man die Prozess-Effektivität. Wenn die gesamte Durchlaufzeit nur aus Value Adding Time besteht ist das Ergebnis ideal, wenn die Zeit überwiegend für die anderen Typen verbraucht wird ist es eher schlecht. In diesen Fällen macht es sinn, den Prozess so zu verändern, dass diese Aufwände zurückgehen.

Bild: Flickr /  Brian Beggerly - CC BY 2.0

Manche Begriffe im Umfeld von Agile und Lean sind sich in ihrer Bedeutung so ähnlich, dass sie immer wieder verwechselt werden, selbst wenn es bei genauerem Hinsehen doch deutliche Unterschiede gibt. Zwei bei denen das immer wieder der Fall ist sind Waiting und Blocked, zwei Zustände die gemeinsam haben, dass nicht an einem Arbeitsgegenstand gearbeitet werden kann wenn er von ihnen betroffen ist. Die Gründe dahinter sind allerdings verschiedene.

Von Waiting (Wartend) ist die Rede wenn alle Fertigkeiten, Genehmigungen und Berechtigungen vorhanden sind die benötigt werden um mit der Umsetzung eines Arbeitspaketes zu beginnen, es aber nicht dazu kommt weil andere gerade wichtiger sind oder schon länger darauf warten, dass mit ihnen begonnen wird. Worauf diese Priorisierungs- und Reihenfolgen-Entscheidungen beruhen ist dabei unwichtig, wichtig ist nur, dass der Status Waiting auf einer selbst getroffenen Entscheidung beruht.

Der Status Blocked (Blockiert) ist dagegen gegeben wenn nicht mit der Umsetzung eines Arbeitspaketes begonnen werden kann weil externe Zulieferungen fehlen oder extern zu vergebende Genehmigungen oder Berechtigungen nicht vorliegen. Unabhängig davon woher diese Zulieferungen, Genehmigungen oder Berechtigungen kommen müssten ist wichtig, dass es sich dabei um eine aussenstehende Einheit handelt, der man nicht selber angehört.

Warum das von Bedeutung ist? Weil die dadurch notwendigen Massnahmen jeweils andere sind. Um Wartezeiten zu reduzieren kann man z.B. versuchen effizienter zu werden (nicht wertschöpfende Tätigkeiten zu unterlassen) oder effektiver zu werden (nur noch an relevanten Zielen zu arbeiten), alternativ kann man das eigene Team (und damit die eigene Arbeitskapazität) aufstocken. All das führt zu schnellerer Erledigung und weniger Warten.

Blockaden werden dagegen reduziert indem entweder die Einheiten von denen man abhängig ist optimiert oder reguliert werden (letzteres z.B. durch vereinbarte zeitliche Obergrenzen für Zulieferungen) oder indem der eigenen Einheit zu den Befähigungen, Genehmigungen oder Berechtigungen verholfen wird deren Fehlen vorher zu den äusseren Abhängigkeiten geführt hat. Um das gängige Schlagwort zu benutzen: das eigene Team muss crossfunktional werden.

Diese unterschiedliche Art der notwendigen Massnahmen macht es schliesslich nötig, dass diese beiden unterschiedlichen Verzögerungstypen auch unterschiedlich kenntlich gemacht und separat gezählt werden, wird das nicht getan ist unklar welches Problem vorliegt und welcher Lösungsweg gegangen werden sollte. Um es mit einem häufigen Antipattern zu erklären: wer auf allem was sich auf dem Board nicht bewegt ein Stopschild-Icon anbringt vermengt die beiden Typen und tut sich selbst keinen Gefallen.

Zielführender sind separate Markierungen, z.B. ein oranger Punkt für jeden Tag an dem ein Arbeitspaket im Status Waiting ist und ein roter Punkt für jeden Tag an dem es sich im Status Blocked befindet. Dadurch sind beide klar unterscheidbar und unterschiedlich behandelbar. Und wer eine Zeit lang so vorgegangen ist wird den Unterschied zwischen Waiting und Blocked so gut kennen, dass es zu keinen weiteren Verwechselungen mehr kommen kann.

Was sind eigentlich die im Lean Management verwendeten Metriken? Die darauf häufig gegebene Antwort ist Durchflussmessung, was auch grundsätzlich richtig ist (wenn auch nur ein Teil der Antwort). Allerdings gibt es mehr als eine Art davon, so dass sich eine Aufschlüsselung lohnt. Wichtig zum Verständnis ist dabei, dass es nirgendwo eine zentrale Stelle gibt, die die Begriffe und ihre Bedeutungen festlegt. Je nachdem wo man ist kann es also Unterschiede geben, die grundlegenden Typen werden aber die gleichen sein.

Customer Lead Time

Die Gesamtzeit zwischen der Beauftragung durch einen Kunden und dem Beginn der Nutzung des bestellten Produkts oder Service durch ihn. Eine der eher selten erhobenen Zahlen, aus Kundensicht aber eine der wichtigsten. Sie zu messen kann verhindern, dass zwar die internen Produktions- und Lieferprozesse optimiert sind, gleichzeitig aber unbemerkte Verzögerungs- und Frustrationsfaktoren bei beim Kunden vorliegen, z.B. ein kompliziertes Einloggen in Bestellportal oder ein langwieriger Schulungsprozess der Anwender.

Feedback Loop Time

Diese Zahl ist der ersten ähnlich, geht aber noch einen Schritt weiter. Gemessen wird nicht nur die Gesamtzeit zwischen der Beauftragung durch einen Kunden und dem Beginn der Nutzung des bestellten Produkts oder Service, sondern zusätzlich auch die Zeit die für eine erste Nutzung, das Sammeln von Feedback und dessen Übermittlung an den Produzenten nötig sind. Vereinfacht gesagt: erst nach dem ersten Feedback Loop weiss man, ob man dem Kunden h,elfen konnte.

(Production) Lead Time

Das ist die erste rein interne Metrik, und vermutlich auch die bekannteste. Erhoben wird die Gesamtdauer aller Vorgänge vom Auftragseingang bis zur Auslieferung. Grundsätzlich ist das zwar relativ einfach zu erheben, kompliziert wird es aber dann, wenn Zulieferer Hardware- oder Software-Komponenten vorfertigen, die dann nur noch eingebaut werden müssen. Die Bestellung, Erstellung und Lieferung dieser Komponenten muss ggf. in die Lead Time mit einbezogen werden.

Pre-Processing Lead Time / Processing Lead Time / Post Processing Lead Time

Bei diesen drei Typen wird die Lead Time in drei unterschiedliche Abschnitte unterteilt, die sich so fast überall wiederfinden und separat betrachtet werden können. Die Pre-Processing Lead Time umfasst alle Verhandlungs, Bestell- oder Beauftragungsprozesse, die Processing Lead Time ist die eigentliche Anfertigung inclusive Qualitätssicherung, die Post-Processing Lead Time umfasst die nachgelagerten Auslieferungs- und Rechnungsstellungs-Prozesse.

Cycle Time

Nach der Lead Time die vermutlich zweitbekannteste Metrik. Für ihre Erhebung werden die übergreifenden Abschnitte nochmal unterteilt, z.B. die Processing Lead Time in Vormontage, Endmontage und Qualitätssicherung. Diese Unterteilung kann u.a. deshalb Sinn machen, weil verschiedene Cycle Times parallel laufenden Prozessen entsprechen können (z.B. zwei verschiedenen Vormontagen), die aufeinander abgestimmt werden sollen.

Process Step Time

Die kleinste Einheit, die nur noch wenigen manuellen oder automatisierten Vorgangsschritten entspricht. In der Hardware-fertigenden Industrie wäre das z.B. eine Station am Fliessband, bei Software-Releases kann eine Build Pipeline-Station so gemessen werden. Wichtig bei der Process Step Time ist, dass sie v.A. bei repetitiven Tätigkeiten und Prozessen Sinn macht, nicht in der Wissensarbeit (z.B. in Journalismus und Softwareentwicklung), wo sie aufgrund fehlender Vergleichbarkeit kaum Aussagekraft hat.

Grafik: Pixabay / 5718714 - Lizenz

Die Idee sich auf ein einziges Ziel zu konzentrieren und focussiert daran zu arbeiten zieht sich durch zahlreiche Lean und Agile-Frameworks und findet sich u.a. in Sprint- und Produktzielen, im Single Piece-Flow, in OKRs oder in Work in Progress-Limits wieder. Wenn der Gegenstand dieser Focussierung ein schnell umsetzbares Arbeitspaket oder Nahziel ist kann man sich die Umsetzung auch gut vorstellen, aber wie würde das bei Fern- oder Dauerzielen gehen? Ein Ansatz sind die so genannten North Star Metrics.

Die dahinter stehende Idee ist es, eine einzige Messgrösse zu finden, die von so zentraler Bedeutung für die gesamte Organisation ist, dass ihre Optimierung Vorrang vor allem anderen hat. Das funktioniert natürlich nur dort, wo es ein klar umrissenes Geschäftsfeld gibt, das sich auf ein klar definertes Produkt (oder eine klar definierte Dienstleistung) ausrichtet, aber dort kann es ein interessanter Weg sein um focussiertes datengetriebenes Arbeiten zu ermöglichen.

Um Beispiele zu nennen: in Vermittlungsplattformen wie AirBnB oder MyHammer, die an jedem zustandegekommenen Geschäft mitverdienen, ist die Anzahl zustandegekommener Vermittlungen entscheidend. Lieferdienste wie die von Picnic und Rewe haben dagegen ein Interesse an möglichst grossen Warenkörben, um die Logistikkosten gering zu halten. Und für Social Networks wie Instagram und Twitter ist entscheidend wie viele Nutzer täglich durch Likes oder Shares interagieren.

Dort, wo derartige Zahlen den Nordstern bilden, an dem sich alles ausrichtet, kann eine ganze Reihe von Vorteilen genutzt werden. Zunächst helfen sie bei Investitionsentscheidungen: wenn es darum geht, wo ein zur Verfügung stehendes Optimierungs-Budget am besten eingesetzt werden sollte, können z.B. alle Einheiten oder Systeme nachrangig behandelt werden, die diese zentralen Werte nicht beeinflussen können. Und bei denen die es können kann überlegt werden wo die grösste Wirkung möglich ist

Sie helfen offensichtlicherweise auch bei der Erfolgsmessung. Bei jedem der weiter oben genannten Beispiele kann jederzeit überprüft werden ob die Zahlen stabil bleiben, zunehmen oder abnehmen. Und dadurch, dass sie schnell (ggf. sogar in Echtzeit) erhebbar sind ist auch ein schnelles Inspect & Adapt möglich wenn sie sich nicht so entwickeln wie gewünscht oder geplant. Auch eine wirtschaftliche Betrachtung kann stattfinden, indem man prüft wieviel welche Verbesserung gekostet hat.

Zuletzt können North Star Metrics intern wesentlich dazu beitragen, dass die Mitarbeiter die Ausrichtung des eigenen Unternehmens verstehen und ihre eigene Tätigkeit darauf ausrichten. Vor allem dort wo mit autonomen und agilen Teams gearbeitet wird, ist es kaum noch möglich, zentral zu steuern, woran im Tagesgeschäft gearbeitet wird, mit Hilfe des über allem schwebenden Leitsterns können die Teams aber selbst erkennen wie zielführend ihre Arbeit gerade ist.

Wie dieser Ansatz im jeweiligen Einzelfall umgesetzt wird kann (und muss) je nach Fall unterschiedlich sein, da auch die jeweiligen Unternehmen und Produkte unterschiedlich sind. Eine naheliegende Variante ist aber die Kombination mit OKRs. Es gibt auch Versuche ein eigenständiges North Star Framework zu entwickeln, das aber noch in seinen Anfängen steckt und wenig verbreitet ist. Vielleicht entwickelt sich aber hier noch etwas. Man sollte es im Auge behalten.

Es ist der Schlachtruf der DevOps-Bewegung: Automate all the Things!, ein Anspruch der in seiner radikalen Absolutheit oft von dem Hyperbole and Half-Meme unterstrichen wird. Nicht nur in Bezug auf DevOps sondern mittlerweile auch für die Agilität im Allgemeinen ist diese Haltung zu einem der zentralen Distinktionsmerkmale geworden, ohne sie wäre es vermutlich nicht zu der damit verbundenen Erfolgsgeschichte gekommen. Und doch - mittlerweile sollte man  das Ganze kritisch hinterfragen.

Zur Erinnerung, eigentlich ist Automatisierung in der agilen Produktentwicklung etwas Gutes. Manuelle Release-, (Regressions-)Test-, Dokumentations- und ähnliche Prozesse können schnell absurde Umfänge annehmen, in der Durchführung ewig dauern und gigantische Kontroll- und Koordinierungs-Bürokratien erzeugen. Da das jegliche Beweglichkeit und Reaktionsfähigkeit ersticken würde bleibt nur eines - automatisieren, im Wettlauf gegen die Zeit.

Was im Rahmen dieses Vorgehens aus dem Blick geraten kann ist aber, dass die Automatisierung auch im wahrsten Sinn des Wortes Schattenseiten hat. Nicht umsonst wird sie im Deutschen auch als Dunkelverarbeitung bezeichnet, sobald Prozesse einmal selbstständig ablaufen sind sie vor dem menschlichen Auge verborgen (zumindest in der IT, wo Automatisierung fast immer Digitalisierung bedeutet, unter Umständen sogar irgendwo in der Cloud statt in den eigenen Systemen).

Bedingt dadurch kann es vorkommen, dass Informationen gar nicht mehr auffallen (oder erst dann wenn es zu spät ist). Eines der häufigsten Beispiele dafür sind Burndown-Charts. Dort wo sie manuell an der Wand erstellt werden ist es für ein Team schon früh sichtbar ob es Fortschritte macht oder ob es sich festgefahren hat, dort wo sie automatisiert erstellt werden (z.B. auf einer versteckten Web-Seite in Jira) werden sie oft nur zum Sprintende angeschaut, schlimmstenfalls nie.

Selbst wenn sie sichtbar angezeigt werden, können wichtige Informationen aber übersehen werden. Auch hier gibt es ein häufiges Beispiel: die Summe der Punkte auf den Tickets, die anzeigen seit wann sich hier nichts mehr bewegt hat. Dort wo sie automatisiert hochgezählt werden treten oft schnell Abstumpfungs-Effekte ein, dort wo sie manuell hinzugefügt werden entsteht eine bewusstere Beschäftigung mit dem Thema, die häufiger zu Korrekturmassnahmen führt.

Nicht zu unterschätzen ist auch der Effekt der eintritt wenn die Beschäftigung mit den eigenen Prozessen zu einem Standard-Bestandteil von Regelmeetings wird. Das kann etwa im Rahmen von Reviews oder Retrospektiven stattfinden, es können aber auch eigene Termine dafür geschaffen werden, z.B. solche in denen man gemeinsam die eigenen technischen und organisatorischen Schulden begutachtet. Das Ergebnis ist eine Verankerung der Themen im kollektiven Gedächtnis der Organisation.

Um langsam zum Schluss zu kommen - heisst das, dass man die Prozessautomatisierung doch wieder seinlassen soll? Natürlich nicht, und die bisher genannten Beispiele verleiten auch nicht dazu. Repetitive Tätigkeiten sollen (bzw. müssen) weiterhin automatisiert werden wenn Agilität das Ziel ist, das bleibt unverändert. Eine "Ent-Automatisierung" lohnt sich aber trotzdem, vor allem bei vielen Datenerhebungen, um so Probleme offensichtlich zu machen und Lösungsfindungen anzustossen.

Bild: Wikimedia Commons / James Petts - CC BY-SA 2.0

Eigentlich sollte es gar nicht so schwer sein herauszufinden mit welchen Metriken sich der Erfolg einer agilen Transition validieren lässt. Einige davon hatte ich schon einmal aufgeschrieben, unter anderem kämen da Time to Market, Feedback Implementation Time, (Mean)Time to Recovery und Time to Process Adaption in Frage. Eine häufige Sorge ist dabei aber, dass sie alle dazu führen können, dass alle Erwartungen und Verantwortungen nur auf die unteren Hierarchieebenen abgewälzt werden.

Aufbauend darauf stellt sich die Frage, was für weitere Metriken es geben kann, an denen sich auch das Management messen lassen könnte. Ausgehend davon, dass es in der agilen Zielwelt unter anderem für die richtigen Rahmenbedingungen um möglichst autonome Teams zuständig sein wird wäre dieser Bereich ein naheliegender Ansatz. Und auch für diese Zielzustands-Rahmenbedingungen gibts bereits Definitionen: flache Hierarchien, wenige organisatorische Silos, möglichst wenige Abhängigkeiten.

Bevor das operationalisiert wird aber noch eine letzte Vorbemerkung. Da jeder Einzelfall immer einzigartig ist und da eine agile Zielorganisationen hohe Grenzwerte zulassen kann und muss sollte es sich bei allen folgenden Metriken um die Durchschnittszahlen der gesamten Organisation handeln. Dadurch bleiben Ausnahmen noch immer möglich, es kann aber nicht dazu kommen, dass sie zur Regel werden. Und jetzt in medias res, hier sind Ideen für die alternativen Transitions-Metriken:

I. Anzahl der Menschen die einem Product Owner eine Entscheidung untersagen können

Dass diese Zahl bei Null liegen könnte werden zwar nur Scrum-Fundamentalisten glauben, wie hoch sie im Ist-Zustand fast jeder grösseren Firma ist, ist aber selbst für deren Angehörige immer wieder erschreckend. Vorstände gehören dazu, verschiedene Bereichs-, Abteilungs-, Initiativen-, Programm- und Projektleiter, dazu meistens Fachabteilungs-, Produkt- und sonstige Manager sowie Angehörige der Vertriebs-, Anforderungsmanagement-, Rechts-, Datenschutz- und Compliance-Abteilungen. In Summe kommt so schnell eine mittlere zweistellige Personenzahl zusammen, die entweder Sitz in Lenkungs-Gremien oder Vetorecht hat. Ein gutes Transitionsziel kann sein, diese Zahl einstellig werden zu lassen.

II. Anzahl der Menschen die einem Team die Art der Umsetzung vorschreiben können

Auf den ersten Blick ein ähnlicher Fall, nur mit anderen Beteiligten, auf den zweiten mehr. Zu den disziplinarischen Vorgesetzten kommen hier die Architekten, Lead Developer, Test-, Release-, Integrations- und sonstigen IT-Manager, dazu aber auch andere Angehörige der unteren Hierarchie-Ebenen. Wenn andere Teams die selben Services und Komponeneten benutzen ist es schliesslich nur natürlich, dass sie Entscheidungen widersprechen dürfen von denen sie betroffen sind. Ein Transitionsziel auch diese Zahl einstellig werden zu lassen muss daher nicht nur zur Entflechtung von Mitspracherechten führen sondern auch zur Entflechtung von IT-Systemen.

III. Anzahl der organisatorischen Einheiten die beteiligt sein müssen um ein crossfunktionales Team zu bilden

Auch hier gilt: selbst für die Angehörigen grosser Firmen ist immer wieder erschreckend wie gross diese Zahl sein kann wenn End to End-Verantwortung erreicht werden soll. Der PO hängt im Produkt-, der Scrum Master im Projektmanagement, Entwickler in der Entwicklung, Tester in der QA, UXler, Release-Manager und Business Analysten können eigene Abteilungen haben und der Produktions-Betrieb wird oft sogar von eigenen Gesellschaften verantwortet. Alleine um das Customer-Vendor Antipattern zu vermeiden macht es Sinn hier die Zahl zu reduzieren. Das ideale Transitionsziel wäre eine Eins, aber auch eine niedrige einstellige Zahl wäre fast überall eine Verbesserung.

IV. Anzahl der Teams denen ein durchschnittlicher Mitarbeiter der Ausführungsebene gleichzeitig angehört

Ein Phänomen das häufig gemeinsam mit einem funktionalen Abteilungsschnitt auftritt ist die gleichzeitige Zugehörigkeit einzelner Personen zu mehreren Teams, z.B. wenn sich zwei UX-Designer auf mehr als zwei Projekte aufteilen müssen. Die dadurch entstehenden negativen Effekte (Terminkonflikte, Kontext-Wechsel, etc.) sind zwar bekannt, trotzdem sind in grossen Organisationen fünf bis zehn gleichzeitige Mitgliedschaften nicht ungewöhnlich. Da manche Hochspezialisierungen kaum vermeidbar sind (z.B. Juristen oder Penetrationstester) ist ein Transitionsziel von Eins zwar wenig realistisch, ein Durchschnittswert zwischen Eins und Zwei kann aber angestrebt werden.

V. Anzahl der Genehmigungsschritte die ein Team durchlaufen muss um mit einem Endkunden reden zu können

Auch hier kann mehr dahinterstecken als man zunächst ahnt. Das erste und offensichtlichste Hindernis sind natürlich andere Einheiten die bisher das Monopol auf den Endkundenkontakt hatten (häufig Vertrieb, Marketing und/oder Kundendienst), dazu kommt aber auch, dass in der Budgetierung von Entwicklungsteams meistens kein Posten für Kunden-Gespräche vorgesehen ist, bzw. dass dieser aufwändig beantragt und genehmigt werden muss. Ein gutes Transitionsziel in diesem Bereich wäre die Zahl Null, was in der Umsetzung nicht nur zum Abbau von Kommunikationsbarrieren führen würde sondern auch zum Ende von Micromanagement-Versuchen über das Budget.

VI. Anzahl der Genehmigungsschritte die ein Team durchlaufen muss um alle (!) Zahlen zum eigenen Produkt zu erhalten

Apropos Budget. Vor allem Finanz-Zahlen, aber auch Absatzmengen und Nutzungsdaten sind in vielen Firmen für die Entwicklungsteams gar nicht oder nur erschwert zugänglich. Wie aber soll ein Team Intrapreneurship (wirtschaftliches Denken und Handeln) eintwickeln wenn ihm weder bewusst ist welche Kosten es verursacht noch welche Umsätze und Gewinne es erwirtschaftet? Auch hier ist das ideale Transitionsziel die Zahl Null, aber selbst eine Reduzierung auf den niedrigen einstelligen Bereich würde fast überall ein deutliches Mehr an Transparenz und deutlich weniger Herrschaftswissen bedeuten.

Wie oben gesagt, das Erheben und gezielte Senken derartiger Zahlen kann ein wirkungsvoller Weg sein um zu verhindern, dass die Änderungs-Aufwände (bewusst oder unbewusst) ausschliesslich auf die Teamebene gewälzt werden. Wer so vorgeht kommt am Verändern der Rahmenbedingungen nicht vorbei - und das ist auch gut so, denn ohne das haben nur die wenigsten Transitionen eine wirkliche Aussicht auf Erfolg.

Bilder: Pixabay / Valentin Tixonov / Alpcem - Lizenz

Wenn sich Organisationen auf die Reise in Richtung Agilität begeben ist es fast zwangsläufig, dass sie früher oder später mit der Fragestellung konfrontiert werden wie disruptiv dieser Wandel sein soll. Sollen wenige, tiefgreifende Änderungen in kurzer Zeit durchgeführt werden oder machen viele kleine. über längere Zeit gestreckte Anpassungen mehr Sinn?

Die auf den ersten Blick unbefriedigende Antwort lautet, dass beides richtig ist, je nach Kontext. Das ist zwar zutreffend, hilft aber nicht wirklich weiter und muss daher konkretisiert werden. Ein Ansatz mit dem man dabei arbeiten kann (einer von vielen, es gibt hier keine absolute Wahrheit) trägt den poetischen Namen "The Hammer and the Dance". Er kann tatsächlich helfen, allerdings bedarf es zuvor einiger kurzer Erläuterungen.

Ein stark disruptiver (revolutionärer) Ansatz besteht aus starken Umwälzungen. Organisatorische und personelle Umstrukturierungen gehören dazu, auch Intensiv-Trainings aller Mitarbeiter oder Verkauf/Abschaffung und Neukauf/Neubau von Anlagen, Systemen und Gebäuden. Der Vorteil an diesem Vorgehen ist, dass in kurzer Zeit viel bewegt werden kann, der Nachteil, dass bei den davon Betroffenen Ängste und Widerstände ausgelöst werden können.

Ein wenig disruptiver (evolutionärer) Ansatz besteht dagegen aus einem behutsamen, schrittweisen, einladungs-basierten Veränderungsprozess, der sich auf kleine und überschaubare (Teil-)Schritte konzentriert und von denen auch nicht zu viele gleichzeitig stattfinden lässt. Die Ergebnisse können die selben sein wie beim stark disruptiven Ansatz, die Ängste und Widerstände sind aber erfahrungsgemäss deutlich geringer. Der Nachteil ist, dass dafür viel Zeit nötig sein kann, was in dringlichen Situationen ein Problem ist.

Der Hammer and Dance-Ansatz versucht Beides zu verbinden. Entwickelt im Jahr 2020 zur Bekämpfung der Covid19-Pandemie geht er davon aus, dass es sinnvoll ist abwechselnde Phasen starker und behutsamer Eingriffe zu haben, die er als "Hammer" und "Tanz" bezeichnet. Welche dieser Vorgehensweisen als nächstes angewandt wird muss dabei von der aktuellen Situation abhängen (mehr zu Hammer and Dance in der Covid19-Bekämpfung hier und hier).

Aus Sicht eines "Agilisten" ist dieses Vorgehensmodell vor allem deshalb naheliegend weil es evidenzbasiert ist. Im ursprünglichen Kontext der Pandemiebekämpfung bedeutet das (vereinfacht gesagt), dass das Überschreiten bestimmter Infektions-Grenzwerte zu starken Eingriffen führt, die dann wieder zu behutsamen Eingriffen zurückgefahren werden wenn die Grenzwerte wieder unterschritten werden und über einen definierten Zeitraum niedrig bleiben.

Um eine Übertragung auf den Kontext einer agilen Transition vorzunehmen müsste damnach in einem ersten Schritt definiert werden welches die relevanten Werte sind die gemessen werden sollen. Das können die klassischen Zahlen aus datengetriebenen Retrospektiven sein, wie Lead Time, Cycle Time, Durchsatz, WIP-Menge oder Bug-Rate, aber auch Devops-Metriken wie Deployment Frequency, Recovery Time, Automation Rate oder System Availability.

In einem zweiten Schritt sollten die jeweiligen Grenzwerte definiert werden. Wichtig ist dabei, dass diese keinen Idealzustand darstellen dürfen. Auch unterhalb der Grenzwerte kann (und und darf) es zu suboptimalen Metriken kommen, allerdings sollte das mit kleinen, dezentralen Massnahmen behebbar sein, etwa mit Training on the Job oder durch allmähliches Refactoring nur der Systemkomponenten an denen gerade ohnehin gearbeitet wird.

In dieser Vorgehenslogik werden am Anfang der meisten agilen Transitionen einige grosse Massnahmen stehen. Wenn sich zwischen den organisatorischen Silos die Arbeit staut müssen diese neu zugeschnitten oder zusammengelegt werden, wenn Systeme ständig ausfallen muss Zeit in ihre Stabilisierung investiert werden, zu viele parallele Arbeit kann durch die Begrenzung gleichzeitig begonnener Projekte und Initiativen zurückgefahren werden, etc.

Sobald durch diese Massnahmen ein Unterschreiten der Grenzwerte stattgefunden hat kann die Verantwortung für das weitere Vorgehen dezentralisiert und auf die unteren Organisationsebenen verlagert werden. Welche der im vorletzten Absatz genannten (oder anderen) Massnahmen dort ergriffen werden sollte in der Verantwortung des jeweiligen Einheit bleiben - bis die Grenzwerte nicht wieder nach oben überschritten werden, dann müssen erneut stärkere Massnahmen erwogen werden.

Neben der Evidenzbasierung hat das Hammer and Dance-Modell noch weitere Aspekte die zu einem agilen Zielbild passen, als wichtigste seien hier die Subsidiarität und das kontinuierliche Inspect & Adapt genannt. Zu den Risiken gehört, dass in den Hammer-Phasen Selbstorganisations-Strukturen beschädigt werden und die Grenzwerte zum Setzen unrealistischer "ambitionierter Ziele" genutzt werden können. Solange die Ziele der Transformation klar formuliert sind kann man daran aber arbeiten

Zuletzt noch eine Frage die vielleicht dem einen oder anderen Leser im Kopf herumschwirrt: ist "The Hammer and the Dance" denn wirklich in irgendeinem Transformationsvorhaben im Einsatz? Die Antwort: ja, ist es. Zwar nicht unter diesem Namen, nicht immer mit der nötigen Klarheit und nicht mit explizitem Bezug auf das 2020 entwickelte Pandemiebekämpfungs-Modell, aber die Art des Vorgehens findet man immer wieder. Vielleicht wäre es Zeit ihm zur besseren Kommunizierbarkeit einen Namen zu geben. Warum nicht diesen?

Bild: Piqsels - Lizenz

Lead Time

Cycle Time

Bild: Pexels / Lukas - Lizenz

Cycle Time

Lead Time

Throughput

Velocity

Work in Progress

WIP-Age

Blocked Days/Hours

Bug Rate/Incident Rate

Bugfix Time