Im ersten Blogbeitrag haben wir uns mit dem ersten Prinzip des agile.agreements «Kooperation vor Spezifikation» befasst. In diesem Beitrag beleuchten wir das zweite Prinzip des agile.agreements «Enough Design Upfront» (EDUF) vor «Big Design Upfront» (BDUF). Daneben gibt es noch das «No Design Upfront» (NDUF).
All diese Ansätze sind Antworten auf die Fragen: Wie detailliert muss ich im Voraus meinen zu entwickelnden Leistungsgegenstand und meine Bedürfnisse beschreiben? Wie gehe ich dabei am besten vor?
Big Design Upfront
Der BDUF-Ansatz basiert auf der Annahme, dass zu Beginn alle Bedürfnisse genau beschrieben werden können. In einem aufwendigen Prozess wird beschrieben was das Ergebnis alles können soll, wo die möglichen Probleme liegen etc. Erst wenn alles vermeintlich genau beschrieben wurde, wird mit der Umsetzung begonnen.
Dieser Ansatz stammt aus der Zeit in welcher «einfache» oder «komplizierte» Probleme (vgl. Cynefin Blog) dominierten und entwickelt werden mussten. Die heute zu lösenden Probleme sind jedoch viel «komplizierter» oder sogar «komplexer» geworden.
Der BDUF-Ansatz kann damit schlecht umgehen, denn Änderungen die während der Umsetzung auftreten, sind mit hohen Kosten verbunden. Dies führte folglich dazu, dass in der Beschreibung der Bedürfnisse auch viele unwichtige resp. unwesentliche Bedürfnisse aufgenommen werden, um eben danach keine zusätzlichen Kosten zu erfahren. Dies führt letztendlich zu noch umfangreicheren Beschreibungen und aufwendigeren Prozessen.
Was sind aber die Vorteile von BDUF?
- Sofern sehr klar ist, was meine Bedürfnisse sind und wie mein Ergebnis aussehen soll, ist dies ein sehr effizienter Ansatz.
- Dadurch, dass alles bekannt ist, kann man sich von Anfang an einen guten Überblick über das Ganze verschaffen und kann mögliche Konflikte schon im Voraus beseitigen.
- Die Kosten können berechnet werden und sind bekannt – dies gibt Planungssicherheit.
Was sind die Nachteile von BDUF?
- Gefahr das möglichst alles, auch viele unwichtige resp. unwesentliche Bedürfnisse beschrieben werden.
- Nachträgliche Änderungen sind äusserst ressourcenintensiv.
- Das Ergebnis wird meist nicht inkrementell eingeführt. Daher erfährt man erst am Schluss durch umfangreiche Tests, wie funktional die Entwicklung ist. Mögliche Fehler werden erst spät festgestellt. Dies führt dazu, dass wesentliche Schritte nochmal gemacht werden müssen.
- Learnings, die während dem Prozess gemacht werden, fliessen nicht resp. zu spät in das Produkt ein.
No Design Upfront
Der komplette Gegensatz zum BDUF ist das NDUF, und damit die ausgeprägteste Form des agilsten Ansatzes. Dabei beginnt man praktisch sofort mit der Entwicklung, ohne dass zuvor Zeit in ein Design investiert wurde. Oft dient eine Produkte-Vision und ein grobes Produkte-Backlog als Ausgangslage, das in einer sogenannten «Iteration Zero» resp. «Sprint Null» auf die erste produktive Iteration resp. «Sprint 1» vorbereitet wird.
Während dem Entwickeln werden neue Inputs und Ideen laufend aufgenommen und umgesetzt. Ein so freier Ansatz benötigt sehr sehr viel Erfahrung. Die allermeisten laufen dabei Gefahr unstabile Architekturen zu entwickeln und Ressourcen in die Entwicklungen zu investieren die sich im Nachhinein als redundant oder unbrauchbar herausstellen.
Passend dazu das Zitat von Dave Thomas, einem der Autoren des «Agilen Manifests»:
"Big design up front is dumb, but doing no design up front is even dumber." (BDUF ist dumm, aber NDUF ist noch dümmer.)
Enough Design Upfront
Wie so oft liegt die Wahrheit oder in diesem Falls die Lösung in der Mitte. Somit landen wir beim EDUF, dem Ansatz, den auch das agile.agreement verfolgt.
Der EDUF-Ansatz besagt zwei Dinge: Einerseits, dass gerade so viel wie nötig – nur die wichtigsten Bedürfnisse (MVP «Minimum Valuable Product») – im Voraus definiert werden sollen und andererseits gibt er vor zu welchem Zeitpunkt die Bedürfnisse in welchem Detaillierungsgrad (vgl. Vision2Code, agilist) vorliegen müssen. Es ist wichtig, diese Bedürfnisse zu benennen, denn diese dienen für den Entwicklungsprozess als Orientierung. Dabei bleibt aber nach wie vor Platz für laufende Anpassungen und Ergänzungen.
Warum EDUF?
- Kombiniert Aspekte von BDUF und NDUF
- Durch die grobe Bedürfnisbestimmung kann der Umfang des Projekts ungefähr bestimmt und von den wichtigsten auf die anderen Bedürfnisse hochgerechnet werden (vgl. Relatives Schätzen, agilist, edorex). Es ist folglich möglich vertraglich den Leistungsumfang, die Liefertermine und die Kosten zu regeln.
- Anpassungen und neue Ideen können laufend berücksichtigt werden.
- Während dem Prozess gelerntes kommt beiden Vertragspartner zugute, da die Entwicklung ein gemeinsames Projekt ist.
Ein verständliches Beispiel zur Unterscheidung von EDUF und BDUF ist die Planung eines Fahrzeuges:
Mit dem BDUF beschreiben wir wie in einem Katalog alle Eigenschaften des Fahrzeuges und engen sehr schnell ein, dass es ein Auto wird. Beim EDUF-Ansatz ist klar, es soll ein Fahrzeug werden, welches die wichtigsten Bedürfnisse abdeckt. Wie diese explizit befriedigt werden, wird sich erst während der Entwicklung herausstellen, denn es gibt mehr als einen Lösungsansatz dafür und evtl. wird es dann auch kein Auto sein müssen.
Das agile.agreement vereint durch die Verwendung des Enough Design Upfront die Vorteile der beiden Extrema BDUF und NDUF. Somit ist es möglich, ein agiles Projekt zum Fixpreis resp. Kostendach zu beschaffen und gleichzeitig dafür zu sorgen, dass die Ziele (offener Scope, feste Zeit & Budget) eingehalten werden.
Welche Erfahrungen hast du mit diesen oder ähnlichen Ansätzen gemacht? Und was hat Dich daran überzeugt?
Kommentar schreiben