Agiles Roadmapping mit Produkt-Routen

„Routenplaner (Streckenplaner, Wegplaner, von französisch: route = Weg) sind Computerprogramme, mit deren Hilfe ein Weg zwischen einem Start- und einem Zielort gefunden werden kann. Meistens können auch ein oder mehrere Orte dazwischen („via“) angegeben werden. Es können meistens Wünsche angegeben werden, ob die schnellste, die kürzeste, die wirtschaftlichste (ökonomischste) oder manchmal auch die schönste Route gesucht werden soll.“ (Wikipedia)

Das Bedürfnis nach (Planungs-)Sicherheit ist ein häufig auftretendes Phänomen bei Softwareprojekten. Erst an zweiter Stelle steht das Bedürfnis, etwas Nützliches und Relevantes liefern zu können. Das ist zunächst verwirrend: Sind agile Methoden nicht genau deswegen überhaupt erst eingeführt worden? Weil es eben keine Sicherheit gibt und wir uns daher lieber darauf konzentrieren, sicherzustellen, dass wir immer das Nützlichste und Relevanteste entwickeln?

Wenn es diese Sicherheit gäbe und wir genau vorhersagen könnten, wann wir welchen Umfang liefern können, wären agile Entwicklungsmethoden überflüssig. Warum sollte man also annehmen, man könne die Komplexität von Softwareprojekten planerisch in den Griff bekommen – speziell, wenn alle Studien und Fallbeispiele das Gegenteil beweisen?

Häufig kommen wir in Projekte, in denen die Planungsphase bereits abgeschlossen ist und wir das Ziel hinnehmen müssen, wie es ist. Leider sind diese Pläne meist schlecht. Die Tatsache, dass der Plan bereits geschmiedet ist, sollte aber keine Entschuldigung für uns sein, sie nicht in Frage zu stellen (auch wenn der Kunde das vielleicht lieber hätte). Wenn wir nicht hinterfragen, welche Ziele und Werte hinter dem Plan stehen, was das Ergebnis sein soll, wie eine Veränderung der Verhaltensweise der Kunden (und manchmal auch des Unternehmens) herbeigeführt werden soll, wenn wir nicht lineare Backlogs und unmessbare User Stories kritisieren, dann werden wir unserer Rolle als Berater nicht gerecht. Vielleicht gibt es ja die Chance, dass der Kunde versteht, worum es bei Agilität geht, statt in eine weitere Kostenfalle zu tappen.

Wie können wir Dinge ändern, die ganz offensichtlich schlecht sind oder nachweislich unpassend oder gar falsch, wenn wir nicht aktiv dagegen argumentieren und dafür andere, bessere Wege aufzeigen?

Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. (Agile Manifesto)

Wenn Scheitern zum Standard wird

Man könnte jetzt dem Kunden erklären, dass er einige „schlechte Angewohnheiten“ hat und wir ihm helfen können, diese zu überwinden. Dummerweise hören Kunden nur ungern von externen Beratern oder Entwicklungsteams, dass alles, was sie die letzten 30 Jahre gemacht haben, vollkommen falsch war und dass sie endlich Transparenz und Vertrauen und andere agile Werte fördern sollten. Man darf auch nicht vergessen, dass diese Unternehmen 30 Jahre lang erfolgreich im Geschäft sind und immerhin den Mut haben, sich trotz dieser offensichtlichen Reife Hilfe von außen zu holen!

Trotzdem ist es besser, die Tatsache, dass es keine Sicherheit gibt, zu akzeptieren statt sie zu verleugnen und hinterher überrascht zu sein, wenn das Projekt fehlschlägt. Aber auch wenn es keine Sicherheit gibt, das Bedürfnis nach Sicherheit existiert in jedem Fall. So kommt es, dass in einigen Firmen schon so lange Projektfehlschläge (in Bezug auf den ursprünglichen Plan) passieren, dass jeder es vorher weiß, obwohl es keiner auszusprechen wagt.

Am Ende ist in solchen Firmen keiner überrascht, weil ja jeder damit gerechnet hat, dass das Projekt fehlschlägt und weil es ein „ganz normaler“ Prozess ist, der keinen Grund zur Beunruhigung gibt. Man ist es eben gewohnt, „betrogen“ zu werden. Manchmal wird dies auch ganz gezielt zur Diskreditierung von Personen eingesetzt. Dann rollt eben am Ende des Projektes ein Kopf, und man setzt einen neuen Projektleiter ein, den man sowieso viel besser leiden kann als den Querkopf, der das Projekt im Moment leitet.

Der Ausweg: volle Transparenz

