Dimensional Planning in Agile

In den letzten Jahren habe ich festgestellt, dass ich immer häufiger über das „Dimensional Planning” spreche. Ich habe durch Koen van Exem, einem der frühen belgischen Agilisten, von Dimensional Planning erfahren. Es stammt aus der Anfangszeit der (belgischen) Agile-Bewegung und ist leider etwas in Vergessenheit geraten.

Gestern habe ich mich mit JB (Rainsberger) und Alistair (Cockburn) darüber unterhalten und festgestellt, dass ich dazu noch eine nette Geschichte auf Lager habe.

Bevor ich sie Ihnen erzähle, erkläre ich aber erst noch kurz die Grundlagen von Dimensional Planning. Der Gedanke dahinter ist, dass wir unsere Stories in verschiedene Implementierungsdimensionen aufspalten. Das tun wir, weil viele unserer Kunden am Ende der Woche einen Lexus haben wollen. Das schaffen wir aber vielleicht nicht. Allerdings können wir ihnen schon morgen einen Toyota anbieten. Die meisten Kunden finden dieses Angebot toll und können abwarten, bis wir den Lexus liefern können (aka schnell erzielter ROI).

Die Art und Weise, wie Koen Dimensional Planning erklärt, gefällt mir sehr gut

Stellen Sie sich vor, Ihr Kunde möchte eine Autobahn zwischen Amsterdam und Heusden haben. Sie sind ziemlich gut darin, Autobahnen zu bauen, also fangen Sie direkt an. Nach einigen Monaten sind Sie fertig und lassen Ihren Kunden voller Stolz zum ersten Mal die Autobahn benutzen. Er kommt in Heusden an, sieht aber nicht besonders glücklich aus. Sie fragen also, ob die Tankstellen, die Rastplätze und die Ausfahrten alle paar Kilometer in Ordnung sind. Obwohl der Kunde alles bejaht, scheinen ihn Ihre Fragen nur noch mehr aufzuregen. Schließlich rückt er mit der Sprache heraus: „Das ist nicht der Ort, zu dem ich wollte!”

Sie schauen sich das Ortsschild an: Heusden. Wollte er nicht nach Heusden? Doch, wollte er.

Es stellt sich aber heraus, dass es noch einen anderen Ort mit dem Namen „Heusden” gibt.

Ihre Anwälte und die des Kunden haben jetzt lange Diskussionen darüber, wessen Fehler das ist und wer für die falsche Autobahn zahlen muss. (Wenn Sie einen guten Rechtsanwalt haben, wird Ihr Kunde zahlen und nie wieder kommen…)

In diesem Fall könnte man gut mit Dimensional Planning arbeiten. Man würde dann zuerst eine Schotterstraße zwischen Amsterdam und Heusden anlegen.

Nach nicht einmal einer Woche wären Sie schon fertig damit und hätten festgestellt, dass Sie den falschen Ort erwischt haben. Für Sie ist das kein Problem, denn Sie wussten, dass es das ein oder andere Missverständnis geben würde. Sie machen sich kundig, finden das andere Heusden und bauen eine neue Schotterstraße. Nach einer weiteren Woche ist auch diese Straße fertig und Sie stellen zusammen mit Ihrem Kunden fest, dass es tatsächlich immer noch das falsche Heusden ist. Es gibt nämlich zwei Orte mit diesem Namen in Belgien und noch einen in den Niederlanden. Wer konnte das schon ahnen?

Nach einer weiteren Woche ist Ihr Kunde glücklich, endlich eine Schotterstraße zwischen Amsterdam und dem richtigen Heusden zu haben. (Und das viel schneller als ursprünglich in mehreren Monaten.)

Obwohl es noch nicht alle Features gibt, gibt es doch schon einen gewissen Gewinn zu verzeichnen, da der Kunde jetzt zwischen den beiden Standorten seines Unternehmens pendeln kann. Es ist keine tolle Straße und man kann nicht sonderlich schnell fahren aber es ist wesentlich schneller als mit der vorherigen Straße und einem Umweg von 100 km.

Am Tag nach der Fertigstellung der Schotterstraße fangen Sie an, an einer Kopfsteinplaster-Version der Straße zu arbeiten, die Sie nach drei Wochen auch fertiggestellt haben. Sie können ebenso an einer Asphalt-, Teer- oder Autobahn-Version arbeiten. In den meisten Fällen wollen die Kunden die Autobahn aber gar nicht mehr, sobald sie einen Nutzen aus den vorherigen Versionen ziehen können.

