On Lean and Agility

Für den Fall, dass es im eigenen Unternehmen gerade nicht aufregend genug ist - eine der sichersten Möglichkeiten das zu ändern ist, sich jemanden aus der IT-Abteilung (oder aus einer Abteilung, die die IT beauftragt) zu suchen und mit ihm oder ihr ein Gespräch zum Thema Entwickler-Produktivität zu beginnen. Was das ist, ob sie in ausreichendem Ausmass vorhanden ist und wie man sie messen kann. So lässt sich schnell Stimmung in die Firma bringen.

Aber Scherz beiseite, das Thema ist tatsächlich ein Klassiker. Und dass es seit Jahrzehnten in zahllosen Unternehmen immer wieder diskutiert wird, zeigt, dass bei ihm noch grundlegende Fragen ungeklärt sind - zum Beispiel, was das überhaupt ist, Entwickler-Produktivität. Eine allgemein anerkannte Definition gibt es bis heute nicht, und die existierenden Definitionsversuche haben alle ihre Schwächen. Daher zunächst ein Überblick: welche Versuche gibt es, Entwickler-Produktivität zu definieren?

I. Code-Output

Aus klassischer Management-Sicht der naheliegendste Ansatz. Wie viele Zeilen Code wurden in welcher Zeit geschrieben? Das ist einfach verständlich, gut messbar - und völlig unsinnig. Warum, habe ich hier aufgeschrieben. Eigentlich war das auch bereits allgemein anerkannt, seit dem Aufkommen von KI in der Softwareentwicklung hat die Zählung von Code-Zeilen (die auf einmal so schnell erzeugt werden können wie nie) aber ein unerwartetes und unschönes Revival erlebt.

II. Increment-Output

Schon besser als der erste Ansatz. Die Zählung von Incrementen (entwickelten, getesteten, integrierten und deployeten Features) geht mehr in Richtung der Zählung nutzbarer Funktionalitäten, und wird u.a, von McKinsey empfohlen. Schwierig dabei ist, dass es selbst in dem selben System massive Unterschiede beim Erstellungsaufwand verschiedener Incremente geben kann. Und das ist etwas, was auch über die Zeit nicht besser wird (bei Systemen mit geringer Degradability sogar eher schlechter).

III. Story Points (oder vergleichbare Werte)

Die vermutlich am weitesten verbreitete Metrik in agilen Entwicklungsteams, vor allem in Extreme Programming, Scrum und SAFe. Das Problem: wenn sie so benutzt werden wie ursprünglich gedacht, entsprechen sie keinen Zeiteinheiten und lassen sich nur rückwirkend und im langfristigen Durchschnitt auf solche umrechnen. Das Vorgeben einer festen Umrechnung in Zeit ist zwar möglich, beseitigt aber die Vorteile, wegen denen Story Points überhaupt erfunden wurden (siehe hier).

IV. Output-Flussmetriken

Die klassischen Lean-Metriken. Gemessen wird nicht mehr wie viele Arbeitspakete fertig werden, sondern wie lange die Fertigstellung im Schnitt braucht, ob von der Idee bis zum Endabnehmer (Lead Time) oder auf Teilstrecken dazwischen (Cycle Time). Je kürzer, desto besser. Wird auf Systemebene optimiert, etwa durch Abbau von Flaschenhälsen zwischen Anforderungsmanagement und Entwicklung, bessere Übergaben, etc. Daher auch eine System-Metrik, nicht nur eine auf Entwickler-Ebene. 

V. Outcome-Flussmetriken

Ähnlich wie der letzte Metriken-Typ, aber mit einem klareren Focus auf der Durchschnittszeit bis zur Erzielung eines angestrebten Geschäftswertes. Klassiker sind die Time to Market und die Feedback Loop Time, möglich sind aber auch andere, etwa die Durchführungsdauer eines A/B-Tests oder die Zeit bis zur Skalierung auf 10.000 Nutzer. Da daran neben den Entwicklern auch Produktmanagement, Marketing und andere Einheiten beteiligt sind, ebenfalls eher eine Metrik für das Gesamtsystem.

