Letzte Änderung am 22. Februar 2016 by Christoph Jüngling
Der übliche Ablauf eines Projektes ist wohl der, dass anfänglich ein Plan gemacht wird. In diesem Plan ist idealerweise alles enthalten, was gemacht werden soll, welche Abhängigkeiten die Aufgaben voneinander haben und wie lange man jeweils brauchen wird.
Wie war das? Wie lange man brauchen wird? Sagen wir besser “wie lange man voraussichtlich brauchen wird”! Denn ein Plan ist eben doch nur ein Plan. Das wusste auch Bert Brecht schon:
Ja, mach nur einen Plan.
Und sei ein großes Licht.
Mach ruhig noch ‘nen zweiten Plan.
Geh’n tun sie beide nicht.
In diesem Artikel
Ein Plan ist ein Plan ist ein Plan
Mit einem Plan sagt man aus, dass man beabsichtigt, etwas auf eine bestimmte Weise und in einer bestimmten Reihenfolge zu tun. Ein Plan ist also eine Absichtserklärung. Aber was, wenn sich die Absichten nicht umsetzen lassen, weil das Universum andere Pläne mit uns hat? Das passiert nicht? Fragen Sie mal die Baubranche …
Jeder kennt das Problem: “Na, was hast du am Wochenende vor?” — “Wir planen eine Motorradtour in den Harz. Aber wir wissen noch nicht, ob das Wetter hält.” Die Motorradtour ist also geplant, man weiß wo man lang fahren will, wo gerastet werden soll usw. Man beachte die Wortwahl: “geplant” = beabsichtigt, “fahren will” ≠ “fahren wird”! Denn das Wetter lässt sich nicht planen, ebenso wie Straßensperren nur begrenzt bekannt sind und Unfälle überhaupt nicht. Das passiert einfach. Unter Umständen muss die Tour kurzfristig abgesagt oder verschoben werden; oder umgeplant, vielleicht ist das Wetter im Lahntal an dem Wochenende besser.
Planung in Scrum
Das Scrum-Team ist sich über diese Unwägbarkeiten im Klaren. Es weiß, dass im Vorfeld niemals alle Eventualitäten berücksichtigt werden können. Es weiß, dass irgendetwas immer dazwischen kommt, weswegen dann der Plan wenigstens in Teilen umgearbeitet werden muss. Einen Plan umzuarbeiten bedeutet aber, einen Teil der Arbeit, die in den anfänglichen Plan eingeflossen ist, wegzuwerfen und hier neu zu beginnen.
In Scrum wird daher möglichst vermieden, von Beginn an alles haarklein auszurechnen. Daher weiß man auch nicht unbedingt, wann man fertig sein wird. Genaugenommen “weiß” das auch ein klassischer Projektmanager nicht, er glaubt nur, es zu wissen. Aber er schätzt genauso wie das Scrum-Team, nur dass das Scrum-Team sich die Selbsttäuschung, alles zu wissen, nicht erlaubt. In der Offenheit, diese Art der Unwissenheit zuzugeben, liegt keine Schande. Denn wir alle sind Menschen, keine Götter.
Dennoch sind klassisches Projektmanagement und Scrum keine Verfahren, die einander ausschließen würden. Einiges versuchen nämlich beide Methoden: Anfänglich so viele Informationen zu gewinnen wie möglich, um die Strategie festzulegen. Aus den anfänglich erkannten Aufgaben und deren Abhängigkeiten ergibt sich nämlich mehr oder weniger zwingend eine Reihenfolge oder auch die Option paralleler Abläufe, und das ist auch im Scrum sehr wichtig. So ein Plan wird oft in Microsoft Project gemacht, weil man da sehr schön aus den Einzelinformationen die Gesamtlaufzeit ablesen kann bzw. bei festgelegtem Endetermin den spätesten Beginn (sog. GANTT-Chart, siehe Foto).
Agilität
Im Scrum fließen diese Informationen in das Project Backlog ein, eine Art projektweiter To-Do-Liste. Von dort werden sie dann für jeden Sprint im Rahmen der Velocity eingeplant. Und innerhalb eines solchen Sprints sollte (!) sich die Menge der Aufgaben und die Prioritäten nicht ändern. Neue Aufgaben kommen erst mal in das Project Backlog, werden aber frühestens in den nächsten Sprint übernommen. Für die Dauer eines Sprints setzt Scrum also den Traum aller Projektmanager um, mit fixen Vorgaben zu arbeiten. Da jedoch von Sprint zu Sprint ein neuer Mini-Plan gemacht wird, ist man recht gut in der Lage, auf Regenschauer oder Gewitterstimmungen von außerhalb des Projektes zu reagieren. Daher kommt der Begriff “Agilität”.
In dem Artikel Planning Poker habe ich beschrieben, wie Aufwandsabschätzungen in Scrum durchgeführt werden können. Die Frage, die sich mir in der Vergangenheit oft stellte, ist diese:
Lässt sich die ermittelte Durchschnitts-Velocity sinnvoll und verlässlich in Zeiten umrechnen?
Würde ein Team z.B. bei einem 20 Arbeitstage dauernden Sprint (4 Wochen) mit einer durchschnittlichen Velocity von 50 Points arbeiten, dann bekäme man 50 Pt / 20 Tg = 5/2 = 2,5 Story Points pro Tag. Daraus würde sich umgekehrt errechnen lassen, dass das Team für ein Projekt mit dem Umfang von 450 Points etwa 450/2,5 = 180 Arbeitstage brauchen würde, also etwa 9 Monate. In diesem Zeitrahmen sind schon ganz andere Projekte, die die Natur schon sehr oft durchgeführt hat, aus dem Ruder gelaufen :-)
Verlässlichkeit
Rein rechnerisch ist das noch nachvollziehbar. Aber wie verlässlich ist die Prognose in der Praxis?
Betrachten wir das oben Gesagte, dann liegt die Antwort auf der Hand: Mehr oder weniger verlässlich. Denn trotz Scrum ist auch die Velocity nur eine Planzahl, die sich aus einem Mittelwert (Median) der bisherigen Sprints errechnet. Ebenso extrapoliert das klassische Projektmanagement einen gefühlten Mittelwert (genannt “Erfahrung”) in die Zukunft. An dieser Stelle sei ein Link in eine Parallelwelt gestattet, die sich ebenfalls mit Magie befasst. Der Absatz über Human Divination aus dem Harry-Potter-Wiki könnte ebensogut in einem Handbuch über Projektmanagement stehen. Denn in beiden Welten gilt:
Learned wizards and witches seem to regard the practice of divination with scepticism.
Wenn das organisatorische Umfeld einigermaßen stabil bleibt, wenn niemand krank wird, wenn nicht plötzlich in der Produktion ein schwerer Bug auftritt, dann wird voraussichtlich die geplante Menge an Stories bis zum Ende des Sprints fertig sein. Und da ist es egal, ob die Einheit Story Points oder Stunden lautet.
Ein Plan ist eben auch im Scrum nur ein Plan.
Foto: iStockphoto.com/Peter Nadolski
1 Kommentar
Ein Bahnkunde steht auf dem Bahnsteig und wartet auf den schon um 10 Minuten verspäteten Zug. Einem Bahnbediensteten gegenüber stellt er die Pläne der Bahn in Frage, da die Züge sowieso meistens zu spät kommen. Der Bahnbedienstete entgegnet: “Woher sollen wir wissen, dass unsere Züge zu spät kommen, wenn wir keine Pläne machen würden?”
Was die meisten Kritiker einer “Planung” nicht verstanden haben: Pläne helfen, sich mit der Materie eines Projekts intensiv zu befassen und dem Team ein gemeinsames “Big Picture” zu vermitteln”. Sie dienen darüber hinaus, Abweichungen vom Plan zu identifizieren und Lesson Learned zu dokumentieren, die ein bewusstes und unbewusstes PM-Kow How generieren.