Wir alle wissen, dass ein Kunde immer „Ja” sagen wird, wenn wir ihn fragen, ob er eine Autobahn haben will, und dass Entwickler es lieben, an all den Features für eine Autobahn zu arbeiten.

In unserem Auto-Beispiel würden die meisten Leute auch den Lexus dem Toyota vorziehen – bis es ans Bezahlen geht, denn dann reicht ein Toyota plötzlich auch. Und ebenso möchte auch nicht jeder Entwickler ständig an alle Details denken müssen, die der Lexus erfordert.

Ist es denn nicht teuer, drei Schotterstraßen, eine Kopfsteinpflasterstraße, eine Teerstraße und eine Autobahn zu bauen?

Natürlich ist es teurer, als nur eine Autobahn zu bauen. Wir wissen aber alle, dass Fehler passieren und dass es immer noch billiger ist, als drei Autobahnen bauen zu müssen, wie es oft in der Produktentwicklung vorkommt.  

Bei meiner Methode bereiten wir uns aber so gut vor, dass wir nie Fehler machen…

Wenn Sie sich sicher sind und das Risiko eingehen wollen, können Sie das natürlich gerne tun. Und auch wenn Sie Recht behalten (ich bezweifle, dass das immer der Fall sein wird), bin ich mir jedoch relativ sicher, dass die meisten Kunden ihre Meinung bereits geändert haben, wenn Sie anfangen, die Autobahn zu bauen. Und Monate, bevor Sie auch nur angefangen haben zu bauen, liefern unsere Schotterstraßen dann schon Return on Investment.

Das klingt theoretisch ja ganz nett. Funktioniert es in der Praxis denn auch wirklich?

Gute Frage! Fast hätte ich es vergessen; Ich wollte in diesem Artikel ein schönes Beispiel aus dem echten Leben vorstellen:

Ich habe ein paar Einzelheiten der Geschichte verändert, um den Kunden zu schützen.

Es geht um die Webseite eines Unternehmens. Diese befand sich jedoch in einer komplett entmilitarisierten Zone des Firmennetzwerks. Dort hatte man ein kleines Produkt geschaffen, das über das Internet vertrieben werden sollte. Der Chief Financial Officer (Finanzchef) war ein großer Befürworter dieses Produkts und wollte die Verkaufszahlen regelmäßig vorgelegt bekommen. Dafür hätten allerdings Sicherheitszonen verletzt werden und die Verkaufsdaten in das SAP-System eingefügt werden müssen.

In einem großen Unternehmen ist das ein ziemlich großes Projekt, das bestimmt sechs Monate an Entwicklungsarbeit benötigt. Die Vorbereitungen begannen mit Meetings mit mindestens 20 Personen (Sicherheitsexperten, SAP-Experten, Webentwickler und eine Menge an Managern bis zur Position unterhalb des CFO).

Bei einem darauffolgenden Meeting beklagte sich der CFO über die schlechte Erkennbarkeit der Absatzentwicklung für das Produkt innerhalb der wichtigen ersten sechs Monate. Ich empfahl also vorübergehende Nebenprojekte unter der Verwendung von Dimensional Planning (wie bei dem Autobahn-Beispiel).

Die Schotterstraßen-Version:

Jeden Tag generierten wir einen PFD-Bericht auf dem Webserver und speicherten ihn auf einer Floppy Disc. (Wir erinnern uns, dass ein Großteil des Netzwerks nicht mit dem Server verbunden war.) Jeden Tag druckten wir diesen Bericht aus und brachten eine Kopie der Verkaufzahlen in das Büro des CFO, wo ein Praktikant alle Daten in unser SAP-System eintrug. Der PDF-Bericht wurde von einem unserer Entwickler am gleichen Tag erstellt, an dem das Produkt live ging. Am Ende des Tages hatten wir dann bereits die Daten für den CFO.

