Es existieren viele Missverständnisse, über Agilität in der Produktentwicklung. Da gibt es die, die meinen, alles außer der Implementierung weglassen zu können: Wir dokumentieren nicht, wir testen nicht, alles ist jeder Zeit änderbar. Außerdem gibt es viel Menschen, die meinen, in der agilen Produktentwicklung werde nicht geplant.
„Heute sind wir mal ganz agil und machen einfach, ohne zu planen!“
Ein sehr häufig verbreitetes Missverständnis ist, dass agile Teams nicht planen. Dabei ist eher das Gegenteil der Fall: Agile Teams planen häufiger und mit mehr Beteiligten aber eben anders: Aktivitäten, die weiter in der Zukunft liegen, werden nur grob geplant, weil akzeptiert wird, dass Änderungen auftreten und neue Dinge gelernt werden die den Plan ändern werden.
Hier zuerst ein tabellarischer Vergleich:
| Prozesselement | Klassisch | Agil | Agile Prinzipien und Elemente |
| langfristige Planung | stabil. Es wird versucht, unter Unsicherheit abgegebene Terminversprechen, einzuhalten | grob, flexibel: Terminversprechen werden unter Vorbehalt und als Zeitraum gegeben, z.B. höchst wahrscheinlich im 3. Quartal des aktuellen Jahres), oder es werden nur Versprechen gegeben, die durch genügend Puffer auch gehalten erden können | Rolling-wave planning |
| kurzfristige Planung | stabil über Aufgaben | stabil über Ziele, aber flexibel in der Aufgabenplanung | Iterationsplanung |
| Planung des Umfangs (Scope) | stabil, komplexes Change Management | flexibel, inbesondere für fest vereinbarte Termine für Releases und Zulieferungen | fixed time, flexible scope |
| Wer plant | Projektleiter | Der Product Owner mit dem Team | |
| Terminplanung und Zusagen | durch den Projektleiter auf Basis von Schätzungen des einzelnen Projekts. Andere Projekte werden nicht berücksichtigt. | auf Basis der tatsächlichen Arbeitsgeschwindigkeit des Teams (Team Velocity) und des Clusters, die auch andere Projekte berücksichtigt | Zusagen auf evidence-based planning & velocity, see-the-whole |
| Häufigkeit der Planung | zu Beginn des Projekts. Komplexe und umfangreiche Pläne werden selten angepasst | Regelmäßige Planung jede Iteration. Feinplanung: Iteration Planning. Grobplanung: Cycle Planning. | Rolling-wave planning, Team-Sync, Team-Planning, Cluster-Sync, Cluster-Planning, Organisation-Sync, Portfolio-Planning |
Warum Planen wir?
Planung verfolgt zwei wichtige Grundbedürfnisse:
- Vorhersage: Wann können wir es liefern und was wird es kosten?
- Effizienz in der Umsetzung: Wann benötigen wir welche Ressourcen?
Die klassische Planung geht davon aus, dass vorab genau definiert werden kann, was geliefert werden soll (auch bekannt als „Scope“ oder Umfang), dass der Projektleiter relativ genau herausfinden kann, wie dies erreicht werden kann und welche Bearbeiter und Ressourcen wann und mit welchem Aufwand daran beteiligt werden müssen.
Wichtige Planungskriterien dabei sind …
- Die Größe (Umfang und Dauer) von Aktivitäten sollen bekannt sein, um den zu investierenden Aufwand frühzeitig zu ermitteln. Häufig basieren Festpreisangebote auf diesen Aufwandsschätzungen.
- Die Art und Größe von Aktivitäten bestimmt deren frühestmögliche Fertigstellung durch die limitierten Ressourcen und Bearbeiter
- Zeitpunkte von Zulieferungen zwischen Teams und Organisationen sollen bekannt sein, damit Aktivitäten geplant werden können, d.h. externe Ressourcen und Bearbeiter sollen erst zum Zeitpunkt der Zulieferung vorgehalten werden.
Das Problem ist, dass in der heutigen VUCA-Geschäftswelt (englische Abkürzung für Volatilität, Unsicherheit, Komplexität, Mehrdeutigkeit) häufig weder der Umfang einer Produktentwicklung, noch die beteiligten Bearbeiter/Experten vorab planbar sind, insbesondere, wenn die Spezialisierung immer mehr zunimmt und sich die beteiligten Rollen je nach verfolgter Option drastisch unterscheiden.
Wie entsteht Vorhersagbarkeit in agilen Vorgehensweisen?
Vorhersagbarkeit entsteht einmal dadurch, dass wir die Komplexität der Planung dadurch reduzieren, dass wir nicht in Individuen denken und planen, sondern in Teams. Der Trick dabei ist, nicht für jedes Projekt oder Arbeitspaket ein eigens dafür optimiertes Team zusammenzustellen, sondern die Projekte und Arbeitspakete an das am besten geeignete (und verfügbare) Team zu geben. Dies setzt voraus, dass die Teams vorher so aufgestellt wurden, dass sowohl die unterschiedlichen Projekte und Arbeitspakete einzelnen Teams zugewiesen werden können und dass andererseits die Teams dabei möglichst wenige Abhängigkeiten zu anderen Teams haben, d.h. dass sie die Projekte und Arbeitspakete ohne Hilfe von außen fertigstellen können. Die Kunst besteht hierbei in der Entwicklung einer Team-Struktur, die diese Anforderungen auch über einen längeren Zeitraum ermöglicht, also langlebige und stabile Teams ermöglicht.
Warum stabile Teams?
Stabile und selbstorganisierte Teams haben die Tendenz sich selbst zu verbessern, dadurch dass die Team-Mitglieder rein menschlich eine „eingeschworene“ Gemeinschaft bilden und sich die Arbeitsabläufe einspielen. Nach einer Einarbeitungsphase (Tuckman Team-Entwicklung, Cog’s Stages) bildet sich eine relativ stabile, vorhersagbare Team-Leistung heraus, die in der agilen Produktentwicklung als „Team Velocity“ bezeichnet wird. Mit dieser vorhersagbaren Team-Leistung lässt sich deutlich besser planen als mit Teams, die speziell für ein Projekt zusammenstellt wurden und dadurch in dieser Konstellation zum ersten mal zusammenarbeiten!
Wer plant und priorisiert, wer schätzt?
Prinzip der Gewaltenteilung: In der agilen Produktentwicklung wird das Priorisieren und das Schätzen des Aufwands getrennt. Dabei werden die Prioritäten und damit auch die planerische Reihenfolge durch den Product-Owner festgelegt. Die Schätzungen werden aber vom Team der Bearbeiter (Working-Team) durchgeführt.
Das Pull-Prinzip sorgt dafür, dass das Working-Team sich nicht systematisch überplant und überlastet. Das Prinzip der „gnadenlosen Transparenz“ sorgt dafür, dass das Working-Team nicht in die Bequemlichkeit abrutscht. Durch die Balance dieser beiden Prinzipien soll eine nachhaltige und vorhersagbare Arbeitsgeschwindigkeit entstehen (Sustainable Pace, Velocity). Eine Voraussetzung dafür ist aber eine gewisse Stabilität der Teams über die Zeit, so dass die Arbeitsgeschwindigkeit sich nicht schon alleine durch Team-Strukturänderungen schwankt (siehe oben).
Prinzip Evidence-based-Planning: Auf Basis der vorhersagbaren Arbeitsgeschwindigkeit und den vom Working-Team erstellten Schätzungen, kann der Product-Owner über die Prioritäten im Team-Backlog Vorhersagen von Lieferungen treffen und dadurch Lieferversprechen abgeben.
Agile Planung: Was, wie häufig und wer?
Prinzip: Rolling-wave Planning: „Rolling-wave Planning“ ist die Umschreibung für eine sich wiederholende Planung, die umso detaillierter durchgeführt wird, je näher die Ereignisse liegen (je näher, desto feiner). Wichtige Vorteile dabei sind, dass auf der einen Seite die großen, weiter weg liegenden Dinge nicht verloren gehen, aber auch nicht zu viel Planungsaktivitäten in sie investiert werden. Insbesondere in einer sich schnell ändernden Umgebung wäre das höchst ineffizient.
Diese Art der Planung wird auf allen Ebenen der Organisation gelebt. Die folgende Grafik verdeutlicht, welche Elemente (links), wie häufig (Mitte), auf welcher Ebene bzw, von wem (rechts) geplant wird. Dabei sind die Grenzen je nach Organisation und zu entwickelndem System/Produkt verschieden und verschwimmen dabei. Sehr klar sind die oberste und unterste Ebene: Das Produkt-Portfolio wird auf der obersten Ebene der Organisation geplant, die einzelnen Aufgaben auf der Ebene der Personen in den Teams.
Um auf Änderungen reagieren zu können und ein flussbasierendes System zu ermöglichen, muss die hierarchische zeitliche Abfolge von Jahresplanung, Quartalsplanung, Iterationsplanung und Tagesplanung genügend Spielräume freilassen. Das bedeutet, dass auf allen Ebenen Freiräume verbleiben müssen, um Verbesserungen und außerplanmäßige Aktivitäten und zu ermöglichen und auf Verzögerungen reagieren zu können. Die Größe der Spielräume kann dabei von Team zu Team stark unterschiedlich sein.
Die inhaltliche Hierarchie stellt bei der Planung sicher, dass die „oberen“ Elemente durch Verfeinerung in kleinere untere Elemente vollständig abgebildet werden. Dies wird z.B. auch in dem momentan viel beachteten OKR-Framework vorgesehen.
Abbildung der Prinzipien im P4-Framework
Das P4-Framework kann mit der häufigen Tatsache umgehen, dass einzelne Teams nicht alleine in der Lage sind ein komplettes Produkt zu liefern. Dies ist meist die Aufgabe der Cluster, die aus 3 bis 10 Teams bestehen. Die gesamte Organisation besteht wiederum aus mehreren Clustern, die das Portfolio aller Produkte betreut, entwickelt und ggf. herstellt.
- Auf Ebene der Teams
- Auf Ebene der Value Streams in einem Team-Cluster (insbesondere wenn mehrere Teams an der Produktentwicklung beteiligt sind)
- Auf Ebene der Organisation
Organisationsebene
Funnel: Neue Ideen für Produkte, Applikationen, Systeme, Funktionen, Plattformen, Module und Dienstleistungen sind jederzeit willkommen und werden bezüglicher deren Nutzen und Aufwand grob abgeschätzt. Die Priorität zur weiteren Bearbeitung entsteht primär durch den Quotient: Prio = Nutzen / Aufwand, wobei eindeutige Prioritäten entstehen sollen.
Refinement: Priorisierte Ideen werden während des laufenden Portfolio-Cycle verfeinert ausgearbeitet und ggf. mittels Durchstichen oder Studien in einem Team bewertet
Planung des nächsten Organisations-Cycles: Auf Basis der Ergebnisse des vorangegangenen Organisations-Cycles können Prioritäten angepasst werden. Die Arbeitsgeschwindigkeit der Organisation aus vorangegangenen Zeiträumen (aka „Organisations-Velocity“) ergibt die Grundlage damit die Cluster der Organisation (vertreten durch die Cluster-System-Engineers) nur so viele Portfolio-Backlog-Items in den nächsten Org-Cycle ziehen, wie sie sinnvollerweise schaffen können. Das bedeutet, dass Dinge die mit hoher Wahrscheinlichkeit sowieso nicht bearbeitet werden können, auch nicht angefangen werden. Während der Planung des nächsten Organisations-Cycles werden auch die Abhängigkeiten und Zulieferungen zwischen den Cluster berücksichtigt.
Regelmäßige Prüfung und Anpassung der Planung: Während der Organisations-Cycle läuft, werden Änderungen der Planung im Organisation-Sync vorgenommen, wenn sie sich durch Erkenntnisgewinn ergeben.
Cluster-Ebene (Value Stream oder Systemebene)
Refinement: Priorisierte Cluster-Backlog-Items werden während des laufenden Cluster-Cycles verfeinert ausgearbeitet.
Planung des nächsten Cluster-Cycles: Auf Basis der Ergebnisse des vorangegangenen Cluster-Cycles können Prioritäten angepasst werden. Die Arbeitsgeschwindigkeit des Clusters aus vorangegangenen Zeiträumen (aka „Cluster-Velocity“) ergibt die Grundlage damit die Teams des Clusters (vertreten durch die Team-System-Engineers) nur so viele Cluster-Backlog-Items in den nächsten Cluster-Cycle ziehen, wie sie sinnvollerweise schaffen können. Das bedeutet, dass Dinge die mit hoher Wahrscheinlichkeit sowieso nicht bearbeitet werden können, auch nicht angefangen werden. Während der Planung des nächsten Cluster-Cycles werden auch die Abhängigkeiten und Zulieferungen zwischen den Teams berücksichtigt.
Jeder Cluster reserviert einen Teil seiner Kapazität für ungeplante, kurzfristige Dinge, sowie für Verbesserungsmaßnahmen aus dem Cluster-Improvement-Backlog.
Regelmäßige Prüfung und Anpassung der Planung: Während der Cluster-Cycle läuft, werden Änderungen der Planung im Cluster-Sync vorgenommen, wenn sie sich durch Erkenntnisgewinn ergeben.
Team-Ebene
Refinement: Priorisierte Team-Backlog-Items werden während der laufenden Iteration verfeinert ausgearbeitet.
Planung der nächsten Iteration: Auf Basis der Ergebnisse der vorangegangenen Iteration können Prioritäten angepasst werden. Die Arbeitsgeschwindigkeit des Teams aus vorangegangenen Zeiträumen (aka „Team-Velocity“) ergibt die Grundlage damit die Mitglieder des Working-Teams nur so viele Team-Backlog-Items in die nächste Iteration ziehen, wie sie sinnvollerweise schaffen können. Das bedeutet, dass Dinge die mit hoher Wahrscheinlichkeit sowieso nicht bearbeitet werden können, auch nicht angefangen werden. Während der Planung der nächsten Iteration werden auch die Abhängigkeiten und Verfügbarkeiten der Team-Mitglieder berücksichtigt.
Jedes Team reserviert einen Teil seiner Kapazität für ungeplante, kurzfristige Dinge, sowie für Verbesserungsmaßnahmen aus dem Team-Improvement-Backlog.
Regelmäßige Prüfung und Anpassung der Planung: Während die Iteration läuft, werden Änderungen der Planung im Team-Sync vorgenommen, wenn sie sich durch Erkenntnisgewinn ergeben.
Fazit
Die Beispiele zeigen , dass in agilen und pragmatischen Organisationssytemen und Frameworks, wie P4-Dev, unterschiedlich und häufiger geplant wird und dabei eine größere Anzahl an Personen in die Planung involviert werden. Insbesondere auf der Team-Ebene vermischt sich die Planungsaktivität mit der inhaltlichen Arbeit, z.B. wird während der Planung bereits an möglichen Konzepten gearbeitet, oder durch neue Erkenntnisse wird während der Arbeit, die Planung angepasst.
Bild von pch.vector auf freepik.com