Unser Vorschlag für einen Ausweg aus diesem Dilemma ist, dass wir das Akzeptieren des Bedürfnisses unserer Kunden nach Sicherheit über unser eigenes Bedürfnis stellen, ihm den Umgang mit Komplexität beibringen zu wollen – etwa so, wie wir dem agilen Wert folgen, das

Reagieren auf Veränderungen höher zu schätzen als das Befolgen eines Plans.

Wir könnten damit anfangen, ihm die unterschiedlichen Kompromisse, die er bei der einen oder anderen Methode eingehen müsste, so transparent zu machen, dass er mindestens im vollen Bewusstsein der Konsequenzen seine Entscheidung trifft, diesen Weg zu gehen.

Als nächstes könnten wir den Plan des Kunden als eine erste Version einer agilen Planung betrachten und ihm den Unterschied zwischen klassischer und agiler Planung erklären.

„In preparing for battle I have always found that plans are useless, but planning is indispensable.“ (Dwight D. Eisenhower)

„Malum est consilium quod mutari non potest“ – „Schlecht ist ein Plan, der sich nicht ändern lässt.“ (Publilius Syrus, 85-43 B.C., Römischer Mimen-Autor und Ethiker)

Das wird nicht immer ganz einfach sein, denn der Kunde ist es gewohnt, seine Pläne früh zu kommunizieren und sich darauf festzulegen, und die Empfänger dieser Botschaft sind es gewohnt, dass diese sich bis kurz vor Ende des Projektes nicht ändern. Die Botschaft, die Eisenhower, Publilius Syrus und die Verfasser des Agilen Manifests senden, ist aber: Solange der Inhalt des Plans an den Produkt- oder Projektzielen ausgerichtet ist (oder noch besser: am nächsten vielversprechenden Teilziel) und keine plumpe Ansammlung von versprochenen Features, ist es sehr gut, einen Plan zu haben! Den Kunden nach seinen Zielen zu fragen, mögliche Einflüsse seiner Lösung auf die Anwender zu beleuchten und zu ermitteln, wieviel er auf einen Projekterfolg wetten würde, wird uns nicht umbringen. Aber vielleicht erzeugen diese Fragen neue Erkenntnisse und Änderungen in der Denkweise.

Als nächstes versuchen wir mal, den Plan auf einen Zeitstrahl zu projizieren. Das ist der Kunde gewohnt, und es gibt ihm ein Gefühl von Sicherheit. Natürlich sollte der Plan keine festen Datumsangaben haben, aber vielleicht Produktinkremente, Quartale, Releases oder was auch immer für diesen Kunden sinnvoll ist.

Aber einen Plan zu haben bedeutet mehr, als nur das Ziel zu kennen und eine vage Vorstellung davon, wie man ihm näher kommt. Es bedeutet auch, ein Bauchgefühl dafür zu haben, ob es eher Monate oder Jahre braucht, um dorthin zu gelangen.

Und dann gilt natürlich: Reagieren auf Veränderung steht über dem Befolgen eines Plans. Mit anderen Worten: Habe einen Plan. Folge ihm nicht blind. Wenn der Plan anpassbar ist, ist alles gut. Wenn du nach zwei Wochen feststellst, dass du auf der falschen Fährte bist, z. B. dass die erstellten Features Schrott sind und keiner sie verwendet, dann ist der Rest des Plans wahrscheinlich auch Schrott und sollte überarbeitet werden. Oder anders herum: Wenn du nach zwei Wochen dein Ziel schon erreicht hast, wie wertvoll ist dann der Rest des Plans noch?

Die große Gefahr, die ein statischer Plan mit sich bringt, ist, dass man ihm weiterhin folgt, ohne Feedback-Loops zu berücksichtigen. Agilität bedeutet, das Richtige zu tun und nicht alles zu tun, was geplant war, mit einem Zeitstrahl und soundso vielen möglicherweise benötigten Features, aber ohne den Wert des Produktes zu erhöhen bzw. überschüssigen Kram zu produzieren.

Ein GPS der Agilität

Ein agiler Roadmapping-Prozess ähnelt daher stark einem modernen Navigationssystem: Das Ziel ist ziemlich fest vorgegeben, und üblicherweise will man so schnell wie möglich dorthin gelangen. Oder auf dem Weg die maxi- male Anzahl an Sehenswürdigkeiten erleben, für den Fall, dass man gerade im Urlaub ist. Wenn das System einen Stau feststellt, wird die Route verändert. Nur die Zeit ver- ändert sich etwas, der Optimierungsalgorithmus („schnellst- mögliche Route“) bleibt erhalten. Und natürlich möchte man Zwischenstopps einlegen (zum Tanken, Frühstücken, Sightseeing), während man schon unterwegs ist.

