Agile und Gantt-Diagramme: So nutzen Sie beide zusammen

Ja, sie koexistieren. Hier ist die ehrliche Antwort

Stellen Sie einem Scrum-Puristen und einem Lieferverantwortlichen dieselbe Frage, und Sie erhalten gegensätzliche Antworten. Der Purist sagt, ein Gantt-Diagramm sei verkleideter Wasserfall. Der Verantwortliche sagt, ein Backlog könne einem Kunden nicht sagen, wann die Funktion erscheint. Beide haben halb recht. Ein Gantt-Diagramm und Agile sind keine Rivalen, sie arbeiten auf unterschiedlichen Höhen. Agile steuert die tägliche Arbeit innerhalb jedes Sprints. Ein Gantt beschreibt die Form des Release über den Sprints: die Phasen, die harten Termine und die Übergaben zwischen Teams, die kein einzelnes Backlog zeigen kann.

Der eigentliche Fehler ist, ein Werkzeug zu zwingen, beide Aufgaben zu erledigen. Planen Sie einen zweiwöchigen Sprint auf einem Gantt, und Sie zeichnen es jeden Morgen neu, während die Storys wandern. Versprechen Sie einen Starttermin allein aus einem Backlog, und Sie raten bei der Velocity. Setzen Sie jedes Werkzeug dorthin, wo es passt, und die alte Spannung verschwindet still.

Zwei Werkzeuge, zwei Höhen

Ein Board und ein Backlog sind für den Fluss gebaut. Sie beantworten, was ein Team als Nächstes ziehen sollte, was heute blockiert ist und wie viel im aktuellen Sprint übrig ist. Sie sind bewusst blind für Kalendertermine, denn Termine sind nicht die Art, wie ein Sprint gesteuert wird. Ein Gantt ist für die Zeit gebaut. Es beantwortet, wann eine Phase beginnt, welche Teams fertig sein müssen, bevor ein anderes anfangen kann, und ob das Release noch zum versprochenen Termin landet.

Beachten Sie, dass sich die Spalten kaum überschneiden. Genau darum geht es. Sie wählen nicht zwischen ihnen, Sie decken zwei verschiedene Fragengruppen ab.

Die drei Schichten eines agilen Plans

Eine gesunde agile Lieferung läuft auf drei Schichten, und nur eine davon ist der Sprint. Sie getrennt zu halten, ist das, was ein Gantt und ein Board nebeneinander leben lässt, ohne sich in die Quere zu kommen.

• Roadmap-Schicht. Quartale und Themen. Was in diesem Halbjahr zählt und ungefähr in welcher Reihenfolge. Das ist eine Strategiesicht, kein Zeitplan.
• Release-Schicht. Hier lebt das Gantt. Ein einzelnes Release ist eine Reihe von Phasen über mehrere Sprints hinweg, mit echten Terminen, Meilensteinen und teamübergreifenden Abhängigkeiten. Hier verpflichten Sie sich gegenüber Kunden.
• Sprint-Schicht. Das Board und das Backlog. Storys, Punkte, täglicher Fluss. Schätzungen ändern sich hier ständig, und das ist in Ordnung, denn die Schicht darüber fängt die Schwankung auf.

Wenn jemand sagt, Gantt-Diagramme töten die Agilität, meint er meist, dass jemand versucht hat, die Sprint-Schicht auf einem Gantt zu führen. Heben Sie das Gantt auf die Release-Schicht, und der Einwand verfliegt.

Was ein Gantt leistet, das ein Backlog nicht kann

Ein Backlog ist eine flache, nach Priorität sortierte Liste. Es ist hervorragend im Ordnen der Arbeit und miserabel in drei Dingen, von denen ein Release abhängt. Erstens teamübergreifende Abhängigkeiten. Wenn das API-Team ein Gateway liefern muss, bevor das App-Team den Checkout bauen kann, ist diese Beziehung im Backlog beider Teams unsichtbar, aber als Abhängigkeit auf einem Gantt offensichtlich. Zweitens harte Fristen. Eine Messe, eine Vertragsklausel oder ein regulatorischer Termin ist ein fester Punkt, den ein Backlog schlicht nicht abbildet. Drittens die Release-Sicht: ein einziges Bild, das einem Stakeholder die gesamte Spanne vom Entwurf bis zum Start zeigt.

