Scrum Gantt: Management will Planung & Reporting

Home / Scrum Gantt: Management will Planung & Reporting

Zusammenfassung: Stakeholder (Management und Kunden) wollen Reportings und Planungsdokumente, die sie lesen können. Ein Release-Burndown aus dem Scrum können sie nicht lesen, ein Gantt-Chart schon. Wir zeigen, wie man von A zu B kommt. Das Management bekommt eine Roadmap und weiß endlich, was das Scrum-Team macht und wann es „fertig“ ist. So steigert man die Akzeptanz von agiler Entwicklung bei Gantt-verwöhnten Stakeholdern.

Wie agile Entwicklug für Stakeholder transparent und planbar wird

Diesen Artikel zu lesen, lohnt sich dann,

  1. Wenn Sie in Ihrem Unternehmen Scrum eingeführt haben, und Sie als Teil des Managements, sich eine bessere Planbarkeit und Reportings von Ihren Scrum-Teams wünschen. Es ist möglich und wir zeigen hier wie.
  2. Wenn Sie in Ihrem Unternehmen Scrum eingeführt haben, Sie als Teil des Scrum-Teams, die Forderung von Stakeholdern nach besserer Planbarkeit kennen und das Problem gerne lösen würden. Es ist möglich und wir zeigen hier, warum das Management ein klassisches Reporting haben will und wie Sie es ihm geben können.
  3. Wenn Sie in Ihrem Unternehmen Scrum einführen möchten und mehr über typische Konflikte im Change-Prozess und bewährte Methoden zur Lösung erfahren möchten.

Über die Schwächen von Scrum aus der Sicht des Managements und über die Schwächen klassischer Projektplanung aus der Sicht agiler Entwicklung

Das Gantt-Chart stammt aus der klassischen Projektplanung. Es wird verwendet, wenn sehr detaillierte Aufgaben, Abhängigkeiten, Termine und Ressourcen verwaltet werden sollen. Typische Praxis: Droht ein Termin zu platzen, dann bekommt die gefährdete Aufgabe – im Projektplan – mehr personelle Ressourcen zugewiesen. Soweit die Theorie.

Das Verschieben von personellen Ressourcen entspricht nicht der Planung und Methodik von agiler Entwicklung. In Scrum-Projekten wird das gesamte Projekt zunächst nur sehr grob in so genannten Epics beschrieben. Die Detailplanung erfolgt erst, wenn die Epics in Userstories zerlegt sind, wenn die Komplexität einmal vom Entwickler-Team geschätzt wurde und dann vom Productowner priorisiert wurde. Auf diese Weise wird nur das im Detail geplant, was auch in nahe liegender Zukunft umgesetzt wird.

Im Scrum übernehmen die Teams Aufgaben. Die Teams bestehen aus Menschen, die man erfahrungsgemäß nicht verlustfrei von einer Aufgabe abziehen und auf die nächste Aufgabe draufsetzen kann. Soweit die Praxis, auch in klassischer Projektplanung. Die Erfahrung zeigt, dass Menschen eine gewisse Einarbeitungszeit brauchen, wenn sie die Aufgabe wechseln. Deshalb ist die rechnerische Verfügbarkeit von personellen Ressourcen in einem klassischen Wasserfall-Projekt in der Praxis eben doch nicht zu 100% verfügbar. Bei der agilen Entwicklung geht man deshalb mit Engpässen und Verzögerungen anders um. Im Scrum wird der so genannte Scope (der Umfang eines Projektes) reduziert oder ein Release-Termin verschoben. Ressourcen, die ja Menschen sind, umher zu schieben ist im Scrum nicht vorgesehen.

Viele Mitglieder im Management sind mit der klassischen Detailplanung aufstiegen bzw. aufgewachsen. Das Management kann Dashboards, Balanced Scorecards und Gantt-Charts lesen und will deshalb auch mit diesen Werkzeugen steuern. Dahinter steht die Überzeugung, man könne mit der klassischen Detailplanung ganz genau vorhersagen, wie ein Projekt laufen wird, zumindest wie es laufen soll.

