Agile Roadmaps: Aufbauen, Teilen, Verwenden, Weiterentwickeln

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

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 und langfristige Ziele 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. Produktteams 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 und zukünftigen Ziele des Teams und sie sollte auf Verschiebungen in der Wettbewerbsumgebung reagieren. Mehrere agile Teams können sich entweder eine einzige Produkt-Roadmap teilen oder eine eigene Produkt-Roadmap nutzen.

Um eine Roadmap zu erstellen, berücksichtigen Produktteams Marktentwicklungen, Unternehmensziele, Kundenfeedback und Erkenntnisse sowie technische Einschränkungen. Sobald ein ausreichendes Verständnis dieser Faktoren gegeben ist, werden sie in einer Roadmap als Initiativen und Zeitleisten wiedergegeben. Nachfolgend findest du ein Beispiel für eine sehr einfache Roadmap, die für ein Produktteam erstellt wurde. Generell ist es für Produkt-Roadmaps am besten, sich an größere Zeitabschnitte wie Monate oder Quartale zu halten, anstatt sich auf bestimmte Daten festzulegen. Damit sich die Gespräche zur Priorisierung auf Ziele und Strategien konzentrieren, anstatt auf Zeitleisten, kannst du sogar versuchen, Initiativen unter "Jetzt", "Als Nächstes" und "Später" zuzuordnen.

Nachdem eine Roadmap erstellt wurde, muss sie mit dem gesamten Produktteam, den Führungskräften und den Bereitstellungsteams geteilt werden, damit jeder die Vision und Ausrichtung versteht. In vielen Unternehmen erstellen Produktinhaber 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) zeitaufwendig und mühsam, alle auf dem Laufenden zu halten, falls sich die Roadmap ändert.

Wie können Produktteams also das Unternehmen besser auf dem Laufenden halten? Ganz einfach.

Die meisten Tools für Zusammenarbeit benachrichtigen automatisch alle Teilnehmer über ein Projekt und teilen ihnen mit, dass sich die Roadmap geändert hat.

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?
  • Welchen Einfluss wird jede Initiative auf die Produkt- und Unternehmensziele haben?
  • Wie viel Aufwand ist für jede Initiative erforderlich?
  • Gibt es genügend Erkenntnisse und Daten, um die Umsetzung einer Initiative zu unterstützen?
• 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, dass du die Bereitstellungen deines Teams wieder mit der Produkt-Roadmap verknüpfst, damit du den gesamten oben erwähnten Kontext erhältst. Eine bewährte Methode hierfür besteht darin, die Produktideen, die du priorisiert hast, auf deiner Produktkarte abzubilden und diese Ideen dann auf deiner Bereitstellungs-Roadmap in Epics, Anforderungen und User Storys aufzuschlüsseln. In den meisten Fällen gibt es für jede Idee ein entsprechendes Epic, das in kleinere Aufgaben aufgeteilt werden muss, die erledigt werden müssen. Indem du Ideen auf deiner Produkt-Roadmap mit Epics auf deiner Bereitstellungs-Roadmap verbindest, erhalten Techniker den Kontext für priorisierte Initiativen, wie Benutzerfeedback und Recherchen, immer zur Hand. Außerdem erleichtert es Produkt- und Entwicklerteams, gemeinsam kurzfristige Entscheidungen zu treffen, die die zukünftige Arbeit nicht beeinträchtigen.

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 Fähigkeit, etwas Abstand zu nehmen und zu recherchieren, bevor du eine wichtige Entscheidung triffst, ist das, was eine agile Roadmap im Wesentlichen ausmacht. Im Idealfall ist der Erkennungsprozess, bei dem Erkenntnisse und Daten gesammelt werden, der erste Schritt, bevor du dich zur Umsetzung einer Entscheidung entschließt. Das Team hat dann die Möglichkeit, Funktionen weiterzuentwickeln, 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 versuchen, deine eigene Roadmap kostenlos in Jira Product Discovery zu erstellen, das speziell für Produktteams entwickelt wurde.