Agile Entwicklungsteams sind niemals vollkommen frei von der Notwendigkeit eine mittel- bis langfristige Planung aufzustellen. Das ist auch sinnvoll und nachvollziehbar, denn manche Maßnahmen, die parallel zur Entwicklung aufgesetzt werden, können nicht sprintweise, sondern nur langfristig geplant werden. Beispielsweise wartet eine Messe nicht auf einen funktionierenden Prototypen, bis sie beginnt. Auch lassen sich regulatorische Anforderungen nicht einfach verschieben, weil andere Tasks wichtiger waren. Die Liste derartiger Beispiele kann beliebig erweitert werden.

Nun ist es aber keine Zielsetzung, dass zu den bekannten Ritualen von agilen Entwicklungsteams ein weiteres hinzukommt, in welchem sprintweise detaillierte Planungsarien durchgeführt werden.

Eine schöne Methode zur langfristigen Planung in Form von Roadmaps stellt uns das scalable agile Framework (SAFe) zur Verfügung. Darin planen Teams ihre Tätigkeiten in sogenannten Releasetrains. Die Methode dient eigentlich dazu, Teams mit heterogenen Vorgehensmodellen eine Synchronisation ihrer Tätigkeiten zu ermöglichen. Denkbar ist bspw. die Zusammenarbeit von agilen Entwicklungsteams mit einer Wasserfall-orientierten Entwicklungseinheit.

Die Idee der Releasetrains bietet aber auch im homogenen agilen Kontext eine sehr einfache Möglichkeit Roadmaps auf einem hohen Aggegrationslevel (z.B. auf Themen- oder EPIC-Ebene) zu erstellen und über mehrere Teams zu synchronisieren. Jedes Team besetzt dabei einen Train. Alle Trains vereinbaren, sich in einem bestimmten Takt (Releases) zu synchronisieren (z.B. alle 8 Wochen). Dabei ist der gedankliche Bahnhof, also das Release, nicht unbedingt als Produktionsrelease gedacht, sondern kann ebenso als einfacher fachlicher Synchronisationspunkt vereinbart werden.

Im Falle von agilen Teams könnten bspw. bei einem Releasetakt von 8 Wochen 4 Sprints geplant werden. Ein sehr einfacher Schachzug des Planungsansatzes besteht darin, nur 3 von den tatsächlichen 4 Sprints zu planen. So bleibt pro Team immer ein Puffer von einem Sprint. In erster Linie können in den Puffersprints technische Schulden abgebaut werden. Gleichzeitig entsteht aber ein einfaches Mittel gegen Fehlplanungen, da der Puffersprint natürlich auch zum Aufholen bisher nicht abgeschlossener Stories genutzt werden kann.

Die Themen und EPICs sollten bewusst nicht auf eine Storyebene herunter gebrochen oder mit Storypoints versehen werden. Es reicht eine Allokation der Themen zwischen einem oder mehreren Releases. So lassen sich alle Themen inkl. etwaiger Abhängigkeiten über die Teams hinweg planen und miteinander synchronisieren. Diese Aggregationsebene der Planung ist leicht erfassbar und vergleichbar.

Viel weiter braucht man auf einer Roadmap dieser Art nicht gehen. Es geht um Orientierung, nicht um Detailplanung! Es muss für alle Empfänger erkennbar sein, wann zentrale Themen abgebildet werden können. So springt am Ende mit der Roadmap auch für das Entwicklungsteam ein zusätzliches Artefakt zwischen dem refinten Backlog und der Vision heraus, welches gute Orientierung für die zukünftigen Aufgaben gibt.

Kai Ebenrett, Chief Business Development Officer