Ich höre immer noch häufig die Aussage, dass Agile Methoden wie Scrum keinen Plan hätten oder bräuchten und deshalb für dieses oder jenes Projekt ungeeignet wären. Um es klar zu sagen: Agile Management ist für jedes Projekt ungeeignet in dem es egal ist, ob das Wichtigste zuerst umgesetzt wird. Jedes andere Projekt kann auch von der Disziplin und der Transparenz eines agilen Vorgehens nur profitieren. Und natürlich gibt es auch bei agilen Projekten einen Plan – die Betonung liegt dabei auf “einen”.
Vermutlich hat dieses Gerücht mehrere Ursachen. Die Naheliegendste ist, das Scrum und Co. häufig mit dem Wegwerfen von Gantt Charts und weniger Aufwand in der langfristigen Planung verkauft wird. Auch wenn ich besagten Charts keine Träne nachweine und bei korrekter Umsetzung tatsächlich weniger Aufwand anfällt; ganz wegfallen kann und darf die Planung nicht. Leider ist die Verantwortlichkeit im Management des Product Backlogs und der am Projekt beteiligten Stakeholder durch den Product Owner nur implizit.
Und damit kommen wir zur zweiten Ursache: eine bewusst oder unbewusst schlampige Implementierung von Scrum, auf das dann die Verantwortung geschoben wird. Produkt- bzw. Projektverantwortliche ziehen sich mit der Aussage aus der Verantwortung, sie würden nach Scrum handeln und dort sei langfristige Planung nicht vorgesehen. Doch Scrum ist ein Framework und nichts als ein Framework. Es schreibt, wenn es in der Softwareentwicklung eingesetzt wird, auch nicht die Benutzung eines Computers vor; trotzdem würde kein Entwickler auf die Idee kommen, sich auf diese Argumentation zurückzuziehen. Nur weil Scrum nicht explizit Termine, Roadmaps und einen Produktplan fordert heißt das noch lange nicht, dass es keinen geben muß.
Viele Pläne – keine Planung
Im Gegenteil. Die wirkliche Stärke von agilen Methoden liegt gerade darin einen Plan an die aktuellen Bedürfnisse anzupassen und Abweichungen (gewollte und ungewollte) transparent zu machen und allen Beteiligten zu kommunizieren. Dies führt zu einer beispiellosen Konvergenz für gewöhnlich schnell disparate Pläne, wie ich sie als Projektmanager erleben durfte:
Der Kunde unterschreibt mit einem Auftrag gleich auch einen fein ausgearbeiteten Projektplan und verlässt sich darauf.
Der Projektleiter weiß zu diesem Zeitpunkt bereits, dass er zum geplanten Projektstart noch kein Team haben wird und hat in seinem Kopf den Plan bereits angepasst. Darüber mit dem Kunden zu kommunizieren kommt nicht infrage, schließlich will man den Auftrag – um jeden Preis.
Das Projektteam sieht, sobald es sich mit dem Projekt auseinandersetzt, wie unrealistisch die für das Angebot zugrunde gelegten Aufwände waren – und stellt sich bereits seelisch darauf ein, dass der Endtermin nicht realistisch ist. Der Projektleiter will aber vom rausgegebenen Scope und Termin nicht abweichen. Das Team hat nur eine Stellschraube, die hier noch genutzt werden kann: Es spart an der Qualität. Plant, prüft und testet nur das Allernötigste, wohlwissend das das Projekt damit auf lange Sicht fehlerbehaftet und schlecht wartbar bleiben wird.
Ein langjähriger Entwickler, der bereits Altlasten in 3 Vorprojekten zu verwalten hat, steht deswegen dem Projekt nur eingeschränkt zur Verfügung – Supportaufwände fressen 50% seiner Zeit. Der Gedanke noch ein weiteres Gurkenprojekt umsetzen zu müssen ist das Signal für ihn sich nach einem neuen Arbeitsplatz umzuschauen. Die dreimonatige Kündigungsfrist bedeutet, dass er und sein Fachwissen auf der geplanten Projekthalbzeit wegfallen.
Es ist noch nicht ein Handschlag bei der Umsetzung getan, aber es existieren bereits 4 Pläne für das selbe Projekt: und keiner ist mit einem anderen auch nur annährend deckungsgleich.
Der eine Plan
Im starken Kontrast dazu einigen sich die Projektparteien im agilen Ansatz auf einen Planaufwand für das Gesamtprojekt und einen gemeinsamen Endtermin, der sich nicht am Gesamtscope orientiert, sondern am Minimal releaseable Product (MRP). Der Scope wird grob beschrieben und in den regelmässigen Besprechungen mit den Stakeholdern abgeglichen. Denn jeder Kunde lernt im Laufe seines Projektes nicht nur Neues über die technische Lösung. Nicht selten hinterfragt er sein eigens Geschäftsmodell und seine Strategie weil sich neue Möglichkeiten eröffnen – und agile möchte diese Erkenntnisse auf keinen Fall auf der Straße liegen lassen. Damit geschehen Abweichungen grundsätzlich öffentlich und bewusst und es wird dennoch immer das Wichtigste fertig. Naht das Projektende lässt sich das Scope anpassen oder der Termin verschieben, ohne Qualitätseinbussen in Kauf nehmen zu müssen. Alle Beteiligten schauen auf den einen, selben Plan.
Agile braucht keine Pläne – es braucht *einen* Plan.
Tolle Tools zur Planung bietet bspw. Roman Pichler auf seiner Website kostenlos an. Ladet Euch bei ihm das Vision Board und die Roadmap runter und legt direkt los: http://www.romanpichler.com/tools/