Zu jeder Zeit kann das Navigationssystem vorhersagen, um welche Zeit welcher Zwischenstopp erreicht wird (und tatsächlich sind die meisten Navigationssysteme erstaunlich präzise in ihren Vorhersagen, das haben sie vielleicht einem agilen Roadmapping-Prozess voraus). Aber es gibt keinerlei Garantie dafür, dass man tatsächlich zu diesem Zeitpunkt ankommt, und es zwingt einen umgekehrt auch nicht, zu einem bestimmten geplanten Zeitpunkt an einem bestimmten geplanten Ort anzuhalten. Weicht man etwas vom Plan ab, kalkuliert das System sofort eine neue Route und neue Zeiten. Ein Stau? Vielleicht ist jetzt der längere Weg die bessere Route für den aktuellen Optimierungsalgorithmus! Entscheidend ist: Das System berechnet immer die beste Route, basierend auf den aktuellsten Informationen, die ihm vorliegen. Manche Systeme gehen sogar so weit, dass sie mehrere alternative Routen vorschlagen und dabei Zusatzinformationen (z. B. Verkehrsdichte, Baustellen, Straßensperren) mit anzeigen, so dass der Anwender gut informiert seine eigene Entscheidung treffen kann, welche Route er für die geeignetste hält (s. Abbildung 1).

Abb. 1: Der Anwender kann gut informiert seine eigene Entscheidung treffen, welche Route er für die beste hält.

In manchen Fällen muss man sogar das Ziel neu bewerten: Möglicherweise hat man selbst oder das Navigationssystem festgestellt, dass das Ziel in einer Fußgänger- zone liegt – dann muss die Route zum nächstgelegenen Parkplatz und nicht zum Ziel selbst führen. Oder wenn man zu einem Termin spät dran ist, könnte man sich ab einem gewissen Maß der Verspätung dafür entscheiden, den Termin ausfallen zu lassen und direkt weiter zum nächsten zu fahren.

Mir selbst ist es schon häu g passiert, dass ich auf halber Strecke zu einem Termin im Stau stecken geblieben bin und dann bei der nächsten Gelegenheit von der Autobahn abgefahren und wieder nach Hause gefahren bin, weil sich mein Zeitfenster geschlossen hatte.

Manchmal bekommt man auch neue Informationen während der Fahrt, die einige der geplanten Ziele obso- let erscheinen lassen: Wir waren mal mit der Familie auf einer Besichtigungstour französischer Schlösser und Burgen. Wir hatten uns vier bis fünf Schlösser herausgesucht und eine Route ermittelt, die an allen vorbeiführt. Bei der Besichtigung eines der Schlösser haben wir von einem anderen Touristen eine Empfehlung eines weiteren nahegelegenen Schlosses bekommen, also haben wir ein anderes gestrichen und sind lieber der Empfehlung gefolgt.

Wenn man dieses Beispiel noch weiter abstrahiert, kommt man vielleicht sogar zu der Erkenntnis, dass die eigentliche Optimierungsfunktion eine glückliche Familie ist und bricht die Tour einfach ab und geht in ein nettes Bistro nahe dem Schloss, in dem die Kinder je ein großes Eis bekommen, während es sich die Eltern bei einem Glas guten französischen Rotweins gut gehen lassen.

Zusammenfassung

Auf Basis aller dieser offensichtlichen Parallelen schlagen wir vor, sich eine agile Roadmap wie eine Reiseroute vorzustellen. Zum Schluss ein paar Hinweise, die beim Erstellen einer solchen Roadmap hilfreich sein können:

• Mache das Ziel explizit und richte deine Route so aus, dass sie dorthin führt
• Bewerte das Ziel nach einem längeren Zeitraum (z. B. ein Jahr) neu, um zu überprüfen, ob es sich inzwischen bewegt hat
• Finde heraus, was deine Optimierungsfunktion ist. Mögliche Kandidaten sind z. B. Time-to-Market, Qualität, Unique Selling Point etc.
• Projiziere deinen Plan auf einen Zeitstrahl. Je größer die Organisation ist, desto längerfristig wird die Planung. Typischerweise sollte die Planung sechs bis zwölf Monate in die Zukunft reichen (abhängig vom Projekt/ Produkttyp und dem Marktsegment, in dem du dich befindest)
• Mache deine Route leicht zugänglich, visuell ansprechend und leicht zu aktualisieren
• Sorge dafür, dass deine Route gute Vorhersagen für die nahe Zukunft und (absichtlich) eher vage Vorhersagen für die ferne Zukunft macht
• Stelle sicher, dass du deine Produkt-Route regelmäßig aktualisierst, typischerweise jeden Monat
• Bedenke, dass ein Stoppen des Projektes zu jedem Zeitpunkt eine deiner Optionen ist. Setze die „Reise“ nicht nur deshalb fort, weil du sie begonnen hast!