Langfristige Produktplanung und Agilität

Ein wichtiges Argument für agile Entwicklung ist, dass man flexibel auf Änderungen der Umstände reagieren kann. Viele Manager befürchten allerdings, dass sie diesen Vorteil auf Kosten der Planbarkeit erkaufen müssten. Gerade bei Produkthäusern verlangen Kunden und Investoren möglichst zuverlässige Aussagen, wann welche neuen Produktmerkmale oder Marktstrategien zur Verfügung stehen. Stört hier agile Entwicklung?

Ich meine, dass agile Planungspraktiken ganz im Gegenteil sogar helfen, solche langfristigen Planungsaussagen nicht nur zu treffen, sondern dann auch noch einzuhalten. Allerdings muss man dafür eine zusätzliche Planungsebene einführen, nennen wir sie strategische Planung (oder Roadmap, falls Ihnen Anglizismen besser gefallen). Anders als alle anderen Planungsebenen in einem agilen Vorhaben, geht der Horizont der strategischen Planung nicht nur über die anstehende Iteration, sondern über die nächsten 18 oder 24 Monate – mehr ist in der Regel nicht mehr seriös planbar.

Ein so langer Planungshorizont heißt natürlich auch, dass die Aussagen der strategischen Planung um so spekulativer werden, je weiter sie in der Zukunft liegen. Daher wird die Planung regelmäßig überarbeitet. Ich empfehle normalerweise, die Planung nach jedem Release zu überarbeiten, also Inhalte, Prioritäten und Annahmen über die Produktivität dem aktuellen Stand anzupassen, aber dazu gleich mehr.

Wie erstellt man eine Produktplanung? Zunächst unterscheidet sich die Technik nicht wesentlich von der Planung eines Releases, einer Iteration oder eines Sprints: Produktmanager, Vertrieb, Entwickler, Support und andere Beteiligte bringen Ihre Ideen ein, wie sich das Produkt weiter entwickeln soll. Dabei muss natürlich sichergestellt sein, dass auch die Bedürfnisse und Erfahrungen der Endanwender ausreichend Gehör finden, z.B. über sogenannte Anwender- oder Fokusgruppen. Meistens ist das die Aufgabe des Produktmanagements.

Wenn alle Aufgaben gesammelt sind, werden sie grob geschätzt und Abhängigkeiten ermittelt. Im Unterschied zu anderen agilen Planungsebenen wird die Aufgabe aber nicht in handliche (und leichter schätzbare) Brocken zerlegt, grobe Schätzungen des Aufwandes sind völlig ausreichend. Nun folgt die Priorisierung. Die Beteiligten legen, wie gewohnt, eine vollständige Reihenfolge fest, jeder Punkt bekommt also seinen Platz auf der „Hitliste“. Die vorderen Plätze sind dabei in der Regel heiß umkämpft, die Reihenfolge auf den hinteren Plätzen ist dagegen nicht so entscheidend: Bis diese Merkmale in die Realisierung gehen, wechseln sie ohnehin noch öfters ihre Position.

Um nun die „offizielle Planung“ zu bekommen, werden die Plätze auf die kommenden Releases verteilt, wobei jedes Release nur so weit „gefüllt“ wird, dass noch ausreichend Spielraum für ungeplante Tätigkeiten bleibt. Hierüber entzünden sich oft heftige Diskussionen. Ist der Prozess erst einmal eingeschwungen, kann man einfach die „Menge an geschätztem Aufwand“ für das nächste Release planen, die man im letzten Release aus der strategischen Planung umsetzen konnte (Velocity) – getreu dem Prinzip „Yesterday’s Weather„.

Habe ich zum Beispiel im letzten Release neue Produktmerkmale aus der Releaseplanung mit einem geschätzten Aufwand von 100 Punkten (oder Personentagen, je nach Schätzverfahren) zur Auslieferung gebracht, sollte ich für das nächste Release auch wieder 100 Punkte einplanen. Liegen bereits Daten über mehrere Releases vor, rate ich oft dazu, den gleitenden Durchschnitt über die letzten drei oder vier Releases zu verwenden, je nach Volatilität des Geschäfts. Dieses Verfahren führt automatisch dazu, dass ausreichend Puffer eingeplant ist für Fehlerbehebungen, Schätzfehler etc.

Liegen noch keine Erfahrungswerte vor, empfehle ich in der Regel ca. 20% der zur Verfügung stehenden Kapazitäten zu verplanen. Das führt zwar fast sicher zu erregten bis erzürnten Diskussionen, hat sich aber im Nachhinein oft als ganz gute Faustregel erwiesen. Und wenn die Zahl wirklich deutlich besser sein sollte, wird man es spätestens nach einem Release wissen.

Bis hierher ist das weitgehend Standardvorgehen bei agiler Planung. Spannend wird die Zuordnung für die weiteren Releases. Zwar könnte man stur für die folgenden Releases jeweils die gleiche Punktzahl wieder verteilen, doch ist das selten realistisch. Vielleicht soll das Team verstärkt werden, man erhofft sich von neuen Testverfahren weniger störende Fehler aus der Produktion, ein Standort soll geschlossen werden, und so weiter. Hier empfehle ich, verschiedene Szenarien aufzubauen. Ein Szenario unterstellt gleichbleibende Velocity, ein optimistisches Szenario unterstellt einen realistischen Anstieg, z.B. 5% pro Release, ein pessimistisches unterstellt zusätzliche unerwartete Schwierigkeiten und geht nur von 70 oder 80% der bisherigen Geschwindigkeit aus. Wer noch belastbarere Varianten braucht, muss in eine vollständige Szenarioanalyse investieren – ein Aufwand, der selten lohnt.

Mit diesen drei Varianten lassen sich realistische Möglichkeiten und voraussichtliche Termine recht gut abschätzen. Dies ist das Basismaterial, aus dem Management, Vertrieb oder Marketing Verlautbarungen an Kunden und Investoren ableiten können. Intern stellt die Planung aber die abgestimmte Version realistischer „Zukünfte“ dar. Wer nach außen mehr verspricht, als die Planung hergibt, kann anschließend nicht versuchen, die Verantwortung in Form von Überstunden und Wochenendarbeit auf andere abzuwälzen.

Die strategische Planung ist eine wichtige Quelle für die regelmäßigen Releaseplanungen, die dann von bereits deutlich besser verstandenen Ideen ausgehen. Nach jedem Release wird die strategische Planung aktualisiert und auf den neuesten Stand gebracht. Dies stellt sicher, dass sie auf dem Laufenden ist und den aktuellen Anforderungen entspricht.