Inhalt
Eine klassische Produkt-Roadmap plant die Entwicklung von Funktionen bzw. Features über ein bis drei Jahre. Stakeholder sehen solche Roadmaps als Zusage, dass konkrete Funktionen und Produkteigenschaften zu bestimmten Zeitpunkten verfügbar sind. Doch genau dieses langfristige Festlegen der zu liefernden Features widerspricht auf krasse Weise dem sehr adaptiven agilen Vorgehen. Bestehen die Geldgeber trotzdem auf einer Roadmap, muss ein agile Produktmanagement nicht zwangsläufig in das Wasserfall-Planungsmodell einer klassischen Roadmap zurückfallen. In dieser und ähnlichen Situationen eignet sich eine agile Roadmap.
Agile Roadmap als Routenplaner
Selbst Google berechnet im heutigen Verkehr keine von Anfang an verlässliche Route mit genauer Ankunftszeit. Die Route verändert sich im Laufe der Fahrt evtl. mehrfach durch Staus, Pausen und viele andere Einflüsse. Die voraussichtliche Ankunftszeit berechnet sich ebenfalls kontinuierlich neu. Ein kurzer Blick auf das „Navi“ vermittelt jederzeit einen aktuellen Planungsstand. Ein Entwicklungsteam in einem komplexen Software- oder Hardwarevorhaben kann ähnlich wie die besten Navigationssystem keine präzisen Vorhersagen treffen. Eine agile Roadmap kommuniziert den Stakeholdern durch ihren Aufbau möglichst klar, dass es sich um eine Art Route eines Navigationssystems handelt. Eine ständig aktualisierte Roadmap funktioniert für Team und Stakeholder ähnlich wie eine Route: Ein kurzer Blick auf die aktuelle Roadmap zeigt den aktuellen Planungsstand.
Gestaltungsoptionen einer Roadmap
Stakeholder möchten am liebsten wissen, wann welche Verbesserung kommt. Eine solche langfristige Detailplanung war schon immer problematisch. Und sie widerspricht dem agilen Ansatz der adaptiven rollierenden Planung. Im agilen Umfeld gibt es entsprechend eine ganze Reihe unterschiedlicher Anpassungen mit Ziel einer agilen Planung. Dabei variieren die Festlegung der Umsetzungsreihenfolge und die Art, wie die geplanten Inhalte beschrieben werden.
Reihenfolge bzw. Termine
Eine Roadmap ist ein mehr oder weniger verbindlicher Entwicklungsplan. Deshalb ist eine der beiden Hauptdimensionen einer Roadmap auch eine Priorität für die Umsetzung bzw. eine zeitliche Abfolge. Im klassischen Fall sind das konkrete Releastermine, die oft weit auseinander liegen.
- Priorisierter Backlog
Die agilste Form einer High-Level Planung zeigt lediglich eine Geschäftswert-priorisierte Reihenfolge von „Opportunities“. Typischer Vertreter ist das „Product Opportunity Backlog“. - Now/Next/Later
Etwas konkreter lassen sich die Outcomes in die groben Kategorien Now/Next/Later aufteilen. Das erfordert beides noch keinen großen Planungsaufwand. - QY/HY/FY
Der Planungsaufwand wächst bei der Aufteilung in Quartal (QY), Folge-Halbjahr (HY) und Folge-Jahr (FY). Eine solche Aufteilung kann von Stakeholdern bereits als Lieferzusage interpretiert werden. - Termine
Eine weitere konkretere Aufteilung beispielsweise in Quartale erfordert bereits ein sehr weit in die Zukunft reichendes Refinement der User Stories. Dadurch wird eine Zeitabschätzung zwar möglich, aber beinhaltet ein hohes Maß an Unsicherheit. Meine Empfehlung hier ist, maximal die Hälfte der aktuellen Kapazität zu verplanen.
Themen
- Feature-basiert
Klassisch entwickelt das Produktmanagement in der Roadmap-Planung aus den Anforderungen Lösungsfeatures. Die Entwicklung schätzt dann die jeweiligen Umsetzungsaufwand. Das Produktmanagement legt die Features dann prioritätenbasiert auf einen von der Kapazität abhängigen Zeitstrahl. Aus dieser Planung wird dann die Roadmap-Darstellung abgeleitet. - Outcome/Ergebnis-basiert
Agile Organisationen nutzen für die Grobplanung Outcome bzw. Geschäftswert zur Kommunikation der Inhalte. Dabei wird nicht die neue Funktion, sondern die Auswirkung auf Kunden und Nutzer beschrieben und in der Roadmap dargestellt. Durch die veränderte Sichtweise verstehen Kunden besser, welchen Nutzen sie für sich erwarten können. Und die Entwicklung kann wesentlich kreativer bis in die Umsetzungsphase hinein mit unterschiedlichen Lösungsansätzen experimentieren, um ein bestmögliches Ergebnis zu erreichen. Typische Vertreter dieser Kategorie sind Opportunity Backlog und Goal Oriented Roadmap.
Layout
Klassische Roadmaps ordnen Features und Funktionen an:
- In einer Liste
- Auf einem Zeitstrahl
- In einer Tabelle
Agile Roadmaps verwenden zur Anordnung von Features oder Outcomes
- Listen
- Tabellen
- Trichter
- Kreise
Zuerst sollte man sich klar sein, auf welchen Inhaltskategorien und mit welchem Detaillierungsgrad diese dargestellt werden sollen. Dann geht es an die Auswahl einer passenden Darstellungsform.
Vergleich verschiedener Roadmap Typen
Die Matrix vergleicht verschiedene Roadmap-Ansätze anhand der beiden Dimensionen. Dabei unterscheiden sich diese Ansätze vor allem durch ihre inhaltliche Ausrichtung und ihre zeitlichen Vorgaben. Die Klassische Roadmap mit genau terminierten Funktionen steht dabei am klassischen Ende und das Produkt Opportunity Backlog am agilen Ende einer Roadmap-basierten Planung und/oder Kommunikation.
Die folgenden Beispiele variieren bewusst verschiedene Anordnungsmöglichkeiten, können aber jederzeit an die eigenen Bedürfnisse angepasst werden. Jede Roadmap zeigt das selbe beispielhafte Entwicklungsvorhaben zum gleichen Zeitpunkt. Die entsprechenden Roadmaps sind mal mehr und mal weniger agil.
Klassische Roadmap mit langen Releasezyklen und Funktionen
Eine klassische Roadmap arbeitet mit langen Releasezyklen, in denen ein möglichst grosser zusätzlicher Funktionsumfang entwickelt wird. Das Beispiel zeigt einen Plan für eine Eingangsrechnungs-Verarbeitung bei Handwerkern mit halbjährlichen Releases zu einem festen Zeitpunkt.
Anwendungsfälle
- Hohe Abhängigkeit der Nutzer von Lieferzeitpunkten
- Ablehnung von agiler Vorgehensweise bei Entwicklung oder Stakeholdern
Vorteile
- Planungssicherheit bei den Stakeholdern, zumindest auf den ersten Blick
- Vergleichbarkeit mit den Mitbewerbern
Nachteile
- Bei komplexen Vorhaben kommt es regelmäßig zu Verzögerungen gegenüber dem Plan.
- Funktionen und Features werden missinterpretiert. Das gilt besonders, wenn das Wording der Produktorganisation und nicht bekannte Begriffe aus der Kundensprache verwendet werden.
- Lange Zyklen führen zu hohen Risiken bezüglich Kosten und Nutzen
- Oft sind Features auch ein Symptom dafür, dass die neuen Funktionen des Produktes nicht sauber aus Kunden-Outcomes abgeleitet wurden und evtl. gar nicht so wertvoll sind, wie das Produktmanagement glaubt.
Der Product Opportunity Backlog als Roadmap
Ein Product Opportunity Backlog priorisiert eine Liste von „Outcomes“. Outcomes sind produktrelevante Probleme und Wünsche der Zielgruppe oder der Produktorganisation. Gefestigte agilen Produktorganisationen verwenden das Opportunity Backlog als Produktroadmap: Eine „Opportunity“ mit gutem Kosten- / Nutzenverhältnis wird jeweils als Ziel gewählt. Dann arbeitet das Team so lange fokussiert an dieser einen Lösung, bis der Outcome erreicht ist. Dieses Ziel ist erst dann erreicht, wenn die neue Funktion bei den Nutzern des Produktes deren Wunsch erfolgreich erfüllt hat oder das Problem der Nutzer wirklich gelöst wurde. Parallel zur Entwicklung werden die erfolgversprechendsten weiteren Opportunities in einem „Discovery“ Prozess auf deren technische Machbarkeit, Nutzenpotential und Wirtschaftlichkeit analysiert. Dann sucht sich das Entwicklungsteam die nächste Opportunity aus den besten Kandidaten aus. Wie lange das Umsetzen für jede Opportunity konkret dauern wird, steht nicht im Fokus der Entscheidung dabei, welche Opportunity als nächstes umgesetzt wird. Eine genaue Zeitschätzung mit dem Ziel der Ressourcenplanung findet im agilen Team auf keinen Fall statt.
Anwendungsfälle
- Agile, adaptive Planung
- Zeitliche Aspekte sind nur für die Beurteilung des Nutzens bzw. des Geschäftswertes wichtig
Vorteile
- Unterstützt eine agile, adaptive Planung optimal
- Trennung von Product Backlog mit dem aktuellen Outcome als Entwicklungsschwerpunkt von der Planung der zukünftigen Outcomes im Product Discovery Prozess
- Führt selten zu Missverständnissen bezüglich zukünftiger Lieferungen
Nachteile
- Keine erkennbare Planung über den aktuellen Sprint hinaus
- Für viele Stakeholder unbekannt
- Benötigt viel Vertrauen in der Produktorganisation und bei den weiteren Stakeholdern
Anmerkung: Das Product Opportunity Backlog sollte nicht mit dem Product Backlog vermischt werden. Im Product Backlog nehmen konkrete User Stories bereits Gestalt an. Idealerweise ist der Zeithorizont eines Produkt Backlogs nicht mehr als ein Vierteljahr.
Outcome Based NOW/NEXT/LATER Roadmap
Die aus meiner Sicht agilste Form einer Roadmap mit zeitlicher Einteilung hat das Format Now / Next / Later und beinhaltet Outcome und evtl. Metriken.
- NOW beinhaltet die eine Opportunity, die aktuell in der Umsetzung ist. Je mehr weitere Themen in dieser Rubrik in Umsetzung sind und hier mit gelistet werden, desto unfokussierter ist die Entwicklung. Viele Opportunities in NOW vermindern die Erfolgswahrscheinlichkeit der Entwicklung entsprechend.
- NEXT enthält zwei bis fünf weitere Opportunities, die bereits intensiv im Discovery Prozess auf Machbarkeit, Nutzen und Komplexität hin untersucht wurden. Es ist nicht sicher, ob alle in Next befindlichen Opportunities auch tatsächlich umgesetzt werden.
- LATER listet weitere Opportunities, die aus aktueller Sicht sinnvoll wären und noch genauer untersucht werden sollen.
Die im Beispiel dargestellte Kreisform macht viele Produktorganisationen kreativer beim Product Discovery. Durch die optionale Segmentierung in grosse Themenblöcke bzw. Lösungsbereiche sieht man schnell, wo nach aktuellem Wissenstand der Fokus der Weiterentwicklung liegen wird.
Anwendungsfälle
- Grobe Reihenfolge der Umsetzung soll kommuniziert werden
- Der Product Discovery Prozess wird strukturierter als beim reinen Opportunity Backlog
Vorteile
- Kommuniziert Priorisierung und eine grobe Reihenfolge
- Weckt wenig hinderliche Erwartungshaltungen: Flexibilität bei der Reihenfolge in NEXT, wenig wahrgenommenes Commitment für die Themen in LATER
- Gute Hilfe dabei, Opportunities nicht zu früh zu detailliert zu untersuchen
Nachteile
- Keine Planbarkeit der Abhängigkeiten, z.Bsp. bei den Kunden
- Keine Funktionen, das Lösungskonzept muss noch erarbeitet werden
Story Map Based QY-HY-FY Roadmap
Stakeholder wünschen sich häufig mehr Planungssicherheit, als eine Outcome Based NOW/NEXT/LATER Roadmap liefert. Agile Produktmanager gehen darauf ein, indem sie auf der zeitlichen Achse aus NOW/NEXT/LATER einfach die Zeiträume aktuelles Quartal QY, folgendes Halbjahr HY und anschließend noch ein Jahr FY machen (QY/HY/FY). Dadurch kommuniziert man auf der einen Seite feste Zeiträume, legt aber auf der anderen Seite keine Reihenfolge oder Termine im jeweiligen Zeitraum fest. Nach 6 Wochen bzw. mindestens einmal im Quartal sollte diese Form einer Roadmap aktualisiert und an alle kommuniziert werden. Ein Gültig-Bis-Vermerk auf der Roadmap bringt den Stakeholdern die Vorläufigkeit dieser Planung näher.
Die hier verwendete Story Map ist eine weit verbreitete agile Planungsmethode. Durch die visuelle Darstellung des Haupt-Workflows der Nutzer wird die Diskussion mit Kunden und Anwendern oft deutlich vereinfacht.
Anwendungsfälle
- Aktiv gepflegte Customer Story Map ist die Vorgabe für die Entwicklung
- Visualisierung des Workflows der Nutzer zur Priorisierung mit Stakeholdern
- Grobe zeitliche Planung ist notwendig
Vorteile
- Gute Basis zur Priorisierung gemeinsam mit allen Stakeholdern
- Grobe Zeitplanung ersichtlich
Nachteile
- Höherer Planungsaufwand für Zeitabschätzung
- Risiko von Verzögerungen gegenüber der Planung
- Nicht alle Anforderungen lassen sich den Hauptschritten einer Story Map zuordnen
Goal Oriented, quartalsweise Roadmap mit Features
Inhaltlich unterstützen agile Roadmaps den Produkterfolg am besten, wenn der Fokus wie in den bisherigen Beispielen auf Outcomes liegt. Zu den Outcomes passende Kennzahlen bzw. Metriken kommunizieren die Ernsthaftigkeit an die Stakeholder. Manche Autoren kombinieren zum Genannten zusätzlich Features, wie beispielsweise in der sehr bekannten Goal-Oriented Roadmap von Roman Pichler. Da diese Roadmap neben Features auch feste Releasetermine beinhaltet, kommt sie nahe an eine traditionelle Roadmap. Der Releaserhytmus ist dabei im Template offen wählbar. Eine erste Empfehlung ist hier vierteljährlich. Dieser Roadmap-Typ eignet sich gut, wenn ein klassischer Entwicklungsplan sonst nicht zu vermeiden wäre. Auch wenn stark planungsorientierte agile Frameworks wie SaFE als Vorgehensmodell genutzt werden, ist eine Goal Oriented Roadmap sinnvoll. Meine Empfehlung ist, die Feature-Zeile nur intern zu nutzen und Kunden/Nutzern ausschließlich Ziele und Metriken zu kommunizieren. Ob eine GO-Roadmap zu einem erfolgreichen Produkt führt, hängt letzten Endes vom Mindset der Beteiligten und von der Umsetzung ab.
Anwendungsfälle
- Roadmap im SAFe Umfeld
- Hohe Planungssicherheit erforderlich
- Mischung aus agilem und klassischem Mindset, erster Schritt in Richtung agil
Vorteile
- Hohe Akzeptanz bei klassisch denkenden Stakeholdern
- Klarer Plan
- Umsetzung von Produkt-Zielen ist inhaltliches Hauptkriterium
Nachteile
- Hoher Planungsaufwand
- Erzeugt konkrete Erwartungshaltung bei den Stakeholdern
- Gefahr, dem Plan strikt zu folgen
Fazit
Bei der Wahl der passenden Roadmap kommt es wie immer stark auf die Adressaten des Dokumentes an. Was sind deren Erwartungen? Wie groß ist deren Vertrauen in das Entwicklungsteam? Wie waren die bisherigen Erfahrungen mit dem Produkt und der Produktorganisation? Welche Erfahrung mit agilem Vorgehen haben die Stakeholder?
Um agil zu entwickeln, sollte unter diesen Aspekten eine möglichst agile Roadmap-Struktur gewählt werden. Bleibt man dabei nahe an einem klassischen Entwicklungsplan, dann sollte das Entwicklungsteam für die Zukunft daran arbeiten, die Stakeholder im agilen Sinn enger in die Entwicklung einzubeziehen und dabei gegenseitiges Vertrauen aufzubauen. Je besser das gelingt, umso agiler kann die nächste Roadmap-Version gestaltet werden.