Das erste Problem: Der CFO wollte etwas Zusätzliches; etwas wonach der Kunde auf der Webseite gefragt werden sollte. Der Entwickler hatte den Bericht stolz dem CFO gezeigt und ging nun zurück an seinen Arbeitsplatz. Eine halbe Stunde später wurde auf der Webseite die zusätzliche Information abgefragt und der neue Bericht erstellt (ohne die Daten des ersten Tages). Schon am nächsten Tag erschien ein Zeitungsartikel und viele Kunden kauften das Produkt. Am Tag danach kamen bereits die ersten Zahlen rein und unser Praktikant versuchte, die Daten ins SAP-System zu übertragen. Hier entdeckten wir unser zweites Heusden. Es stellte sich nämlich heraus, dass wir die falsche SAP-Tabelle verwendeten. Es dauerte einige Tage, diesen Fehler zu beheben. Der CFO bekam weiterhin seinen Bericht, jedoch konnte das in der ersten Woche noch nicht mit SAP geschehen. Am Freitag der ersten Woche war der Praktikant in der Lage, die Daten hochzuladen. Allerdings war das eine recht langweilige Arbeit, die absolut nicht skalierbar war. (Wir hatten einige tausend Verkäufe in der ersten Woche.) Jetzt war es an der Zeit für unsere:

Kopfsteinpflaster-Version:

Dieses Mal erstellten wir den Bericht in einem CVS-Format. (Denken Sie daran, das war vor XML.) Jeden Morgen ging also der Entwickler, der als erster im Büro ankam, zum Webserver, generierte den Bericht und kopierte ihn auf eine Floppy Disc. Dann nahm er die Disc und lud die Daten in unser SAP-System hoch. Diese Version war stärker skalierbar; egal wie viel wir am vorigen Tag verkauft hatten, die Arbeit für unseren Entwickler blieb gleich. Aber auch in dieser Version hatten wir ein kleines Problem. Eines der Felder war als Text anstatt als Zahl formatiert. (Ein ganz normaler Bug.)

Die Arbeit musste jeden Tag persönlich von jemandem durchgeführt werden. Sie war nicht automatisiert und es wurde auch nur einmal am Tag eine Aktualisierung durchgeführt (für den vorherigen Tag).

Nun gingen die Meetings für die Autobahn-Version los. Am Ende eines solchen Meetings fragte ich einen Mitarbeiter des CFO, wie sie die Daten nutzten und ob sie mit den Zahlen zufrieden waren. Rein zufällig fiel mir dabei auf, dass der CFO sich nur freitags die Daten anschaute. (Also nicht täglich.) Es machte ihm nicht mal etwas aus, dass er nicht über die vollständigen Verkaufszahlen des Tages bzw. der Woche Bescheid wusste.

Die Autobahn-Version:

Glücklicherweise hatte ich am nächsten Tag sowieso ein Meeting mit dem CFO und seinem Mitarbeiter. Wir sprachen über den Fortschritt des Autobahn-Projekts und darüber, dass es eigentlich die Leute davon abhielt, an einem wichtigen anderen Projekt zu arbeiten. Ich schlug höflich vor, bei der Kopfsteinpflaster-Version zu bleiben und das Autobahn-Projekt vorerst auf Eis zu legen. Viele Leute im Unternehmen freuten sich nicht sonderlich darüber, denn sie wollten so gerne an diesem super coolen Projekt arbeiten. Der Security Officer war jedoch ganz glücklich damit, denn so konnte der Webserver im sicheren Bereich bleiben. Letzten Endes sparte sich das Unternehmen sechs Monate an Entwicklungsarbeit für eine Autobahn, die das Netzwerk in Gefahr gebracht hätte und nicht wirklich notwendig gewesen wäre.

Nach einigen Jahren traf ich den CFO wieder. Er gab zu, dass das Autobahn-Projekt wohl etwas zu viel gewesen wäre, denn das Produkt hatte nie nur ansatzweise so viel Geld eingebracht, wie man für das Autobahn-Projekt hätte ausgeben müssen. Dank des Schotterstraßen-Projekts konnten sie schon ziemlich früh herausfinden, dass die E-Mail Adressen der Kunden noch fehlten und das war das Beste, was ihnen passieren konnte. Mit dieser E-Mail-Liste konnten sie in den nächsten Jahren nämlich einige weitere Services and die Kunden verkaufen und das bewahrte das Unternehmen vor dem Bankrott.

Der folgende Text stammt aus dem Blog von Yves Hanoulle und wurde von uns ins Deutsche übersetzt.