Weiterhin muss immer deutlich gemacht werden, was mit den Zahlen geschieht. Das ist vor allem dann wichtig, wenn die Transparenz, die durch jede Messung entsteht, plötzlich als Kontrollinstrument missbraucht wird. Auch das konnte ich bei einem Kunden beobachten:

Ein großer Konzern hat bei einigen seiner Projekte agile Entwicklung eingeführt. Diese Teams führten die "üblichen" Messungen durch. Dazu gehörte auch der sogenannte Burndown-Graph (s. Abb.1). In diesem wird zu Beginn einer bspw. zweiwöchigen Iteration aufgezeigt, wie viel sich ein Team für die zwei Wochen vorgenommen hat und nach jedem Tag wird aufgetragen, wie viel das Team jetzt noch – d. h. nach einem Tag Arbeit – bis zum Ende der Iteration zu tun hat. Dies kann auf verschiedene Arten erfolgen, eine Möglichkeit ist, zu Beginn alle Aufgaben zu zählen, die das Team fertigstellen muss. D. h. das Team hat sich z. B. 100 Aufgaben für die zwei Wochen vorgenommen. Nachdem ein Tag um ist, sind es vielleicht nur noch 90 Aufgaben. Dadurch ergibt sich ein Graph, der abwärts verläuft (daher der Begriff Burndown) und hoffentlich am Iterationsende, wenn alle Aufgaben erledigt sind, bei Null steht. Diese Messung, sowie diverse andere, wurden in diesem Konzern über einen großen Monitor transparent gemacht. Und zwar nicht nur bei dem entsprechenden Team, sondern konzernweit. Auf den ersten Blick schien dies offene Kommunikation und große Transparenz zu bedeuten. Als ich aber mit einem der betroffenen Teams sprach, wurde gleich erkennbar, dass das von dem Team nicht als hilfreich erachtet wurde. Denn sobald die Kurve nicht wie geplant verlief, stand "irgendein" Manager bei dem Team und fragte, was denn hier los sei. D. h. diese Transparenz wurde als Kontrolle und auch als Druckmittel eingesetzt. Dazu muss noch gesagt werden, dass speziell der Burndown-Graph als teaminternes Mittel gilt, damit das Team nachverfolgen kann, ob es das zugesagte Ziel am Iterationsende erreicht bzw. was es evtentuell verändern muss, um dieses zu erreichen. D. h. diese Messung ist vom Ursprungsgedanken her nicht als externes Reporting gedacht.

Zusammengefasst sollte für jede Messung folgendes sichergestellt werden:

• Sowohl das Ziel als auch der Zweck der Messung sollte deutlich werden.
• Die von der Messung betroffenen Personen sollten selbst die Messkriterien definieren.
• Die Messung muss auf Vertrauen und nicht auf Kontrolle basieren.
• Jeder, der in die Messung involviert ist, muss verstehen, was mit den Zahlen geschieht.

Nun stellt sich die Frage, was denn genau gemessen werden soll, um die Produktivität zu erfassen. Der Burndown-Graph ist, da er wie oben angeführt eine team-interne Metrik ist, nicht dazu geeignet. Die Teamgeschwindigkeit ist auch nicht wirklich aussagekräftig, da es sich hierbei nicht um eine Produktivitätsmessung handelt, sondern um eine Kapazitätsmessung, die dann zur weiteren Planung hergenommen wird. Hilfreicher für die Produktivitätsmessung ist das Messen der durchschnittlichen Durchlaufzeit auf Basis der Wertschöpfung. Dafür muss erst einmal für jede Story vorab auch der Wert definiert werden, den man sich von ihr verspricht. Und dann wird gemessen, wie lange es dauert, von dem Zeitpunkt, an welchem diese Wertschöpfung eingeplant wurde, bis zu dem Zeitpunkt, zu dem der Wert dann tatsächlich an den Kunden geliefert wurde. In agilen Teams wird das oft durch ein Story-Board (s. Abb.2) deutlich, an welchem die Zustände von Eingeplant über in Arbeit und zur Verifizierung bis zu Fertig (engl. Todo, in Progress, to Review, Done) dargestellt werden und die Stories und Aufgaben entsprechend ihres Zustands eingeordnet werden.