In der Praxis offenbart die Statistik von gelungenen IT-Projekten aber , dass diese Überzeugung mehr eine Hoffnung war. Es stellt sich hinterher heraus, dass IT-Projekte – in der überwältigenden Mehrzahl – anders laufen als geplant. Mit anderen Worten: die genaue Projektplanung führt nur dazu, dass der Irrtum –ex post- messbar wird. Durch diesen statistischen Nachweis, dass IT Projekte auch dann, wenn sie noch so genau und akribisch geplant wurden, zumindest „in time“ scheitern ist auch das Gantt-Chart, als Werkzeug des klassischen Projektplans, bei agilen Teams in Misskredit geraten. Scrum setzt darauf, die Planung den Gegebenheiten – bei jeder sich bietenden Gelegenheit – anzupassen, um so zumindest zu jedem Zeitpunkt zu wissen, wo man steht, nicht nur wo man stehen sollte.

Warum Stakeholder bekommen sollten, was sie haben wollen

Trotzdem will das Management „mehr Transparenz“ und „bessere Planbarkeit“. Das bedeutet, die monatliche Frage aus dem Management: „Wann sind wir fertig?“ so präzise wie möglich zu beantworten. Auch wenn die IT sich entschieden hat mit Scrum-Methodik zu entwickeln, dann wollen die Stakeholder trotzdem wissen, wann was fertig wird.

Der Wunsch nach präzisen Fertigstellungsangaben ist Angst des Managements vor Kontrollverlust. Denn auch im Management sitzen Menschen, deren Job von den Ergebnissen des Projekts abhängen. Oft sind es auch die berechtigte Interessen von Kunden, die gerne ganz genau wissen wollen, wann das Projekt „fertig“ ist. Kunden sind – vielmehr noch als das Management – ungeduldig und haben wenig Verständnis für vage Aussagen bezüglich eines Launch-Termins. Selbst dann, wenn sie selbst wiederholt zu Verzögerungen beitragen, durch Änderungswünsche oder unklare Aufgabenstellung, ist mit Einsicht und Nachsicht auf Kundenseite selten zu rechnen.

Um dieses Dilemma zu lösen, und weil wir selbst als Abteilungsleiter von der Geschäftsführung um „bessere Planung“ gebeten wurden, haben wir eine Methode entwickelt, die aus Scrum-Werkzeugen eine Roadmap-artige Übersicht für das Management und für Kunden generiert. Es ist eine Abbildung, eine Übersetzung in die Sprache der Stakeholder. Damit können sie umgehen. Nicht zuletzt hilft die Methode auch überzeugten Scrum-Befürwortern, rechtzeitig Scope und Termine zu steuern.

Überraschung: es ist ein Gantt-Chart.

Überraschenderweise hält das Werkzeug-Portfolio bereits im Standard-Scrum alles bereit, um ein Gantt-Chart zu erstellen. Sogar ein Gantt-Chart, das alle Anforderungen von Gantt-Chart-verwöhnten Stakeholdern erfüllt. Noch besser: Die Erzeugung des Gantt-Charts kann automatisiert werden. Sie kostet im Scrum Prozess nichts. Das Ergebnis ist ebenso genau, wie die bekannten Gantt-Charts in der klassischen Projektplanung. Es dient der Transparenz gegenüber Management und Kunden, es erzeugt ein Gefühl der Übersicht, der Steuerbarkeit und möglicher Einflussnahme. Es beruhigt die Kontrollverlustnerven und hebt die Stimmung zwischen den Lagern der klassischen Projektplaner und der agilen Gemeinde. Damit erfüllt es eine wichtige Funktion im Scrum. Gleichzeitig fördert das Gantt-Chart die Akzeptanz von Scrum durch wichtige Stakeholder (Management).

Scrum ist Change und Menschen sind bequem, egal in welcher Hierarchieebene