Ein Backlog sagt einem Team, was als Nächstes zu tun ist. Ein Gantt sagt der Organisation, ob die Summe all dieser Arbeit pünktlich ankommt. Das sind nicht dieselben Fragen, und ein Release-Plan braucht beide beantwortet.

Ein Gantt für das Release, Sprints für das Detail nutzen

Das funktionierende Muster ist die Planung in rollenden Wellen. Sie zeichnen das Release-Gantt auf der Ebene von Phasen und Epics, grob ein Balken pro Epic oder pro Sprint, nicht ein Balken pro Story. Der kurze Zeitraum ist detailliert, weil Sie ihn kennen. Der ferne Zeitraum ist ein grober Block, weil Sie ihn ehrlich gesagt noch nicht kennen, und etwas anderes vorzugeben ist genau, wie Gantt-Diagramme zu ihrem schlechten Ruf kommen.

In jedem Sprint plant das Team seine Storys wie gewohnt auf dem Board. Daran ändert sich nichts. Was sich ändert, ist, dass Sie am Ende des Sprints den passenden Balken im Gantt aktualisieren: Ist das Epic fertig geworden, verrutscht oder geschrumpft? Das Gantt ist kein zweiter Ort, um Aufgaben zu verwalten. Es ist eine Linse, die acht Wochen Sprint-Ergebnisse in eine einzige Antwort zum Release-Termin verwandelt. Schätzen Sie die groben Balken mit der echten Velocity Ihres Teams, nicht mit Wunschrechnerei, und lesen Sie unseren Leitfaden zum Schätzen von Dauern, bevor Sie die Termine festlegen.

Praxisbeispiel: Release 2.0 über vier Sprints

Ein Payments-Team verpflichtet sich, in acht Wochen einen Self-Service-Checkout zu liefern, vier Sprints zu je zwei Wochen. Das Board führt die Storys. Das Gantt führt das Release. So bilden sich die Epics auf die Sprints ab und so liegt das Risiko.

Die Kette, die Ihren Termin festlegt

Im Beispiel oben ist die Folge Gateway, dann Checkout, dann Start der längste Pfad abhängiger Arbeit. Alles andere, etwa die parallel laufenden Betrugsregeln, hat Spielraum. Diese längste Kette ist Ihr kritischer Pfad, und sie ist das Einzige, das den Starttermin wirklich festlegt. Die Betrugsregeln könnten ein paar Tage verrutschen und das Release erscheint trotzdem. Das Gateway nicht.

Hier verdient ein Gantt seinen Platz in einem agilen Umfeld. Velocity-Diagramme sagen Ihnen, wie schnell ein einzelnes Team vorankommt. Sie können Ihnen nicht sagen, welcher von vier parallelen Arbeitsströmen das ganze Release in Geiselhaft nimmt. Der kritische Pfad kann es, und er lässt Sie Ihre Aufmerksamkeit dort einsetzen, wo ein Verrutschen Sie tatsächlich den Termin kostet, statt die Sorge gleichmäßig über alle Teams zu verteilen.

Häufige Einwände, ehrliche Antworten

Der Widerstand ist vorhersehbar, und das meiste davon ist berechtigt, wenn ein Gantt falsch eingesetzt wird. Hier sind die Einwände, die ein Scrum-Team vorbringen wird, und die ehrliche Antwort auf jeden.

Keiner dieser Einwände übersteht den Kontakt mit einem Gantt, das auf der richtigen Höhe gehalten wird. Fast alle sind in Wahrheit Beschwerden über Gantts, die auf der falschen gehalten werden.

So bauen Sie ein Release-Gantt an einem Nachmittag

Sie brauchen kein schwergewichtiges Werkzeug und keine Zertifizierung. Sie brauchen die Epics, die Termine, zu denen Sie sich bereits verpflichtet haben, und eine Stunde mit den Teamleitungen. Hier ist die Reihenfolge.

