Was soll das denn schon wieder sein? Der neueste agile heiße Scheiß? Klingt außerdem eher kontraproduktiv, oder? Im Leben und auch in der Arbeit muss es doch wohl vorwärts gehen!

Oder ist damit etwa nur die banale Erkenntnis gemeint, dass man vor jedem Vorhaben zunächst Ziele definiert und dann den Weg zur Erreichung derselben plant? Das ist doch selbstverständlich und das macht doch jeder. Oder?

Aber nein, die Rückwärts-Arbeiten-Methode ist weder neu, noch hat sie etwas mit Agilität á la SCRUM zu tun. Es ist ein Amazon Eigengewächs und wurde Anfang der 2000er Jahre von Jeff Bezos und Werner Vogels entwickelt und als ein wesentlicher Bestandteil der Amazon Produkt Entwicklung eingeführt. Auf der anderen Seite steht die Methode nicht im Widerspruch zu agilen Methoden und kann sehr wohl in Kombination mit diesen angewendet werden.

Aber was ist das denn und wozu braucht man das? Wir machen doch schon eine Rückwärtsplanung mit Lastenheft und Pflichtenheft, Ressourcen und Meilensteinen auf einem schönen großen Gantt-Projekplan. Mehr geht doch wohl nicht? Sagt vielleicht der Projektleiter mit dem V-Modell XT Bund unterm Arm.

Aber – Hand aufs Herz – wieviele solcher Projekte laufen wirklich nach Plan? Wie oft müssen Meilensteine geschoben, Ressourcen neu geplant, Ziele neu formuliert werden? Nun genau dafür hat man doch die agilen Methoden entwickelt, als Ausweg aus dieser Planungshölle sozusagen. Iterativ und nach vorne tastend mit 14-täglichen Inkrementen, die dann dem Kunden zur Verfügung gestellt werden. Das ist der moderne Weg. Da kann dann maximal ein Inkrement daneben gehen.

Wer genügend Erfahrungen im agilen Umfeld größerer Unternehmen gesammelt hat, dem fallen womöglich Beispiele ein, wo auch das leider nicht immer klappt. Inkremente werden erstmal auf Verdacht entwickelt, weil sich noch kein Nutzer findet, der die Alpha Version des Produkts schon hilfreich findet. Oder man deklariert Iterationen und Inkremente einfachheitshalber als technische Artefakte, Vorarbeiten, die zunächst die Grundlagen legen müssen für wirklich nutzbare Software. Und so werkeln die Ingenieure Monat um Monat vor sich hin. So lange die Budgets da sind.

Kompatibel mit Agilen und anderen Methoden

Werner Vogels, bis heute Amazon CTO, plädierte in seinem Blog All Things Distributed für die Anwendung der Methode und erläutert, wie auch die Technik Teams davon profitieren.

Die Working Backwards Methode steht nicht im Widerspruch zu anderen Methoden der Produkt-Entwicklung, nur beginnt sie eben am Ende und sie stellt den Kunden in den Mittelpunkt. Es geht nicht um die Planung eines Projekts, sondern um die Erarbeitung der Arbeitsergebnisse in umgekehrter Reihenfolge. Ein Projekt beginnt typischerweise mit der Formulierung einer Presse Veröffentlichung zu dem zu entwickelnden Produkt. Dabei ist es unerheblich, ob später tatsächlich eine solche Mitteilung erscheint oder nicht.

Es geht in diesem Schritt darum sich die größere Idee des Produkts oder Services zu erarbeiten. Welcher Kunde hat welchen Nutzen von dem Produkt und warum sollte ihn das Produkt interessieren. Und man kennt es von Presse Veröffentlichungen und der notgedrungenen Kürze derselben. Es ist immer nur ein Anriss, der bestenfalls das Interesse möglicher Kunden weckt. Es bleiben danach immer sehr viele Fragen offen. Wie soll das denn überhaupt im Detail funktionieren? Wie wird das bepreist?

Deswegen ist das nächste Dokument, das man erarbeitet ein FAQ, das alle Fragen, die sich danach stellen beantwortet. Der fiktive Kunde, dessen Interesse durch die fiktive Presserveröffentlichung geweckt worden war, hat nun plausible Antworten auf seine möglichen Fragen.

Der nächste Schritt ist es die User Experience zu erarbeiten, wie fühlt sich das Produkt an bzw. wie soll es sich für den Kunden anfühlen? Dieser Schritt ist abhängig von dem konkreten Produkt und bei dem zu erarbeitenden Artefakt kann es dabei um einen Prototypen, Wireframe oder ähnliches handeln.

Danach wird das Handbuch zum Produkt oder Service entwickelt, das alle funktionalen Details des Produkts aus Sicht des Kunden beschreibt.

Mit diesen Schritten ist die Working Backwards Methode abgeschlossen und es kann das Wasserfall oder agile Entwicklungsprojekt ansetzen. Das geht dann wieder ganz normal vorwärts. Aber die Zielrichtung eines solchen Projekts ist dann sonnenklar und genauestens spezifiert.