Agile Projektsteuerung mit Artefakten und KPIs

Kürzlich durfte ich mit einem Team zusammenarbeiten, das Treiber entwickelt und ein großes Problem hatte: Es konnte seine Sprint-Commitments nie einhalten. Nach zwei Monaten war das Team so weit, dass es nicht mehr Scrum machen wollte. Das Framework passe einfach nicht zu ihnen, sagten sie.Ich setzte mich mit dem Team zusammen und wir begannen, den Prozess, so wie er aktuell ist, aufzuzeichnen. Üblicherweise können Commitments dann nicht eingehalten werden, wenn das Team im Laufe des Sprints viele ungeplante Aufgaben (Support, Change Requests) zu bewältigen hat. Das war aber hier nicht der Fall - der Anteil ungeplanter Aufgaben war mit jenem anderer Teams vergleichbar. Das eigentliche Problem war die Anzahl an Backlog Items, die gleichzeitig in Bearbeitung waren. Je mehr Treiber das Team parallel entwickelte, desto länger wurde die Fertigstellungszeit. Warum aber nahm das Team so viele Treiber gleichzeitig in Bearbeitung? Um der Sache auf den Grund zu gehen, setzten wir Artefakte auf, die den Arbeitsfluss verdeutlichen sollten:

1. Das Taskboard: Anstelle der klassischen Dreiteilung (Open/In Progress/Done) fingen wir an, den Workflow der Treiber-Entwicklung darzustellen. Es gab also pro Arbeitschritt eine eigene Spalte. Außerdem begrenzten wir die Zeilen am Taskboard, so dass maximal fünf Treiber gleichzeitig in Bearbeitung genommen werden konnten.
2. Das Cumulative Flow Diagram: Hier wird jede Woche gezählt, wie viele Aufgaben sich in welcher Spalte auf dem Taskboard befinden. So entsteht für jede Spalte eine eigene Kurve, die wöchentlich fortgeschrieben wird. Dadurch lässt sich ablesen, ob sich der Arbeitsprozess im Fluss befindet. In unserem Fall hatten wir mit einer flachen "Done-Kurve" zu tun (denn die Anzahl an fertig gestellten erhöhte sich nicht) während z.B. die "Waiting for Test"-Spalte steil anstieg, weil neue Treiber auf den Integrationstest warteten. Dadurch konnten wir sehen, wo die Engpässe im System sind - und was wir verändern müssen, um wieder einen Fluss zu erzeugen. Zudem lassen sich am Cumulative Flow Diagram Lead Time und Work in Progress ablesen (siehe nächster Punkt).

1. WIP und Lead Time: Wir einigten uns auf zwei KPIs (Key Performance Indicators). WIP (Work in Progress): Das ist die Anzahl an Treibern, die sich gleichzeitig in Bearbeitung befinden. Die Obergrenze hierfür haben wir auf fünf festgelegt und das Taskboard als quasi physikalische Grenze entsprechend aufgebaut. Lead Time: Das ist die Zeit, die zwischen Aufnahme eines neuen Treibers in die Entwicklung und dem Release vergeht. Hier fingen wir an, jedem Backlog Item auf dem Taskboard zwei Zeitstempel zu geben - "IN" und "OUT". Je länger die Lead Time, desto unproduktiver ist das Team.
2. Release-Burndown-Chart: Der Product Owner hatte für das Jahr mit 13 neuen Treibern (darunter Neuentwicklung und Updates) geplant. Mit dem Burndown-Chart konnten wir die tatsächlich fertig gestellten Treiber visualisieren - und anhand des Kurvenverlaufs erkennen, ob mit der aktuellen Lead Time das Ziel noch realistisch ist.

Was hat sich verändert?

Vor Veränderung kommt immer die Transparenz. Gerade als erfahrener agile Practitioner sollte man von schnellen Ratschlägen Abstand nehmen. Erst wenn tatsächlich verstanden wurde, wie das Team aktuell arbeitet, können Hebel für Veränderungen identifiziert werden. In diesem Fall wurde klar, dass das Team mit langen Wartezeiten konfrontiert war, da es für die Erstellung von Skripten sowie für die Verifikation und Validation auf Unterstützung von anderen Teams angewiesen war. Das Team füllte diese Wartezeiten, indem es in der Zwischenzeit mit etwas Neuem anfing. Wir kennen das Phänomen, wenn wir zu viele Downloads gleichzeitig starten - am Ende dauert alles viel länger. Deshalb konnte das Team keine Commitments einhalten. In der Außenwahrnehmung wurde das Teams als unzuverlässig gesehen - in Wirklichkeit machte es zu viel gleichzeitig.Um das Vertrauen in die Planbarkeit zurückzugewinnen, fing das Team mit wöchentlichen Forecasts an. Am Montag stellten sich alle vor das Taskboard und beschlossen gemeinsam, was sie bis Freitag erreicht haben wollten. Das Taskboard, wie es dann am Freitag aussehen sollte, wurde aufgezeichnet und zum Vergleich neben das aktuelle Taskboard gehängt. Das funktionierte gut.Product Owner und Management erhielten über den Release-Burndown und die Lead Time zwei ehrliche Indikatoren darüber, was tatsächlich geschafft werden kann. Somit hatten sie zum ersten Mal eine verlässliche Planungsgrundlage. Und der ScrumMaster konnte die Impediments beim Namen nennen, die der Produktivität im Wege standen. Mittelfristig wurden diese über eine engere Zusammenarbeit mit den anderen Teams (tägliches SoS) gelöst, so dass Abhängigkeiten sofort adressiert werden konnten und durch bessere Synchronisation Wartezeiten erst gar nicht entstehen. Langfristig geht es darum, dass das Team immer mehr selber in die Hand nehmen kann (etwa beim Testen) und so schneller wird.