Denn wie bei jedem Change-Prozess, gibt es auch bei der Einführung von Scrum Widerständler, die sich dem Wandel zunächst verschließen. Diese zu ignorieren, ist keine Lösung. In jedem Change-Prozess müssen wir Methoden finden, damit alle Betroffenen den Wandel akzeptieren und mittragen. Deshalb müssen die Initiatoren und Treiber des Wandels, die anderen Betroffenen mitnehmen, mit ihnen kommunizieren, den Zweiflern und Widerständlern mit Offenheit und Angeboten begegnen.

Dieses Scrum/Gantt Chart ist ein Angebot.

Wir haben ein Gantt-Chart entwickelt, das als Reporting-Tool, als Kommunikationstool, nicht als Planungstool eingesetzt wird. Die Planung ist und bleibt agil, also Scrum oder Kanban. Es ist ein Angebot an die Stakeholder, es ihnen zu erleichtern, mit der agilen Entwicklung klarzukommen, es zu verstehen und zu akzeptieren.

Anleitung: Wie aus dem Backlog und Burndown ein Gantt-Chart wird

Warnung: Die folgende Anleitung wendet sich an praxiserprobte agile Productowner. Wem die Fachbegriffe im Scrum nicht geläufig sind, wird Schwierigkeiten haben, alles zu verstehen.

Aus Scrum-Daten ein Gantt-Chart zu erstellen, ist sehr einfach. Jede geschätzte Scrum User Story hat Story Points. Die Story Points entstehen ganz normal wie bisher im Scrum Prozess. Aus vorangegangenen Sprints ist die Velocity (Story Points pro Sprint) bekannt. Die bisherige Velocity wird auch für die Zukunft angenommen.

Dann berechnet man für jede Story in welchem Sprint sie fertig wird und markiert den Sprint im Kalender. Done.

Daraus ergibt sich ein Backlog mit zusätzlichen Kalenderspalten in denen jeweils die Felder markiert sind, in denen eine Story in Arbeit ist und/oder fertig wird.

Das Scrum-Gantt sieht dann so aus:

Aus einem Scrum-Backlock ein Gantt-Chart machen

Aus einem Scrum-Backlock ein Gantt-Chart machen

Bonus: Zusätzliche Ideen aus der Praxis

  • Abgeschlossene, „in Arbeit“ und zukünftige Stories farblich unterscheiden.
  • Zukünftige Velocity = letzte Velocity modifiziert durch Sondereffekte wie Urlaub.
  • Ein zusätzliches Datumsfeld je Story, das angibt, für wann ein Feature dem Kunden/Management „versprochen“ wurde (Soll-Datum). Das Datum wird im Kalender markiert. Soll/Plan/Ist-Angaben helfen der Transparenz.
  • Epic Stories weiter unten im Backlog können auch mal über mehrere Sprints gehen.
  • Zusätzlich zur Scrum-Beschreibung der Story (Wer, Was, Warum) kann man einen kurzen Titel/Namen der Story vergeben. Das hilft der Übersichtlichkeit im Gantt-Chart.
  • Bewährt hat sich eine eigene Hintergrundfarbe für Releases. Das sind oft Gruppen von Stories, die aus einem Epic hervorgegangen sind. Damit kann man Stories zu „Releases“ oder „Milestones“ gruppieren.

Call to Action:

  • Wenn Sie in Ihrem Unternehmen Scrum eingeführt haben, und Sie als Teil des Managements, gerne mehr über das Scrum/Gantt Chart wissen möchten, kontaktieren Sie uns gerne per Email unter team@lupuslabs.de
  • Wenn Sie in Ihrem Unternehmen Scrum eingeführt haben, und Sie als Teil des Scrum-Teams, die Forderung von Stakeholdern nach besserer Planbarkeit kennen, und das Problem gerne lösen würden, und deshalb mehr über das Scrum/Gantt Chart wissen möchten, kontaktieren Sie uns gerne per Email unter team@lupuslabs.de
  • Wenn Sie in Ihrem Unternehmen Scrum einführen möchten und erfahrene Coaches, auch auf Management-Ebene, für die Einführung von Scrum, Kanban suchen, dann kontaktieren Sie uns gerne per Email