Verzögerungskosten aufdecken erhöht die Produktivität

#JAVAPRO #Agile #Wertstromanalyse ||

„Wie kommt ein Projekt ein Jahr in Verzug? Ein Tag nach dem anderen.“ Das hat Fred Brooks einmal so weise gesagt. Der Lean-Gedanke und die Warteschlangentheorie bieten das Wissen an, um dieses Problem zu vermeiden. Die vorgeschlagene Abhilfemaßnahme ist, für einen ständigen Durchfluss (auch in der Entwicklung) zu sorgen, um die maximale Produktivität zu erreichen. Allerdings ist für die meisten Teams und Firmen dieses Ziel in weiter Ferne. In diesem Artikel werden Werkzeuge und Methoden angeboten, um die versteckten Verzögerungskosten aufzudecken.

Kontext und Fallbeispiel

Felix ist Projektleiter und hat vor wenigen Wochen das Projekt von Mirko übernommen. Mirko wurde nicht mehr zugetraut das Projekt rechtzeitig zu Ende zu bringen. Felix Vorgesetzte hatte ihre Erwartungshaltung eindeutig zum Ausdruck gebracht: „Das Team muss effizienter werden. Ich dachte mit der agilen Vorgehensweise würden wir alle Projekte frühzeitig fertig stellen können, aber mir scheint das Gegenteil ist der Fall.“ Natürlich war allen (insgeheim) klar, dass auch vor der Umstellung auf Agilität die Projekte nicht unbedingt alle in der Zeit und im Budget fertiggestellt wurden, aber genau das erhofften sie sich jetzt. Wobei leider auch die Lernkurve für die neue Vorgehensweise unberücksichtigt blieb. Wie auch immer, es nutzte ja nichts, erst mal musste Felix sich einen Überblick darüber verschaffen, wo die Zeit überhaupt verloren ging. Außerdem wollte er insofern eine Basis schaffen, dass er in der Lage war zu beurteilen ob diverse Änderungen überhaupt einen positiven Effekt haben.

In einer Retrospektive mit dem Team, in welcher sie gemeinsam einerseits analysierten, wo die hauptsächlichen Hindernisse liegen, als auch was sie wie messen wollten und andererseits beschlossen, welche Änderungen sie einleiten wollten. Dabei leiteten sie die folgenden Hindernisse ab:

• Oft wurden Stories nicht fertig, da die Tester Kim und Sascha nicht nachkommen.
• Thomas ist auch oft überlastet, da er das Hauptwissen über die Datenbank hat.
• Senior Entwicklerin Lara und Product-Owner Sven sind sich trotz etablierter Definition-of-Done oft uneinig darüber ob eine Story jetzt fertig ist oder nicht.

Messen wollten sie jetzt direkt:

Durchschnittliche Durchlaufzeiten: Wie lange benötigt es im Schnitt eine Story fertigzustellen? Dies kann auch auf dem Taskboard (oder Sprint-Backlog) verfolgt werden, d.h. wie lange dauert es bis eine Story von ToDo nach Done gewandert ist.

Änderungen, die sie im nächsten Sprint einleiten wollten:

• Aufgrund des Problems, dass Kim, Sascha (die beiden Tester) und auch Thomas (der Datenbankexperte) immer wieder überlastet sind, wollten sie versuchen sich als Team besser gegenseitig zu unterstützen.
• Lara und Sven wollten die Definition-of-Done nochmals überprüfen und sie dann auch mit dem gesamten Team verifizieren.

Im Gespräch mit Mirko, dem ehemaligen Projektleiter fand Felix weiterhin heraus, dass vor allem zu Beginn viel Zeit verloren gegangen war, bis das Team überhaupt erst mal anfing die ersten Stories zu entwickeln. Das Team hatte in dieser Zeit Mirko wiederholt erklärt, dass sie unbedingt mittels eines sogenannten Sprint-Zero erst noch den Boden bereiten müssten. Außerdem, so Mirko, sei vorab sehr viel Zeit verloren gegangen, bis überhaupt das Backlog gefüllt werden konnte. Felix beschloss diesen Aussagen nachzugehen und auf alle Fälle in den nächsten Projekten, in welchen er vielleicht die Chance erhalten sollte von Anfang an dabei zu sein, diese Dinge im Auge zu behalten. Er wollte sich dafür wappnen indem er auch für das laufende Projekt folgendes näher untersuchen wollte.

