Was ist agile Planung?

„Failing to plan is planning to fail“ oder zu Deutsch: Wenn Sie nicht ordentlich planen, planen Sie Ihr Versagen. Dieser Ausspruch vom Zeitmanagement-Experten Alan Lakein fasst die Bedeutung von Planung beim Projektmanagement perfekt zusammen. Wir mögen Termine und feste Rahmen vielleicht nicht, doch in vielen Unternehmen ist das Alltag und wir können nicht ignorieren, wie wichtig Planung ist.

Selbst, wenn wir uns außerhalb von Projekten mit festen Zeiten und Arbeitsumfängen bewegen und uns in die Produktentwicklung stürzen, ist Planung immer noch essenziell. Die meisten Kunden bewilligen keine Budgets für offene Spezifikationen und verlangen zum Angebot auch einen Liefertermin.

Wenn wir von dieser Lage ausgehen, fragen wir uns natürlich „Wie erstellen wir einen agilen Projektplan?“. Das ist eine schwierige Frage und die meisten Ressourcen zu diesem Thema behandeln nur Praktiken aus der Softwareentwicklung. So entsteht der Eindruck, Agile wäre nur für die Softwareindustrie geeignet, was überhaupt nicht den Tatsachen entspricht.

Agile Planung ist NICHT Scrum-Planung

In den meisten Artikeln im Internet zum Thema agile Planung wird behauptet, Scrum-Planung und agile Planung wären praktisch ein und dasselbe. Das ist einfach nur falsch. Scrum ist ein präskriptives Framework für die Softwareentwicklung, das einen konkreten Planungsweg zeigt. Es ist sehr beliebt in der Software-Welt, musste aber schon herbe Kritik einstecken.Wir werden nicht im Detail auf die Mängel der Scrum-Planung eingehen, sondern darüber sprechen, wie sich die Agile-Denkweise auf verschiedene Branchen und nicht nur Software anwenden lässt. Sie müssen vielmehr wissen, wie Sie allgemeine Techniken und Praktiken auf globaler Unternehmensebene unabhängig vom Geschäftsbereich anwenden können. Gerade sollten Sie nur wissen, dass die agile Planung nicht zwangsläufig das Scrum-Framework erfordert – ganz im Gegenteil.

Agile Projektplanung vs. traditionelle Projektplanung

In der Vergangenheit verbrachten Führungskräfte enorm viel Zeit mit der Erarbeitung detaillierter Pläne für Jahre im Voraus.

Lange Zeit funktionierte diese Art der Planung perfekt. Das Geschäftsumfeld ist in den letzten Jahrzehnten des 20. Jahrhunderts jedoch immer dynamischer geworden. Geschäftsanforderungen änderten sich häufiger und neue, flexiblere Planungsmethoden wurden benötigt.

Dieser Bedarf trat besonders und fast schon kritisch zutage, als die Wissensarbeit in den Vordergrund rückte. Während die Menschen noch vor 50 Jahren zumeist in Fabriken arbeiteten, wird heute ein Großteil der Arbeit in Büros verrichtet, wo die Menschen mehr Kopf als Hände gebrauchen. Und genau in der Wissensarbeit wird die agile Planung am meisten benötigt.

Der Hauptunterschied zwischen agiler Planung der herkömmlichen Methode (auch als Wassermodell bekannt) ist folgender: Agile ist iterative und passt sich an Veränderungen an, während Wasserfall ein schwerfälliger Schritt-für-Schritt-Prozess ist.Wir müssen an dieser Stelle erwähnen, dass beide Ansätze ihre Vorzüge haben. Wenn Sie eine Brücke oder ein Gebäude bauen, brauchen Sie einen detaillierten und durchdachten Plan. Hier wollen Sie keine agilen Elemente, zum Beispiel Änderungen der Anforderungen später im Prozess. Das kann natürlich vorkommen, doch diese Änderungen wären in der Umsetzung dann extrem teuer.

In der Wissensarbeit wird Veränderung jedoch in jeder Prozessphase begrüßt, sogar zum Ende hin. Ziel ist die Entwicklung einer Lösung, die den Kunden zufriedenstellt und alles ist erlaubt. Einfach gesagt erarbeiten Sie auch im agilen Projektmanagement detaillierte Pläne, jedoch für kürzere Zeiträume, und können bei Bedarf direkt Änderungen vornehmen.

Merkmale der agilen Planung