Um einen Trend ausmachen zu können, wird dafür meist der Durchschnittswert ermittelt, welcher den über verschiedene Zeiträume bspw. verschiedene Release-Zyklen verglichen wird. Mit dem Fokus auf den erstellten Wert bleibt der Markt im Blick. D. h. es geht nicht darum, so viele Stories wie möglich fertig zu stellen, was gleichbedeutend ist mit der Lieferung von "irgendetwas". Im englischen betont man den Fokus auf den Wert durch "Outcome versus Output" – ein findiger Kollege bezeichnete das im deutschen treffend mit "Erlebnis versus Ergebnis", vereinfacht wird das auch über das Idiom "Qualität über Quantität" dargestellt. Das heißt, es geht nicht darum, so viel wie möglich fertig zu stellen, sondern tatsächlich für uns und den Kunden einen Wert zu erschaffen. Am besten verifiziert man das noch zusätzlich dadurch, dass man Tests erstellt, die Daten darüber liefern, welche Funktionalitäten vom Kunden tatsächlich verwendet werden. Damit kann auch die Hypothese über die Wertschöpfung verifiziert werden.

Nur was geliefert ist, erzeugt keine Verzugskosten.

Misst man die Werterstellung von Anfang an, d. h. vom Zeitpunkt, an dem die Anforderung das Unternehmen erreicht, über die Zeit, bis sie in einem Projekt bei einem Team in einem Backlog landet und bis zur tatsächlichen Auslieferung, dann hat man meist schon die ersten Anhaltspunkte, wo die Zeit tatsächlich bleibt. Das heißt, damit wirft man einen ganzheitlichen Blick auf die Verzugskosten im Unternehmen und nicht nur in einem Entwicklungsteam.

Analyse der Verzugskosten

Meine Kollegin Johanna Rothman hat Verzugskosten treffenderweise folgendermaßen definiert: "Verzugskosten sind das Nachdenken über den Gewinn, den man nicht macht und die Kosten der andauernden Entwicklung." Damit liegen einige Ursprungsquellen für den Verzug bereits auf der Hand: Allen voran summieren sich all die Dinge zu Verzugskosten, an denen wir arbeiten, die wir aber nicht fertig stellen. Denn nur was geliefert ist, erzeugt keine Verzugskosten. Daraus folgt, dass man als allererstes sicherstellen sollte, so wenig wie möglich parallel anzufangen und stattdessen so viel wie möglich gemeinsam fertig zu stellen. Dazu gehört, dass ein Team besser an wenigen Stories gemeinsam arbeiten sollte, um diese dann auch tatsächlich zeitnah fertigzustellen, anstatt, dass zum Beispiel jeder Mitarbeiter an einer anderen Story arbeitet und sich dadurch die Fertigstellung aller Stories in die Länge zieht.

Das gleiche gilt auch für Projekte. Nämlich anstatt mittels Multi-Projekte parallel an vielen Projekten zu arbeiten, sollte man sich besser auf wenige fokussieren und diese schnell zu Ende bringen. Angenommen wir haben drei anstehende Projekte, die (um die Berechnung einfacher zu machen) alle einen Monat für die Fertigstellung brauchen. Arbeiten wir nun an allen Projekten gleichzeitig, so machen wir zum ersten Mal nach drei Monaten Gewinn. Arbeiten wir im Gegensatz dazu sequentiell an den Projekten, so erzielen wir bereits nach einem Monat einen Gewinn – nämlich nach der Fertigstellung des ersten Projekts. Entsprechend können wir den nächsten Gewinn nach Fertigstellung des zweiten Projekts nach zwei Monaten erwarten usw.

Das Problem an Multi-Projekten ist nicht nur der nicht gemachte Gewinn, sondern auch die Kosten der andauernden Entwicklung. Die Arbeit an mehreren Projekten erfordert auch vom einzelnen Mitarbeiter einen ständigen Wechsel der Konzentration auf unterschiedliche Aufgaben (engl. Task switching). Mehrere Untersuchungen haben gezeigt, dass durch solche Task-Switches schnell 30 Prozent der Produktivität verloren gehen.

Experten