Wertstromanalyse: Welche Schritte / Prozesse / Aktivitäten wurden unternommen, bevor das Projekt zum Entwicklungsstart an das Team übergeben wurde. Diese wollte er außerdem auch auf den aktuellen Zustand untersuchen, in dem er überprüfen wollte, wie lange es eigentlich dauert bis Sven, dem Product Owner (kurz: PO) eine Story zur Einplanung ins Backlog übergeben wurde, bzw. bis er überhaupt das Ok erhalten hatte bei einem bestimmten Wunsch zu untersuchen, welche Stories sich dahinter verbergen.

Durchschnittliche Durchlaufzeit

Als allererstes versuchte Felix mit allen Beteiligten herauszufinden, wie lange es im Schnitt dauert bis eine eingeplante Story tatsächlich fertig ist. Die Voraussetzungen dafür waren da. Das Team plante sowieso alle Stories anhand eines Boards, das im Teamraum hing. Dort wurden für alle Stories des aktuellen Sprints, die Aufgaben (Tasks) priorisiert dargestellt. Diese Tasks wiederum durchlaufen verschiedene Status: Nämlich erst sind sie eingeplant (ToDo), dann wird an den Tasks gearbeitet (in Progress), wenn diese Entwicklung abgeschlossen ist wandert der jeweilige Task zur Verifizierung (to-be-reviewed), dort werden meist alle Tasks einer Story gesammelt, um dann die Story als Ganzes zu verifizieren und abzunehmen. Damit landen dann letztendlich sowohl die Story als auch die zugehörigen Tasks in der Spalte
Fertig (Done).

Kim machte den Vorschlag einfach zu jeder eingeplanten Story das Datum der Einplanung zu notieren und entsprechend dann auch das Datum der Fertigstellung. Am Ende des Sprints sollten dann die Anzahl der Tage, die von der Einplanung bis Fertigstellung vergangen waren, berechnet und in ein Chart eingetragen werden. Allen war bewusst, dass sich eine wirkliche durchschnittliche Zeit nur über mehrere Sprints ermitteln lassen würde. Aber sie konnten dennoch mit ihren Berechnungen loslegen und die Durchschnittszeit dann über die Zeit korrigieren.

Die Kenntnis über die durchschnittliche Durchlaufzeit ermöglicht schnellere Aussagen zur Umsetzung neuer Features, d.h. die Planung wird vereinfacht. Für Felix bedeutet dies auch, dass er einfacher messen kann, ob sie die Deadline halten können oder nicht. Darüber hinaus kann das Team mithilfe dieses Wissens herausfinden, inwiefern andere Änderungen eine positive oder auch negative Auswirkung auf die Entwicklungsgeschwindigkeit haben. Außerdem wird damit sehr deutlich ob das Team auch Probleme damit hat, Dinge anzufangen aber nicht fertigzustellen. Dies wird vor allem durch eingeplante und angefangene, aber auch über mehrere Sprints nicht fertiggestellte Stories deutlich. Falls sich dies herausstellt, gilt es sich auf wenige Stories zu konzentrieren und am besten eine nach der anderen gemeinsam fertig zu stellen, anstatt so viele wie möglich in einem Sprint zu beginnen – mit der Gefahr, dass nachher keine fertiggestellt wird. Auch die Stories kleiner zu schneiden trägt dazu bei, dass Stories sich nicht so lange in der Entwicklung, sprich in Progress befinden.

Wertstromanalyse

Felix wollte aber nicht nur wissen wie viel Zeit durchschnittlich für die Erstellung eines Features benötigt wird, sondern auch wo die Zeit bleibt. Um dies herauszufinden, analysierte er den Wertstrom. Dafür versetzte er sich in eine Anforderung die vom Kunden, vom Markt hereinkam und verfolgte, was mit der Anforderung passiert bis sie letztendlich auf dem Markt verfügbar war. Dabei ging es ihm darum, folgendes ausfindig zu machen:

• Arbeitsschritte, die unnötig sind,
• Wartezeiten zwischen Arbeitsschritten, die entweder unnötig sind oder reduziert werden können und
• Arbeitsschritte, die beschleunigt werden können.