Zuerst besprechen wir die verschiedenen Ebenen, auf denen Sie planen können. Diese Ebenen werden am besten durch die „Zwiebel der Agile-Planung“ beschrieben:Sie müssen unbedingt verstehen, dass agile Planung auf jede Zwiebelschicht angewendet werden kann. Sie setzen Agile nicht nur auf Teamebene um (Tag, Iteration, Release). Sie können ein agiles Produktmanagement, ein agiles Portfoliomanagement und eine agile Strategie haben. Agilität in Ihrer Strategie ist sogar eigentlich das entscheidende Element der allgemeinen Unternehmensagilität. Wenn Sie Ihre Teams in Agile-Methoden geschult, jedoch noch keine Änderungen an Ihrem Management von Zielen und strategischen Initiativen vorgenommen haben, ist Ihr Unternehmen nicht agil.

Wie bereits gesagt ist agile Planung iterativ. Das bedeutet, dass Sie Ihren Plan mehrfach je nach Bedarf weiterentwickeln und anpassen. Ziel ist es, Zeit in die Planung zum bestmöglichen Zeitpunkt zu investieren und sich leicht an Änderungen anzupassen, die während der Ausführung auftreten.

Unabhängig von der Ebene, auf der Sie aktiv sind, weist Ihr Agile-Plan ähnliche Eigenschaften auf. Sehen wir uns diese einmal genauer an.

• Ziel aus Kundenperspektive (Wert)
• Wenige Details so lange wie möglich (so spät wie möglich binden)
• Häufige Auslieferungen (kleine Batch-Größen)
• Zeiträume statt fester Termine (Wahrscheinlichkeit vs. Determinismus)
• Fokus auf der Arbeit, nicht auf den Arbeitenden (keine Zuweisungen, das Team ist verantwortlich)
• Keine separaten Phasen für die Qualitätssicherung (Qualität ist integriert)
• Zweistufige Pläne (Zeitleisten für Initiativen, Aufgaben ohne Anfangs-/Enddatum)
• Datengetrieben (basierend auf historischen Daten und Monte-Carlo-Simulationen)

Ziel aus Kundenperspektive (Wert)

Bei einem agilen Plan muss unbedingt berücksichtigt werden, was genau der Kunde möchte. Wenn wir einen Begriff aus dem Lean-Wörterbuch ausleihen müssten, würden wir definitiv das Wort „Wert“ benutzen. Mit anderen Worten: Unser Plan muss genau angeben, wie und wann wir Wert für den Kunden schöpfen.

In dieser Hinsicht gilt: Je besser der Plan auf die Ergebnisse fokussiert ist, desto besser. Wenn Sie gelernt haben, Aktivitäten in den Plan zu setzen, denken Sie noch einmal darüber nach. Ist es Ihnen wirklich wichtig, was die Mitarbeiter tun, oder wollen Sie nur, dass der Plan erledigt wird?

Wenn das für Sie komisch klingt, noch eine kleine Frage zum Anstoß: „Kümmert es meinen Kunden, was der Designer zwischen 9 und 18 Uhr getan hat, wenn die Arbeit erledigt wurde?“ Ihre Kunden möchten bestimmt nicht hören, wie beschäftigt alle sind, wenn der Auftrag nicht fertig ist.

Wenige Details so lange wie möglich (so spät wie möglich binden)

Stellen Sie sich vor, Sie bereiten eine Expedition auf einen Berg im Hochgebirge vor, der noch nie zuvor erkundet wurde. Sie wüssten bestimmt einiges über ihn, hätten aber keine Details. Sie haben eine grobe Ahnung von der Dauer der Expedition, sodass Sie genug Lebensmittel und Wasser mitnehmen. Sie wüssten aber nicht, wo es Plätze zum Lagern gibt oder ob es diese überhaupt gibt.

Wenn das der Fall ist, wäre es dann sinnvoll, einen Plan mit Essenszeiten zu erstellen? Wahrscheinlich nicht. Sie würden erst einmal losklettern. Wenn Sie müde werden, suchen Sie nach einem gemütlichen Ort für das Basislager. Wenn Sie den Plan schon vorher detailliert ausarbeiten, essen Sie Ihr Abendbrot vielleicht mitten in einem reißenden Fluss, den Sie überqueren müssen.

Viele Projekte in der Wissensarbeit laufen genauso ab. Sie wissen vieles schon vor Projektbeginn, aber nicht genug, um jedes Element davon genau zu planen. Trotzdem bestehen viele Manager auf einem strengen und detaillierten Plan für jede Projektaufgabe. Interessanterweise zögern wir in unserem Alltag die Verpflichtung bis zum letztmöglichen Moment hinaus, während wir das bei unseren Projektplänen nie schaffen.

Häufige Auslieferungen und schnelle Feedbackschleifen (kleine Batch-Größe)