Selbstverständlich braucht es in jedem Team Experten. Teilt man sich jedoch die Arbeit anhand der Expertise auf, kann nicht gemeinsam an einer Story gearbeitet werden. Das habe ich oben bereits erwähnt. Ich möchte hier den Effekt nochmals deutlich machen. Wird die Arbeit einzelnen Experten zugewiesen, so hat man den gleichen Effekt wie an der Supermarktkasse. Als Einkäufer muss ich mich vorab entscheiden, an welche Kasse ich mich anstelle. "Natürlich" stellt sich im Nachhinein heraus, dass ich mich ausgerechnet an der Kasse angestellt habe, an der es irgendein Problem gibt – es wurde vergessen, die Ware vorher zu wiegen, eine Verpackung ist aufgebrochen, irgendjemand findet das Kleingeld nicht, usw. Daraus folgt, dass es in meiner Schlange nicht voran geht und ich kann beobachten wie an den anderen Kassen Einkäufer, die sich lange nach mir zur Kasse begeben haben, längst den Laden verlassen. D. h. die eigentlich vorab priorisierte Abarbeitung – im Supermarkt ist das "first come, first serve"– wird hinfällig. Das gleiche gilt bei der Zuordnung der Arbeit an Experten. Angenommen wir haben zehn Stories, die alle priorisiert sind und von unterschiedlichen Experten abgearbeitet werden. Stellt sich nun heraus, dass bspw. der Experte, der die zweite Story bearbeitet, auf ein großes Problem gestoßen ist, so dass sich die Implementierung verzögert, wird automatisch die Priorisierung ignoriert. Denn die Experten, die an den Stories mit der Priorität drei, vier, fünf etc. arbeiten, machen diese einfach fertig, während die Story zwei – so wie andere Stories, die diesem Experten zugeordnet wurden – immer noch in der Schlange hängen. Das heißt, die Schlange des zweiten Experten wird immer länger, während niedriger priorisierte Stories fertig werden und bereits den "Laden" verlassen.

Man muss dafür sorgen, dass die Teammitglieder voneinander lernen, so dass sie sich gegenseitig unterstützen können.

Das heißt, die Zuordnung von Aufgaben an Experten sind Verzugskosten. Um diese zu vermeiden, muss man dafür sorgen, dass die Teammitglieder voneinander lernen, so dass sie sich gegenseitig unterstützen können. In meinen Projekten habe ich nicht den Anspruch, dass jedes Teammitglied alles kann – das ist auch aufgrund der hohen Komplexität üblicherweise utopisch – aber wir haben meist das Ziel, dass jedes Teammitglied sich mindestens in zwei-drei Themen auskennt. Das reicht bereits aus, um diese Verzugskosten zu minimieren.

Qualität

Natürlich wollen wir alle ein System von hoher Qualität liefern. Das fordert allein schon die Berufsehre. Das heißt, im Team wird darauf geachtet, dass man sich keine technische Schuld auflädt, man achtet vielleicht sogar die Prinzipien von Clean Code, programmiert die Stories so, dass sie zu 100 Prozent fehlertolerant sind und bedenkt für die zukünftige Flexibilität alle Eventualitäten bei der Implementierung. Das ist oft genau der richtige Weg. Aber eben nicht immer. Manchmal wird auf mehr Qualität geachtet, als der Kunde bereit ist zu bezahlen und es die eigene Strategie vorgibt. Man spricht dann von der sogenannten Goldrahmenerstellung.

Konsequenterweise muss man sich damit auseinandersetzen, welche Qualität überhaupt gefordert ist. Dazu stellt man am besten folgende Fragen:

• Ist 100 prozentige Fehlerfreiheit gefordert bzw. notwendig?
• Ist in dem Budget Clean Code eingepreist?
• Bei der Abwägung zwischen Lieferung und Qualität – was ist in unserem Marktsegment wichtiger? Zum Beispiel ist es in einem neuen Markt üblicherweise wichtiger, erst einmal tatsächlich am Markt zu sein, während die Geschäftsstrategie für ein Produkt, das schon länger auf dem Markt ist, meist v. a. über Qualität Kunden be- und erhält.

Kurzum, man muss sich im Klaren darüber sein, für wie viel Qualität der Kunde/Markt bezahlen wird und auch, welche Rolle die Qualität in unserer Geschäftsstrategie spielt. Diese muss dann gegenüber einer schnelleren bzw. verzögerten Lieferung abgewogen werden. Es geht also darum, eine bewusste Entscheidung zu treffen. Dies geht am besten, wenn man sich bereits vorab Gedanken über das Investitionsvolumen für eine Story macht. D. h. oftmals ist die Schätzung der Entwicklung weniger wichtig, als die Schätzung des zu erwartenden Werts zusammen mit der Definition des maximalen Investitionsvolumens. Denn diese beiden Werte können sehr stark die Art der Entwicklung – v. a. hinsichtlich erzielter Qualität – beeinflussen.