Agile Roadmaps: Aufbauen, Teilen, Verwenden, Weiterentwickeln

Zusammenfassung: Eine Produkt-Roadmap ist ein Projektplan, der vorgibt, wie sich ein Produkt oder eine Lösung über die Zeit entwickelt. Produktinhaber verwenden Roadmaps zur Skizzierung der zukünftigen Produktfunktionen und der Release-Zeitpunkte neuer Features. In der agilen Entwicklung bietet eine Roadmap Kontext rund um die alltäglichen Aufgaben des Teams und sie sollte auf Verschiebungen in der Wettbewerbsumgebung reagieren.

Die Vorstellung, dass die Agile-Entwicklung eine langfristige Planung ausschließt, ist der vielleicht größte Mythos seit dem Ungeheuer von Loch Ness. Eine Roadmap ist für ein Agile-Team ebenso wichtig wie für ein Team, das nach dem Wasserfallmodell arbeitet, weil sie Kontext rund um die alltäglichen Aufgaben des Teams liefert und auf Verschiebungen in der Wettbewerbsumgebung reagiert. Im Gegensatz zu dem legendären schottischen Wasserungeheuer ist eine gut ausgearbeitete Agile-Roadmap jedoch einfach zu finden und zu verstehen.

Eine Produkt-Roadmap ist ein Projektplan, der vorgibt, wie sich ein Produkt oder eine Lösung über die Zeit entwickelt. Product Owner verwenden Roadmaps zur Skizzierung der zukünftigen Produktfunktionen und der Release-Zeitpunkte neuer Features. In der agilen Entwicklung bietet eine Roadmap wichtigen Kontext rund um die alltäglichen Aufgaben des Teams und sie sollte auf Verschiebungen in der Wettbewerbsumgebung reagieren. Mehrere agile Teams können sich eine einzige Produkt-Roadmap teilen.

Beim Erstellen einer Roadmap berücksichtigen Produkteigentümer den Entwicklungsverlauf des Markts, die Wertversprechen und Entwicklungseinschränkungen. Sobald ein ausreichendes Verständnis dieser Faktoren gegeben ist, werden sie in der Roadmap als Initiativen und Zeitabläufe wiedergegeben. Nachfolgend findest du ein Beispiel für eine sehr einfache Roadmap, die für ein Produktteam erstellt wurde. Die Initiativen sind blau dargestellt, die Zeitabläufe mit roten Meilensteinmarkierungen gekennzeichnet.

Nachdem eine Roadmap aufgebaut ist, muss sie mit dem gesamten Produktteam geteilt werden, damit jeder die Vision und Ausrichtung versteht. In vielen Unternehmen erstellen Product Owner ihre Roadmaps in PowerPoint und Tabellenkalkulationen und versenden dann die Folien und Tabellen per E-Mail an das Team. Diese Strategie ist zwar gut gemeint, aber von Anfang an problematisch. Jedes Teammitglied hat seine eigene Kopie der Roadmap und es ist (gelinde gesagt) mühsam, alle auf dem Laufenden zu halten, falls und wenn sich die Roadmap ändert.

Wie kann der Product Owner sein Team also besser auf dem neuesten Stand halten? Ganz einfach.

Die meisten für diese Art von Dingen entwickelten Tools für die Zusammenarbeit benachrichtigen alle Projektteilnehmer automatisch, wenn sich die Roadmap ändert. (Falls dein Tool das nicht tut, ist es vielleicht an der Zeit, über ein neues Tool nachzudenken.)

Wenn du der Roadmap eine Initiative hinzufügst, berücksichtige die folgenden Fragen:

Bevor wir über dynamische Prognoselösungen sprechen, gehen wir die Schritte zur Erstellung eines langfristigen agilen Plans durch und nutzen den Bau eines Hauses als Metapher.

• Wo liegen die relativen Prioritäten jeder Initiative?
• Wann werden wir an den einzelnen Initiativen arbeiten?
  • Gibt es bestimmte Termine, die das Team einhalten muss?
  • Welche Abhängigkeiten hat das Programm – sei es intern oder von anderen Teams?
