Was ist anders bei agiler Planung?

17.12.2008 von Jens Coldewey.

Ein Thema, das meiner Meinung nach oft bei der Ausbildung von Coaches und Scrum Mastern und bei der Einführung von Agilität zu kurz kommt, ist agile Planung. Ich erlebe immer wieder Projektleiter und Scrum Master, die verzweifelt versuchen, ihre Teamplanung in MS Project zu gießen, “weil das hier so gefordert wird”. Das ist in etwa, als würden Sie Spikes unter Ihre Ski montieren, “weil das so gefordert wird”. Machbar, aber sicher keine gute Vorbereitung für außergewöhnlich gute Leistung. Was ist also anders bei agiler Planung?

Um den Eintrag in Grenzen zu halten, möchte ich mich auf die reine Planungstechnik beschränken, also Team- und Kooperationsaspekte außer Acht lassen. Schließlich kann ein Team auch kooperativ Gantt-Diagramme malen, nur es ist eben nicht sonderlich sinnvoll. Warum? Ein wesentlicher Unterschied zu traditioneller Projektplanung ist, dass bei der Agilität nicht die Auslastung der einzelnen “Ressourcen” (dieser Ausdruck lässt so schön vergessen, dass wir über vernunftbegabte Menschen reden!) optimieren, sondern den Durchflussgeschwindigkeit und Durchsatz von neuen Fähigkeiten des Systems. Wir versuchen also, so viel zusätzliche Wertschöpfung fertig zu stellen, wie in guter Qualität möglich, nicht so viel zu arbeiten, wie möglich.

Schlüssel zu diesem Ziel ist die Erkenntnis, dass in der DV-Entwicklung ja keine Maschinen verplant werden, sondern in der Regel hoch qualifizierte Experten, die durchaus in der Lage sind, sich um ihre eigene Auslastung zu kümmern. Die Planung dient also der Koordination und Fokussierung, nicht der der Arbeitszuweisung. Etwas weniger abstrakt wird festgelegt, was zu tun ist, nicht wer etwas tun soll. Die nächste Person, die frei ist, bzw. das nächste freie Paar kümmert sich dann um die nächste Aufgabe, die ansteht. Das wird üblicherweise als “Pull-Prinzip” bezeichnet, oft auch (nicht ganz korrekt) als Kanban.

Dieses System hat Vor- und Nachteile. Zum einen ist es wesentlich flexibler, als eine Zuteilungsplanung, die nur dann gut funktioniert, wenn die Bearbeitungsdauer pro “Ressource” gut vorhergesagt werden kann, aber sehr empfindlich auf Schätzfehler reagiert. Das lässt sich mathematisch mit Hilfe der dabei konstruierten gekoppelten Warteschlangen begründen, die ein chaotisches System darstellen, aber das würde hier zu weit führen. Intuitiv kann das jeder Projektleiter bestätigen, der einmal versucht hat, sein Gantt-Diagramm durchzuhalten oder auch nur aktuell zu halten. Das Pull-Prinzip hingegen reagiert sehr gutmütig auf Schätzfehler und Veränderungen in den Vorgaben, was ebenfalls warteschlangentheoretische Gründe hat.

Der Nachteil ist, dass das Verfahren einen Generalistenansatz im Team benötigt. Teams, in denen jedes Mitglied genaustens seinen “Claim” abgesteckt hat, in dem nur diese eine Person arbeiten darf (”Code Ownership”) bauen trotz Pull-Prinzips genau das gleiche fragile Warteschlangensystem auf, das die Auslastungsplanung schon instabil macht. In der agilen Planung erkennt man diese Situation normalerweise daran, dass an niedrig priorisierten Aufgaben gearbeitet wird, obwohl noch höher priorisierte Aufgaben anstehen, weil “das nur die Eva machen kann”.

Dieser Nachteil ist aber verschmerzbar, weil er ohnehin keine erstrebenswerte Situation darstellt: Wird Eva krank, kann daran das ganze Projekt scheitern. Zudem sind in meiner Erfahrung Kopfmonopole eine der wichtigsten Ursachen für verpasste Termine. Sicherlich wird es immer Aufgaben geben, die Eva effizienter erledigen kann, als Adam. Aber das spielt erst dann eine Rolle, wenn beide auch gleichzeitig anfangen könnten. Bei der Optimierung des Durchsatzes spielt nämlich die Wartezeit auch eine Rolle, anders als bei der Optimierung der Auslastung. Oder, wie Alistair Cockburn formuliert, “Effizienz wird zur Dispositionsmasse abseits des kritischen Pfades”.

Darf man also noch Gantt-Diagramme malen? In seiner Freizeit natürlich. Für ein agiles Projekt spielen sie aber keine Rolle, es gibt keine Entscheidungen, die auf ihnen basieren und sie sind daher Zeitverschwendung. Fortschritt wird mit Hilfe von Burnup bzw. Burndowncharts gemessen und mit lauffähiger Software. Das ist aussagekräftiger, als ein Balken im Gantt-Diagramm, der zu 80% fertig ist, weil 80% der Zeit vergangen sind. Diese Instrumente sind einfacher, effektiver und effizienter, als die beeindruckende Kombinatorik von Ressourcen bei Werkzeugen zur auslastungsbasierten Planung, die von der Realität in der Regel schneller überholt werden, als man sie an der Wand aufhängen kann.

Geschrieben in Planung, Management, Agilität | Drucken | 3 Kommentare »