Felix war es dabei wichtig, nicht nur einen bestimmten Bereich, wie z.B. die Entwicklung zu untersuchen, sondern eine ganzheitliche Betrachtung anzustellen. Die Zeiten in der Entwicklung ließen sich relativ einfach messen, da ab der Einplanung in einem Sprint alles nachvollziehbar am Taskboard war. Er musste nur sicherstellen, dass auf den Tasks die Zeiten notiert wurden. D.h., das war eine Erweiterung der Messung der durchschnittlichen Durchlaufzeit, da jetzt nicht nur darauf geachtet wurde wie lange etwas von ToDo bis Done braucht, sondern auch wie lange es in einem einzelnen Status ist, z.B. in to-be-reviewed.

Schwieriger war es herauszufinden, welche Arbeitsschritte wie lange ausgeführt wurden, bevor eine Anforderung bzw. ein Marktwunsch überhaupt beim Team landeten. Der PO Sven konnte da einige erste Antworten liefern und vor allem auch an weitere Personen verweisen. Dabei wurde deutlich, dass es vor allem recht große Wartezeiten gab, bis es überhaupt zur Verabschiedung (Approval) kam. Felix nahm daraus auch mit, dass er bei seinem nächsten Projekt insbesondere auch am Anfang ein Augenmerk darauf haben wird, dass ein Großteil der Projektzeit nicht verschwendet wird, bevor das Team überhaupt mit der Entwicklung beginnt. Für das jetzige Projekt bedeutete das vor
allem für eine Beschleunigung der Aufnahme von neuen und geänderten Funktionalitäten zu sorgen.

Verzögerungskosten durch Experten

Als das Team die Wertstromanalyse der Entwicklung bei der nächsten Retrospektive genauer betrachtete, wurde nochmals deutlich, welche negativen Auswirkungen die Überlastung, oder auch ungleichmäßige Auslastung, von den Testern Kim und Sascha sowie auch vom Datenbankexperten Thomas hatte. Und diese Auswirkungen hatten sie, obwohl sie sich für den Sprint vorgenommen hatten besser zusammen zu arbeiten. Als Sven das feststellte, fiel ihm ein was er über die Warteschlangentheorie wusste. Er machte das dem Team anhand folgender Analogie deutlich:

„Wenn ihr im Supermarkt einkauft und euch an eine Kasse anstellt, überlegt ihr euch vorher an welcher Kasse es wohl am schnellsten voran geht. Üblicherweise wählt ihr die kürzeste Schlange und eventuell wägt ihr noch ab, an welcher Schlange eher Leute mit vielen und an welcher diejenigen mit wenigen Einkäufen stehen. Aber nahezu egal wo ihr euch anstellt, (fast) immer habt ihr den Eindruck die falsche Wahl getroffen zu haben – weil genau in eurer Schlange jemand vergessen hatte das Gemüse zu wiegen oder Mühe hat, das Kleingeld zusammen zu suchen. Im Vergleich dazu funktioniert das bei der Post (heutzutage) wesentlich befriedigender: Es gibt eine einzige Schlange und der Schalter, der mit einem Kunden fertig ist, bedient den nächsten Kunden. Auf den ersten Blick erscheint die Schlange zwar lange, aber es geht dann immer erstaunlich zügig voran, obwohl an dem einen oder anderen Schalter ein größeres Problem aufgetreten ist.
Aber da man sich nicht an einem bestimmten Schalter angestellt hat, spielt das keine Rolle. So gesehen arbeiten die Servicekräfte als Team, da sie gemeinsam die Probleme abarbeiten und sie vermeiden dadurch Flaschenhälse an einzelnen Schaltern.“

Lara war total begeistert: „Thomas, du musst mir unbedingt mal zeigen wie das bei der Datenbank funktioniert. Und Kim, ich werde im nächsten Sprint auf alle Fälle auch bei den Tests helfen, da werde ich bestimmt eine Menge über das System lernen!“

Das restliche Team ließ sich gleich davon anstecken und sie überlegten auch wie sie das auf die Planung übertragen konnten. Auf alle Fälle wollten sie keine Einzelpersonen den Tasks zuordnen, sondern alle arbeiten an allen Aufgaben nach der Priorität. Weiterhin wollten sie sich auch in andere Themen einarbeiten, natürlich mit Unterstützung der Experten und später dann mittels Review der Experten. Vor allem sahen das alle nicht nur als Möglichkeit die Entwicklung insgesamt zu beschleunigen, sondern auch als eine Chance ihre eigene Expertise zu erweitern. Wobei sie dabei pragmatisch vorgehen wollten, d.h. wann immer es sich ergibt, wollten sie sich gegenseitig unterstützen. Der schwierigere Weg wäre, dass im nächsten Sprint jeder sich per Definition einem neuen Thema widmet. Diesen Weg betrachteten zwar alle als eine super Investition, in Anbetracht ihrer Lage aber nicht als zielführend.