• Welche Teams arbeiten an der jeweiligen Initiative?
  • Sind die aktuellen Teams laut Zeitplanung verfügbar und haben sie ausreichend Kapazität?
  • Können wir die aktuellen agilen Teams unverändert beibehalten?
    • Falls nicht ...
      • Wie werden Teams neu organisiert?
        • Können wir es uns leisten, neu gebildete Teams im Zeitablauf des Projekts aufzustocken?

Es ist wichtig, die Arbeit des Teams mit der Roadmap zu verknüpfen, damit der oben erwähnte "Kontext" gewährleistet ist. Eine altbewährte Methode dafür besteht darin, Initiativen in Epics im Produkt-Backlog aufzuteilen und sie dann weiter in Anforderungen und User Storys zu zerlegen. Wenn alles verknüpft ist, können der Produktbesitzer und das Entwicklerteam einfacher kurzfristige Entscheidungen treffen, die zukünftige Aufgaben nicht beeinträchtigen. Sehen wir uns ein Beispiel dafür an.

Sagen wir beispielsweise, wir führen ein umfassendes Benutzerprofil-Feature auf unserer Website ein. Wenn wir feststellen, dass unsere Kunden das Feature nicht annehmen, sollen wir dann weiter darin investieren? Vielleicht, vielleicht nicht. Wir müssen verstehen, warum die Akzeptanz so gering ist, bevor wir diese Entscheidung treffen. Statt also weiter voranzugehen, sollten wir vielleicht einige A/B-Tests in der Hoffnung implementieren, dass wir einen Einblick erhalten, warum die Akzeptanzrate so gering ist. Das wiederum gibt uns vielleicht eine Richtung vor, die wesentlich schwieriger (oder unmöglich) gewesen wäre, wenn wir einfach weitergemacht und weiteren Schnickschnack hinzugefügt hätten.

Die Möglichkeit, einen Schritt zurückzutreten und zu recherchieren, bevor wir eine zentrale Entscheidung treffen, ist der Kern einer agilen Roadmap. Damit kann das Team Features weiterentwickeln, wenn es mehr über ein Produkt und den Markt erfährt.

Für Projekte nach dem Wasserfallmodell ist eine enorme Vorabinvestition erforderlich. Deshalb sind Teammitglieder emotional mit der Roadmap verbunden und scheuen die richtige Entscheidung, weil es zu schmerzlich ist, die getane Arbeit rückgängig zu machen – eine "menschliche Sünde", wie sie im Buche steht.

An sich bestehen bei der agilen Entwicklung drei verschiedene Risiken:

• Das Team verliert möglicherweise das Vertrauen in die Fähigkeit der Teamleitung, strategische Entscheidungen zu treffen, wenn die Roadmap zu oft aktualisiert wird.
• Wird die Roadmap jedoch nicht oft genug aktualisiert, kommt das Produkt unter Umständen zu spät auf den Markt und es kommt zu Gewinneinbußen, weil die Nachfrage bereits zurückgegangen ist.
• Langfristige Arbeiten können "zu groß und zu schwer" für kürzere Iterationen erscheinen. Das Team gleicht dies übertrieben aus, indem es die Aufgaben in extrem feine Details aufbricht und sich am Ende zu stark auf kurzfristige Ergebnisse konzentriert.

Um "Überlastung", Stillstand und Kurzsichtigkeit zu vermeiden, sollte der Fokus der Roadmap gleichmäßig über kurzfristige Taktiken und strategische langfristige Ziele verteilt sein. Eine großartige Methode dafür sind vierteljährliche Roadmap-Reviews und eine Anpassung nach Bedarf, die dann geteilt wird. Das funktioniert in Unternehmen jeder Größe, bedenke aber Folgendes: Da eine einzige Roadmap mehrere agile Teams umfassen kann, ist eine entsprechende Prüfung, Anpassung und Kommunikation erforderlich.

Lies weiter im "Agile Coach", um mehr über spezielle Überlegungen für größere Teams zu erfahren, die agile Portfolios mit Roadmaps für mehrere Teams verwalten. Du kannst auch mehr über die Roadmap-Angebote von Jira Software erfahren oder das speziell für PMs entwickelte Jira Product Discovery kostenlos testen.