Roadmaps
Niels besteht darauf, dass eine Roadmap nichts mit Agilität zu tun hat. Jan ist der Meinung, dass eine Roadmap auch für ein agiles Unternehmen mehr als nur ein nützliches Werkzeug ist.
Beide haben recht!
In diesem Artikel erkläre ich wie das möglich ist. Wie so oft liegt der Grund in verschiedenen Interpretationen des Begriffes «Roadmap». Ich unterscheide hier zwischen «klassischen» und «agilen» Roadmaps.
Wenn das Interesse gross genug ist erläutere ich gerne in einem weiteren Artikel wie ich agile Roadmaps erstelle.
«Wir brauchen eine Roadmap»
Vor ein paar Jahren trat ich eine Stelle als Chief Product Owner bei einem grossen Telekomunternehmen in der Schweiz an. Keine Woche war vergangen bevor ich mit der Forderung konfrontiert wurde eine Roadmap (auch «Road Map») zu erstellen.
Zu diesem Zeitpunkt war ich eindeutig noch ein «Niels», ein Mensch der Roadmaps zutiefst verachten und der Meinung ist, dass diese absolut nichts in einem agilen Kontext verloren haben.
Als guter Product Owner, einer der täglich vor dem Spiegel das «Nein» übt, fiel es mir nicht schwer, die Forderung nach einer Roadmap abzulehnen. Ein paar Tage später war der Wunsch allerdings schon wieder auf meinem Tisch. Auf meine Frage «Wofür es denn diese Roadmap überhaupt braucht» hiesse es anfangs «Weil wir schon immer eine hatten». Das ist Kultur, aber keine Begründung. Also «Nein, es gibt keine Roadmap». So ging das Spiel eine Weile hin und her. Als schliesslich auch die Entwicklerteams zu erkennen gaben, dass ihnen eine Roadmap bei der gemeinsamen Ausrichtung helfen würde, habe ich nachgegeben und eine erstellt.
Es war aber nicht eine «klassische» Roadmap.
Merriam-Webster’s Definition einer «road map» (engl.)
Was ist eine Roadmap?
Klassisch verstehen Roadmaps sich als Plan auf höherer Ebene.
“A roadmap is a strategic plan that defines a goal or desired outcome and includes the major steps or milestones needed to reach it.” [ProductPlan]
Das beisst sich selbstverständlich mit der Annahme, dass wir uns in einem komplexen System befinden (ansonsten gäbe es ja nicht unbedingt einen Grund agil vorzugehen). Komplexität wiederum bedeutet, dass wir die Zukunft eben nicht vorhersagen können, egal wie viele Informationen wir einholen und wie gründlich wir diese analysieren.
Daher auch meine Aversion gegen klassische Roadmaps.
Aber natürlich können wir den Begriff «Roadmap» einfach anders interpretieren.
Agile Roadmap
Googelt man “Agile Roadmap” bekommt man tonnenweise Resultate. Da ist zum Beispiel die “Go Product Road Map” von Roman Pichler die sich grosser Beliebtheit erfreut. Oder Jeff Patton’s möglicherweise noch populärere “User Story Map” die im weitesten Sinn auch als Roadmap verstanden werden kann. Unzählige Ratgeber, Blog Posts, Videos, Werkzeuge und Templates.
Mir geht es in diesem Artikel nicht darum wie eine agile Roadmap konkret auszusehen hat. Vielmehr möchte ich das Grundprinzip einer agilen Roadmap, wie ich sie zumindest verstehe, erklären. Ich möchte aufzeigen, wie sich die klassische von der agilen Roadmap¹ unterscheidet, damit es in Zukunft weniger Missverständnisse gibt. Vielleicht müssen Niels und Jan sich ja gar nicht mehr über Roadmaps streiten.
Planung vs. Plan
«Plans are worthless, but planning is everything»
[Dwight Eisenhower, 1957]²
Anlehnend Eisenhower hat eine Roadmap (in komplexen Kontexten, für die gilt dieses Zitat nämlich) wenig Wert, wenn Sie vor allem als Plan funktioniert («plans are worthless»). Der Akt der Erstellung einer Roadmap ist allerdings wertvoll («planning is everything»), weil er den aktuellen Stand der Dinge transparent für alle macht.
Vereinfacht gesagt ist die «klassische Roadmap» eine Vorgabe, was wann gemacht werden muss. Sie ist eher statischer Natur. Währenddessen die «agile Roadmap» es transparent macht, was möglicherweise in Zukunft kommt. Sie wird laufend aktualisiert und lädt zu Feedback ein. Erstere ist ein Versprechen, letztere dient der Kommunikation und dem Abgleich.
Transparenz vs. Sichtbarkeit
Eine der wichtigeren Aufgaben eines Scrum Product Owners ist es den Backlog (hier ist immer vom Product Backlog die Rede) transparent zu gestalten. Für viele bedeutet dies den Backlog sichtbar (engl. «visible») für alle zu machen. Ihn auf Jira zu pflegen und dafür zu sorgen, dass jeder Stakeholder darauf zumindest lesend zugreifen kann.
Nur ist Sichtbarkeit und Transparenz nicht dasselbe.
Damit etwas Transparent ist, muss es auch sichtbar sein. Nur weil etwas sichtbar ist, ist es aber nicht automatisch transparent.
Sichtbar ist ein kontextunabhängiges Attribut. Ob ein Backlog allerdings nicht nur sichtbar, sondern auch transparent ist, entscheidet jeder Betrachter für sich. Ein und derselbe Backlog mag gleichzeitig für eine Person transparent sein für eine andere nicht. Aufgabe des Product Owners ist es, dafür zu sorgen, dass so viele Stakeholder wie möglich den Backlog lesen und die Informationen extrahieren können, die für sie von Wichtigkeit sind. Je besser dem Product Owner das gelingt, desto transparenter ist der Backlog.
Und hier kommt nun die agile Roadmap ins Spiel. Sie kann ein hervorragendes Werkzeug sein, um einen Backlog transparenter zu machen.
Der wichtige Unterschied
Bei der agilen Roadmap, so wie ich sie hier beschrieben habe, geht es also «bottom-up». Zuerst haben wir den Backlog (die Details) und daraus macht der Product Owner eine agile Roadmap, indem er unwichtige Details weglässt, sodass der Leser der Roadmap den Wald vor Bäumen sehen kann.
Dass das nicht einfach ist, wusste schon Pascal:
«Please forgive the long letter; I didn’t have time to write a short one.»
[Blaise Pascal]
Bei der klassischen Roadmap ist es oft umgekehrt. Sie kommt nicht selten «top-down» daher und dient der Steuerung. Sie ist als Vorgabe mit definierten Leistungspaketen und Milestones zu verstehen. Erst kommt die klassische Roadmap, dann die Details. Ein «Push-Werkzeug». Die Details müssen sich der Roadmap anpassen. Das muss zwar nicht so sein, ist es aber oft.
Schlussfolgerung
Das unantastbare Prinzip, dass der Product Owner den Product Backlog besitzt und nicht einfach nur verwaltet. Dass nur er allein — und sonst niemand — diesen Priorisiert und somit bestimmt in welcher Reihenfolge die Backlog Elemente geliefert werden, wird bei der agilen Roadmap nicht verletzt, bei der klassischen schon.
Wenn Niels also davon ausgeht, dass mit dem Begriff «Roadmap» die klassische gemeint ist und Jan schon an die agile denkt, haben beide recht mit ihrer Behauptung.
Ich habe 5 Jahre gebraucht um das zu verstehen.
¹Eigentlich gefällt mir der Begriff «agile Roadmap» nicht besonders gut. Einfach ein «agil» an einen altbekannten Begriff hängen birgt Gefahren, sorgt für Missverständnisse und ist zudem uncool. Etwas wie «Product Forecast», «Snapshot» oder «Status Quo Map» wäre vielleicht besser? Dabei geht allerdings eventuell vergessen, dass es ein Ersatz für die klassische Roadmap ist.
²Eisenhower zitierte dabei allerdings einen anonymen Soldaten. Mehr kann man hier darüber lesen.