Projekte sind per Definition große Brocken Arbeit. Man ist jedoch nicht verpflichtet, alles auf einmal zu liefern. Die meisten Kunden wünschen sich sogar einen frühen Ausblick auf die Ergebnisse, um sicherzustellen, dass das Projekt nicht zu stark von den erwarteten Endergebnissen abweicht.

Nehmen wir einmal an, das Projektteam hat die Anforderungen falsch verstanden und erarbeitet etwas komplett Anderes als das, was Sie sich als Kunde vorgestellt haben. Möchten Sie dem Team lieber so früh wie möglich Feedback zukommen lassen oder bis zum Liefertermin warten? Es ist viel naheliegender, Feedback früh zu geben und Zeit- und Ressourcenverschwendung zu vermeiden.Ein agiler Plan sollte häufige Auslieferungen berücksichtigen und explizit das Einholen von Feedback vorschreiben. Natürlich muss das erhaltene Feedback auch für die nächste Planversion berücksichtigt werden, sodass die Wahrscheinlichkeit eines erfolgreichen Projektabschlusses steigt.

Zeiträume statt fester Termine (Wahrscheinlichkeit vs. Determinismus)
Wenn Kunden nach der Projektdauer fragen, erwarten sie für gewöhnlich einen festen Termin. Sie wären jedoch überrascht, wie viele Kunden auch einen Zeitraum anstelle eines einzigen Datums akzeptieren.

Wenn der Zeitraum vernünftig ist, werden die meisten vernünftigen Menschen der Schätzung zustimmen. Wie heißt es so schön? Besser grob richtig als genau falsch. Das möchten wir allen ans Herz legen – arbeiten Sie mit Zeiträumen basierend auf historischen Daten und Prognosemethoden, um Ihren agilen Plan zu erstellen.

Fokus auf der Arbeit, nicht auf den Arbeitenden (Verantwortung beim Team)

Dieses Merkmal kommt aus derselben Stoßrichtung wie das Beispiel zur Bindung. Wenn Sie Ihren Leuten zu früh Aufträge zuweisen, riskieren Sie, dass sie zur falschen Zeit das Falsche tun. Wichtig ist der Fluss der Arbeit und nicht die maximale Auslastung aller Arbeitenden; es ist also okay, wenn sich die Menschen im Team selbst organisieren, um das Projekt auszuliefern.Es ist höchstwahrscheinlich der Fall, dass Sie Spezialisten im Team haben, die für eine Menge Abhängigkeiten sorgen – besonders in größeren Unternehmen. Die naheliegende Antwort eines Agile-Coachs wäre die Beseitigung der Abhängigkeiten, aber das hat mit der Praxis wenig zu tun. Sie können nicht einfach alle Abhängigkeiten abschaffen, ohne an anderer Stelle für eine Menge Probleme zu sorgen.

Vernünftig wäre es dagegen, die Abhängigkeiten aus der ganzheitlichen Sicht Ihres Unternehmens und der Wertströme zu handhaben. Wenn der Wertschöpfungsstrom zum Kunden durch Team X blockiert ist, sollten Sie sich darauf konzentrieren – auch wenn Team Y dann nichts zu tun hat. Das ist etwas radikal und erfordert ein Umdenken, ist jedoch ein essenzieller Gedanke in Agile und Lean. Wir müssen wohl nicht erwähnen, dass Ihr Plan in solchen Situationen den Fokus auf der Behebung des Blockers/Problems wiedergeben muss und weniger Fokus auf der Mitarbeiterauslastung liegt.

Keine separaten Phasen für die Qualitätssicherung (Qualität ist integriert)

Toyota wurde innerhalb von 50 Jahren vom kleinen Familienunternehmen zum größten Autohersteller. Einer ihrer Grundsätze war „Qualität einbauen“ – also keine Zeit mit der Produktausbesserung verbringen, nachdem dieses die Produktionslinie verlassen hat.

Sie sollten während der Projektausführung nach derselben Qualität streben und möglichst eine abschließende Phase der „Qualitätssicherung“ vermeiden. Wenn Sie zum Schluss eine große Qualitätssicherung brauchen, haben Sie die Qualität während des Projekts wahrscheinlich vernachlässigt und in der Qualitätsphase werden die Dinge bald nicht mehr so rosig aussehen.

Natürlich ist es immer besser, einen Qualitätscheck zu machen, statt mangelhafte Produkte auszuliefern, aber das sollte eher die Ausnahme als die Regel sein. Unter normalen Bedingungen sollten endgültige Qualitätsprüfungen gar nicht nötig sein, da sich die beteiligten Teams bereits während der Projektlaufzeit um diese Maßnahmen gekümmert haben.