Verzögerungskosten durch den Verzug des Starts

Die Wertstromanalyse machte auch noch ein weiteres Phänomen deutlich: Für manche Stories dauerte es gefühlt eine Ewigkeit bis sie tatsächlich in einem Sprint eingeplant wurden. Das Problem lag dabei nicht an der niedrigen Priorität – ganz im Gegenteil, sondern daran, dass das Team während der Planung die Story immer wieder an den PO zurückweisen musste, mit der Bemerkung, dass sie nicht der Definition-of-Ready entspräche. Diese Definition dient dazu, klare Kriterien zu haben, die eine Story bereit für die Entwicklung kennzeichnet. Zusammengefasst aus dem Buch von Jeff Patton:

„Eigentlich gehen wir doch mit der Definition-of-Ready so um, als ob eine Mauer zwischen dem PO und uns Entwicklern stünde. D.h. der PO ist allein zuständig für die Aufbereitung der Story, bringt diese zur Planung (über die Mauer) und wir Entwickler weisen diese Story dann
zurück an ihn, d.h. wir werfen sie zurück über die Mauer. Die eigentliche Idee der agilen Entwicklung ist aber doch gemeinsam in einem cross-funktionalen Team zu arbeiten. D.h. für die Aufbereitung der Stories sind wir alle zuständig, nicht nur der PO. Darüber hinaus wird eine Story doch auch deshalb als solche bezeichnet, weil sie erzählt wird. D.h. im Dialog werden die Details gemeinsam geklärt. Natürlich kann man bei diesem Gespräch auch Aufzeichnungen machen, aber auf alle Fälle besteht eine Story nicht aus dem schriftlichen Template „Als der Benutzer … möchte ich erreichen, dass …, so dass …“, sondern aus dem geführten Gespräch.

Weiter sagt Jeff Patton: „… many programmers see stories as a one-way communication from analysts to them. Right from the beginning, stories were supposed to spark conversations. … Stories get their name not from how they’re supposed to be written, but from how they’re supposed to be used. … So the idea is telling, and you know you’re doing it right if you’re generating energy, interest, and vision in the listener’s mind.”

Das Team fasste umgehend den Beschluss, in Zukunft gemeinsam mit dem PO die Stories zu definieren und vor allem keine Story mehr mit dem Argument zurückzuweisen, dass sie der Definition-of-Ready nicht genügen würde. Vielmehr wollten sie dies als Aufforderung an alle sehen, dass sie sich intensiver über die Story unterhalten müssen, um die fehlenden Details gemeinsam zu klären.

Verzögerungskosten durch Perfektion

Bei der nächsten Retrospektive merkte der Product-Owner – mit Blick darauf, dass sie grundsätzlich so schnell wie möglich etwas liefern wollen – noch an, dass er oft den Eindruck hat, dass die Stories viel früher bereits den Kriterien der Definition-of-Done entsprächen. Er hatte diese zusammen mit Lara verifiziert und es gab keine großen Änderungen, sondern nur Klärungen bzw. Erläuterungen was einerseits die Technik (hier repräsentiert durch Lara) und andererseits das Business (präsentiert durch Sven) von einer Story erwartet, die als fertig deklariert wurde. Dabei kam heraus, dass üblicherweise das Team wesentlich mehr machte als der PO und auch die Kunden erwarteten und letztendlich auch bereit waren zu bezahlen. Zum Beispiel wurden immer wieder „Goldrahmen“ erstellt, um die Oberfläche noch schicker zu machen, das System noch performanter usw., obwohl Sven die Story ohne diese Erweiterungen bereits akzeptiert hätte. Aber diesen Nutzen erkannte die Business-Seite weder an, noch wollte sie dafür Zeit und Geld investieren. Von daher musste nochmals ganz deutlich gemacht werden, was genau von einer fertigen Story erwartet wurde. Sven erklärte, dass allgemein für das Projekt und insbesondere in der jetzigen Situation gelte: „Die Stories müssen gut genug – im Englischen auch barely-sufficient genannt – entwickelt werden. Alles was darüber hinaus geht, ist dieser Kunde nicht bereit zu bezahlen.“

