Meditations on Agile

In den Alpen verirrt

Eine Anekdote aus dem zweiten Weltkrieg besagt, dass ein Trupp der ungarischen Armee sich im Winter in den Alpen verirrt hatte. Ein junger Offizier beauftragte einen Unteroffizier und einige Soldaten mit einer Erkundungsmission. Kurze Zeit später kam ein Schneesturm auf. Der Offizier wurde nervös, weil er fürchtete, die Leute in den Tod geschickt zu haben.

Das Wetter wurde auch am folgenden Tag nicht besser. Und auch am dritten Tag fielen noch dicke Flocken und der Wind blies kräftig. Der Offizier war sich sicher, dass die kleine Gruppe nicht überlebt hatte. Dann kamen sie plötzlich zurück ins Lager. Natürlich wollte der Offizier wissen, wie sie es geschafft hatten.

Der Unteroffizier berichtete, dass sie sich nach Beginn des Sturmes erstmal in eine Höhle zurückgezogen hatten. Sie fürchteten, dort zu verhungern, als er eine Landkarte des Gebirges im Rucksack entdeckte. Mit dieser Landkarte führte er sie zurück zum Lager. Der Offizier ließ sich die Landkarte zeigen und stellte fest, dass es sich um eine Karte der Pyrenäen handelte.

So absurd diese Anekdote klingen mag, so wichtig ist die Moral daraus für Softwareprojekte. Die Aufgabe von Roadmaps ist es nicht, die Wahrheit zu zeigen, sondern uns zu helfen, zum Ziel zu finden. Deshalb ist es immens wichtig, die Beschäftigung mit Roadmaps als eine kontinuierliche Aufgabe zu sehen.

Unsicherheit auf der Roadmap

Was ich oft erlebe, ist, dass Roadmaps einmal erstellt werden und dann um jeden Preis eingehalten werden müssen. Ich nenne das immer Roadmap-Mikado: Wer zuerst ein Feature bewegt, hat verloren.

Die Ursache liegt oftmals in der Unsicherheit, ob ein Feature, das nicht zu einem exakten Zeitpunkt auf der Roadmap eingeplant ist, tatsächlich auch geliefert wird. Die Pflege der Roadmap wird dann zu einem regelmäßig wiederkehrenden Gewaltakt, denn jedes Feature macht Arbeit – auch wenn es “nur” Planungsarbeit ist.

Dieser Unsicherheit zu begegnen, ist eine der wichtigsten Aufgaben von Product Ownern und agilen Teams. Der einzige Weg, die Unsicherheit abzubauen, führt über den Aufbau von Vertrauen. Und Vertrauen in eine Roadmap entsteht, wenn geliefert wird, was versprochen wurde. Dazu muss die Verwaltungsarbeit an der Roadmap auf ein Minimum reduziert werden. Diese Kunst, eine Roadmap auszubalancieren, erfordert einiges an Fingerspitzengefühl, viel Kommunikation und ein paar zielgerichtete Methoden. Empfehlenswert sind Impact Mapping, Story Mapping und die Arbeit mit Epics, User Storys und Themes.

Und wenn schon alles voll ist…

…mit hunderten User Storys, die problemlos die nächsten zehn Jahre füllen würden?

Dann sollte der Product Owner mutig sein und einfach alles löschen, das es in den letzten drei Monaten nicht in die Software geschafft hat. Das klingt brutal und widerspricht dem menschlichen Bedürfnis, einmal Aufgeschriebenes zu erhalten – man könnte es ja noch einmal gebrauchen. Aber dieses Bedürfnis ist nur ein Ausdruck der Sunk Cost Fallacy.

Es ist für alle Beteiligten weitaus zeitsparender, wirklich wichtige Features noch einmal neu zu erfassen, als sie unter Unmengen unwichtiger Features herauszusuchen. Und: in so einem Haufen ehemals wichtig empfundener Features tauchen noch eine ganze Menge auf, die dann aus Gründen doch behalten werden sollen. So sind Menschen.

Wichtig ist, dass die Roadmap dabei nicht leer wird. Aber das ist unwahrscheinlich, denn in den meisten Projekten und Produkten kommen kontinuierlich neue Themen auf die Roadmap, die irgendwann mal entwickelt werden müssen. Wegwerfen sollten wir nur alles, was älter als drei Monate ist. War es wichtig, kommt es nochmal, wenn die Zeit reif ist.

Ein schlechtes Spiel

Roadmap-Mikado ist ein schlechtes Spiel. In Softwareprojekten, egal, ob agil oder nicht, müssen Features bewegt werden. Manche in die Produktion, andere von der Roadmap herunter. Sonst kann es sein, dass man sich irgendwann auch mit einer Karte der Pyrenäen nicht mehr in den Alpen zurechtfindet.

Deshalb git für Roadmap-Mikado: Wer die meisten Features bewegt, gewinnt!

Dieser Artikel erschien zuerst in der Kolumne „Meditations on Agile“ auf JAXenter.