VI. Qualitäts-Metriken

Wieder eine reine Entwickler-Metrik. Kann sowohl unmittelbare Qualitätsmessungen enthalten (z.B. die Bug Rate oder Incident Rate) als auch Messungen der Qualitätssicherung (z.B. der Testabdeckung oder des Live-Monitorings). Anders als man zunächst denken könnte ein durchaus zweischneidiges Schwert, da hohe Qualitätsstandards zu unverhältnismässigen Aufwänden für die Durchführung von Experimenten oder die Erstellung von Prototypen und MVPs führen können.

VII. Betriebswirtschaftliche Metriken

Damit kann man die Augen vieler Controller zum Glänzen bringen. Return on Investment, Cost of Delay, Ressourcenaufwand pro Feature (z.B. in Form von Token-Verbrauch) oder Höhe von Betriebs- und Wartungskosten versprechen eine Steuerbarkeit anhand von Business Value, allerdings sind auch diese Zahlen sowohl stark vom jeweiligen System abhängig (siehen oben, Degradability) als auch von der Arbeit von verschiedenen Nicht-Entwicklungseinheiten wie Marketing oder Vertrieb.

VIII. Auslastungs-Metriken

Wieder ein Klassiker, aber diesesmal einer, der verheerende Auswirkungen haben kann. Jede Arbeitsstunde mit Tätigkeiten zu verplanen mag wie ein guter Weg zu hoher Produktivität erscheinen, da dadurch Leerlauf vermieden wird, allerdings reicht dann eine einzige Verzögerung aus um einen Domino-Effekt zu erzeugen, der alles nach hinten verschiebt (siehe hier). Und dazu kommen noch die Zusatzaufwände durch Umplanung, Informationsverteilung, Triage, Eskalation, etc.

IX. Kombinierte / gewichtete Metriken

Naheliegenderweise gibt es Versuche, mehrere Metriken zu verbinden oder miteinander zu verrechnen. Bekannt sind vor allem WSJF (Cost of Delay geteilt durch Durchlaufzeit) und das von McKinsey popularisierte inner Loop / outer Loop, das Entwicklungs- und Abstimmungs-Ergebnisse ins Verhältnis zueinander setzt. Das Problem daran ist, das sie leicht zu mechanistischen oder über-vereinfachten Betrachtungen komplexer Systeme führen können, die der Realität nicht mehr gerecht werden.

***

Was man an all diesen Versuchen, Entwickler-Produktivität zu messen, merken kann, ist, dass man bei ihrer Anwendung relativ schnell auf Probleme stösst. Zum Teil (v.A. bei Output- und Qualitätsmetriken) können versehentlich falsche Anreize gesetzt werden, zum Teil (bei Outcome- und Betriebswirtschafts-Metriken) lässt sich nur die Produktivität einer Gesamt-Organisation messen, nicht hingegen die von einzelnen Teilbereichen wie der Software-Entwicklung.

Bedingt dadurch führt der Wunsch, Entwickler-Produktivität zu messen meistens in einen nicht auflösbaren Konflikt. Auf der einen Seite stehen dabei Management und Controlling, die ein berechtigtes Interesse daran haben, die eigene Produktivität empirisch nachvollziehbar und auf Datenbasis optimierbar zu machen, auf der anderen Seite die Entwickler, die ebenfalls zu Recht anmerken, dass das durch die Erhebung und Auswertung von Metriken nur sehr eingeschränkt möglich ist.

Am Ende kann in genau diesem Konflikt aber auch die Lösung liegen. Wenn es gelingt, ihn sachlich, fallbezogen und lösungsorientiert auszutragen, kann das zu Produktivitätsmessungen führen, die dem jeweils einzelnen Fall eher gerecht werden als eine Einheitslösung, die in jedem Fall zwar zum Teil passend, zum Teil aber auch unpassend ist. Man hat dann nicht mehr ein zentrales Dashboard für alle IT-Teams, dafür aber das Potential für echte Verbesserungen. Und darum geht es doch eigentlich.

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.