1. Listen Sie die Epics für dieses Release auf, nicht die Storys. Streben Sie fünf bis zwölf Balken an.
2. Markieren Sie zuerst die festen Termine: Start, Demos, Vertragsfristen. Das sind Meilensteine, als Rauten gezeichnet, und sie bewegen sich nicht.
3. Bemessen Sie jedes Epic in Sprints anhand Ihrer echten Velocity und setzen Sie es dann auf die Zeitachse.
4. Zeichnen Sie die Abhängigkeiten zwischen Epics ein, besonders die, die Teams kreuzen. Das ist der wertvollste Schritt.
5. Finden Sie die längste Kette abhängiger Epics. Das ist der Pfad, den Sie verteidigen.
6. Bestimmen Sie einen Verantwortlichen, der das Diagramm bei jeder Sprint-Review aktualisiert, und sonst nirgends.

Öffnen Sie einen leeren Plan im Gantt-Editor, fügen Sie eine Zeile pro Epic hinzu, verknüpfen Sie die Abhängigkeiten, und Sie haben in unter einer Stunde eine Release-Sicht. Halten Sie das Story-Detail auf Ihrem Board, wo es hingehört.

Halten Sie es leicht, sonst stirbt es

Der größte Grund, warum ein Gantt in einem agilen Team scheitert, ist Gewicht. Jemand baut ein schönes Diagramm mit hundert Zeilen, es veraltet innerhalb eines Sprints, und das Team schließt daraus, dass Gantt-Diagramme nicht funktionieren. Nicht das Diagramm ist gescheitert, sondern die Granularität. Ein Release-Gantt sollte klein genug sein, dass eine Person es bei der Sprint-Review in zehn Minuten aktualisiert, indem sie ein paar Balken zieht und einen Termin verschiebt.

Verfolgen Sie das Release so, wie Sie jeden Plan gegen die Realität verfolgen, indem Sie vergleichen, wo Sie gesagt haben, dass jedes Epic sein würde, mit dem, wo es tatsächlich gelandet ist. Ein schneller Baseline-Abgleich bei jeder Review sagt Ihnen, ob der Termin abdriftet, lange bevor daraus eine Krise wird. Ein Gantt-Diagramm, das einmal gebaut und nie angefasst wird, ist kein Plan, es ist ein Wunsch. Aktualisieren Sie es oder löschen Sie es, aber lassen Sie es nicht auf einem geteilten Laufwerk verrotten und vorgeben, die Wahrheit zu sein.

Wann Sie das Gantt ganz weglassen sollten

Ehrlichkeit schneidet in beide Richtungen. Nicht jedes agile Vorhaben braucht ein Gantt, und eines dort hinzuzufügen, wo es nichts einbringt, ist nur Ballast. Wenn Ihre Arbeit ein stetiger Fluss kleiner, unabhängiger Elemente ohne externen Termin und ohne teamübergreifende Übergaben ist, reicht ein Board. Ein reines Wartungsteam, eine Support-Warteschlange oder ein einzelnes Squad, das täglich in Produktion liefert, gewinnt wenig durch eine Release-Schicht, weil es kein Release zu formen gibt.

Greifen Sie zum Gantt, wenn drei Signale gemeinsam auftreten: ein fester externer Termin, den Sie versprochen haben, mehr als ein Team, dessen Arbeit von der eines anderen abhängt, und ein Stakeholder, der die ganze Spanne auf einmal sehen muss. Wenn alle drei vorhanden sind, lässt das Backlog echte Fragen offen und das Gantt beantwortet sie. Wenn keines vorhanden ist, lassen Sie es mit reinem Gewissen weg und lassen Sie das Board seine Arbeit tun.

Häufige Fragen

Passend dazu

• Die Methode des kritischen Pfads erklärt
• Aufgabenabhängigkeiten erklärt
• Meilensteine und Aufgaben
• Zurück zu den Ratgebern

Dieser Artikel ist auch auf Englisch verfügbar.