Übereinstimmend stellte das Team fest, dass es in der Vergangenheit viel Zeit mit Verschönerungen bzw. mit dem Wunsch nach Perfektion verloren hatten. Da sie nun gemeinsam das Projekt zum Erfolg führen wollten, kostete es Sven nicht allzu viel Überredungskunst, diesen Wunsch zurückzufahren und stattdessen sich auf die notwendige – und nicht die mögliche – Qualität zu beschränken. Alle waren sich einig, dass sie zwar lieber die Stories perfekt realisieren wollten, sahen aber auch ein, dass die Kosten dadurch exorbitant steigen.

Fazit

Gerade die Wertstromanalyse bildet oft einen Dreh- und Angelpunkt zur Aufdeckung von Verzögerungskosten. Es ist dabei wichtig, einerseits alle Entwicklungsaktivitäten genau zu analysieren, aber dabei nicht den gesamten Ablauf aus den Augen zu verlieren. Wie in unserem Beispiel aufgezeigt, können darüber sehr schnell typische Verzögerungskosten entdeckt werden, die durch folgendes entstehen:

• Verzug des Starts,
• Experten und
• Perfektion.

Das Überraschende an diesen typischen Verzögerungskosten ist, dass sie oft auf den ersten Blick als positive Elemente angesehen werden. Den Start zum Beispiel zu verzögern, um die Dinge erst richtig zu verstehen und zu klären wie bei der Definition-of-Ready, ist ja erst einmal eine gute Sache. Allerdings ist es verheerend, wenn diese Klärung die cross-funktionale Zusammenarbeit verhindert. Ähnliches gilt bei Experten: Natürlich sind Experten wertvoll, aber sie können eben auch sehr schnell zu Flaschenhälsen mutieren und dann blockieren sie die Entwicklung, wodurch die Kosten höher werden als der Nutzen. Von daher gilt es von vornherein dem vorzubeugen und Backups bezüglich der Expertise im Team aufzubauen. Auch Perfektion ist natürlich eine gute Idee. Dennoch: Genau so häufig wie Projekte aufgrund von schlechter Qualität scheitern, oder zumindest Probleme haben, genauso häufig werden Projekte nicht fertig, weil mehr in die Qualität investiert, als tatsächlich bezahlt wird.

Die hier angesprochenen Verzögerungskosten sind typisch. Von daher empfiehlt es sich besonderes Augenmerk darauf zu werfen, was sich oft als entsprechend schwierig gestaltet, weil diese Kosten sich alle wie oben erwähnt auf den ersten Blick als positiv darstellen. Dies hat meist zur Folge, dass es ziemlich viel Mut braucht, um diese Dinge abzustellen. Aber nur durch diesen Mut ist man in der Lage, Projekte durch Effizienz zum Erfolg zu führen, was gerade in der heutigen Zeit, in welcher niedrige Kosten, wenig Zeit und viele Änderungen, hoch im Kurs stehen.

Jutta Eckstein arbeitet seit über zwanzig Jahren als Business-Coach, Change-Manager, Beraterin und Trainerin im In- und Ausland. Weltweit verfügt sie über eine einzigartige Erfahrung bei der erfolgreichen Umsetzung agiler Prozesse in mittleren bis großen, verteilten, unternehmenskritischen Projekten, wovon auch ihre Bücher Retrospectives for Organizational Change, Agile Softwareentwicklung mit verteilten Teams, Agile Softwareentwicklung in großen Projekten und zusammen mit Johanna Rothman Diving for Hidden Treasures: Uncovering the Cost of Delay in your Project Portfolio handeln. Ihr neuestes Buch (veröffentlicht zusammen mit John Buck) trägt den Titel Company-wide Agility with Beyond Budgeting, Open Space & Sociocracy. Jutta Eckstein ist Mitglied der Agile Alliance und im Programmkomitee verschiedener europäischer, amerikanischer und asiatischer Konferenzen. Jutta wurde 2011 von der Computerwoche in die Top 100 der bedeutendsten Persönlichkeiten der Deutschen IT gewählt.