Zweistufige Pläne (Zeitleisten für Initiativen, Aufgaben ohne Anfangs-/Enddatum)

Das ist eines der wichtigsten Merkmale eines guten und effektiven Agile-Plans. Wenn Sie einen übergeordneten Plan aller wichtigen Projektelemente (Initiativen) haben, können Sie diese leicht in Aufgaben zerlegen und den Teams zur Umsetzung weiterleiten.

Das klingt vielleicht trivial, doch ist es ein wesentlicher Unterschied zu den herkömmlichen Gantt-Diagrammplänen. Wenn Sie eine Initiative (Projektergebnis) in ihre Aufgaben aufschlüsseln, empfehlen wir, dabei keine Anfangs- und Endtermine festzulegen, wenn es nicht zwingend nötig ist.

Eine Aufgabe zur Erstellung von Plakaten für ein Konzert wäre beispielsweise nutzlos, wenn sie nach dem Konzert abgeschlossen würde; also braucht sie einen Endtermin. In den meisten Fällen haben Aufgaben jedoch keine wirkliche Lieferfrist.Wenn Sie keine Anfangs-/Endtermine für Einzelaufgaben festlegen, ermöglichen Sie Ihren Teams das Ziehen neuer Arbeit, wenn sie wirklich die Kapazität dafür haben und nicht, wenn sie sie haben sollten. ZIEHEN ist hier wörtlich gemeint und steht für das PULL-Prinzip, das wir von Toyota kennen.

Dadurch, dass Sie der Initiative einen Anfang und ein Ende zuweisen, untergeordnete Aufgaben jedoch frei bleiben, wird die Planung von der Umsetzung entkoppelt. Das sieht auf den Blick vielleicht nach einer dummen Idee aus, ist aber eigentlich sehr clever: Sie behalten einen Plan mit Fristen und Verbindlichkeit, doch Ihre Teams können die optimalen Entscheidungen treffen, da sie der Arbeit am nächsten sind.

Datengetriebene Entscheidungen (mit historischen Daten die Zukunft planen)

Wenn Sie das Tagesgeschäft Ihrer Teams mit der Kanban-Methode verwalten, können Sie ganz leicht statistische Methoden für die datenbasierte Prognose nutzen. Eine dieser Methoden, die sich breiter Verwendung in der Agile-Welt erfreut, ist die sogenannte Monte-Carlo-Simulation.

Monte-Carlo-Simulationen arbeiten mit historischen Daten (Durchsatz und Zyklusdauer). Mithilfe mathematischer Algorithmen simulieren sie Tausende mögliche Ergebnisse für Ihr Projekt. Nach der Bewertung aller möglichen Ergebnisse liefert die Monte-Carlo-Simulation Informationen zu möglichen Abschlussterminen des Projekts und unterstützt die Prognosen durch Wahrscheinlichkeitsangaben.

Beispielsweise kann eine Monte-Carlo-Simulation eine Wahrscheinlichkeit von 85 % dafür prognostizieren, dass Ihr Projekt bis zum 2. Juli abgeschlossen wird. Alternativ kann die Prognose lauten, dass Sie bis zu Ihrer Frist mit 95 % Wahrscheinlichkeit mindestens 200 Aufgaben geliefert haben werden. Das verschafft Ihnen eine gute Übersicht zum Projektstatus, die vollständig auf Statistik basiert. So sparen Sie sich die Mühen, alle Aufgaben einzeln zu schätzen.

Tools wie Kanbanize by Businessmap verbinden diese Idee mit der vorigen (zweistufige Pläne) und schaffen ein kontinuierliches Prognosesystem, das Manager über den tatsächlichen Status aller Projekte und ihrer Leistungen informiert. Kanbanize by Businessmap erweitert diese Art der kontinuierlichen Prognose sogar bis auf Portfolio-Ebene, sodass Sie Echtzeitprognosen aller Projekte im Portfolio erhalten. Dafür müssen Sie nur die Tagesaufgaben in Kanban Team-Boards ausführen und diese mit den übergeordneten Projekten verknüpfen.

In Summary

Agile Planung ist eine neue, flexible Methode zur Organisation zukünftiger Projekte und zur Anpassung an veränderte Anforderungen, ohne Ressourcen zu verschwenden. Hier sind die wichtigsten Merkmale eines guten Agile-Plans:

• Ziel aus der Sicht des Kunden
• So wenig Details wie nötig so lange wie möglich
• Häufige Auslieferung
• Zeiträume statt fester Terminangaben
• Fokus auf der Arbeit, nicht auf den Arbeitenden
• Keine separaten Phasen zur Qualitätssicherung
• Zweistufige Pläne
• Datengetrieben