In meinen Projekten geht es meistens um individuelle Softwareentwicklung. Das fehlende Puzzlestück im Geschäftsmodell selber zu erstellen kann oft kostengünstiger sein, als eine Standardlösung mit Konfigurationsaufwand und laufenden Lizenzkosten. Die Projekte sind dabei so vielfältig wie die Branchen es sein können. Der Schwerpunkt meiner Erfahrung liegt bei den klassisch denkenden Auftraggebern, die sich mit viel Tradition im Gepäck den Herausforderungen des heutigen Marktes stellen müssen.

Auch bei vielen traditionsreichen Unternehmen setzt sich vermehrt die Erkenntnis durch, dass Agiles Projektvorgehen viele Vorteile mit sich bringt und nicht mehr per se infrage gestellt wird.

So habe ich in zahlreichen Diskussionen mit Projektleitern und Entscheidern über das hybride Projektvorgehen “Agiler Festpreis” (1) gesprochen und ihnen die Vorteile (2) erläutert. Es war nicht schwer, sie von dem iterativen Vorgehen und der engen Zusammenarbeit mit Anwendern zu überzeugen.

Die größten Schwierigkeiten entstanden bei dem Verständnis der Projektsteuerung.

Verzichten? Nein Danke!

Aus dem Leistungsdreieck kann abgeleitet werden, wann welches Vorgehen und welche Steuerung passender ist (3).

• Sollte der Scope fest sein – was er bei Hardware-Projekten oft ist – dann müssen Termine und Budget variabel bleiben
• Wenn Budget und Termine fest sind – was mir oft bei meinen Software-Projekten begegnet – dann muss der Scope variabel sein

Mehr Budget zu beantragen oder den Termin zu verschieben war aus deren Erfahrung gewohnter, als der andere Weg, den Scope zu ändern. Dabei muss man doch nur Dinge weglassen können.

Aber welche?

Das Optimum herausholen

Unser hybrides Vorgehensmodell “Agiler Festpreis” soll zwei Dinge in einem Projekt für den Auftraggeber erreichbar machen:

• Einhalten von Budget und Terminen
• Den Scope zu einem Optimum führen

Am Ende des Budgets sind die Projektergebnisse fertig, nutzbar und bringen den maximal erreichbaren Nutzen. Das Geld ist also optimal investiert.

Die Herausforderung besteht nun also darin, das Projekt so aufzusetzen, dass man

• jederzeit etwas hinzufügen oder weglassen kann
• schnell eine Entscheidung treffen kann, worin das Budget investiert wird

Das Setting macht’s

Auch auf Basis eines klassischen Wasserfall-Projektes kann eine Entkoppelung vorgenommen werden. Unter Berücksichtung der technischen Abhängigkeiten zwischen den Anforderungen und dem Bedarf des Marktes lassen sich große Projekte in viele Teilprojekte zerlegen.

Das folgende Beispiel zeigt die Parallelisierung des Wasserfalls in mehrere Features, die durchaus als Iterationsschleifen (bzw. Sprints) verstanden werden können.

Im Ergebnis wird nicht nur der Release-Termin vorgezogen, sondern auch entschieden welches Feature zuerst umgesetzt werden soll. Das time2market wird steuerbar (4). Einen Schritt weitergedacht, lässt sich damit auch das Budget steuern: Lässt man ein Feature weg, reduzieren sich die Kosten.

Der Ansatz lässt sich mittels design2cost (2) auch auf den Umfang eines Features anwenden. Dann werden die Anforderungen innerhalb des Features Muss, Soll und Kann unterteilt. Bei Bedarf wird auf die Kann-Funktionen eines größeren Features verzichtet.

Wie treffe ich eine Entscheidung?

In jedem Projekt sollte es darauf ankommen, das Richtige umzusetzen und das weniger Wichtige sein zu lassen. Unabhängig von agilem oder klassischem Projektvorgehen.

Damit nähern wir uns dem Hauptproblem.

Meine Ansprechpartner haben durchaus das Verständnis dafür, dass man etwas weglassen muss. Sie haben aber Schwierigkeiten dabei, die Anforderung zu finden, die man in der aktuellen Situation weglassen sollte. Darüber hinaus muss diese Entscheidung ja auch kommuniziert und dem Top-Management verständlich erklärt werden.

Die Lösung für dieses Problem verbirgt sich in der Betrachtung des Nutzens einer Anforderung.

Kenne ich den Nutzen, dann kann ich alle Anforderungen gegen deren Kosten abwägen und setze nur die um, die in einem gewählten Budget den Nutzen maximieren. Die Berechnung des Nutzens ist allerdings nicht so leicht. Dennoch gibt es einen sehr guten Ansatz, den ich in dem Artikel “Von der Impact Map zu User-Storys: Wie Stakeholder und Entwickler gemeinsam eine Strategie verfolgen” von Dr. Monika Schubert (5) gefunden habe.

Im Grunde genommen geht es darum, die vielen kleinen Anforderungen in Form von User Stories so zu strukturieren, dass man in der Lage ist, nur das feiner auszuarbeiten und später umzusetzen, was am meisten Nutzen bringt.

• Mit der Impact Map werden aus dem Geschäftsziel (Warum?) die benötigten Features (Was?) entwickelt. Diese Features haben eine Wirkung (den Impact), indem sie einer Nutzergruppe (Wer?) geeignet dabei helfen, das Geschäftsziel zu erreichen (Wie?).
• Die Features wiederum sind die Basis für die Ausarbeitung in einer Story Map. Deren Struktur ist geeignet, etwaige Prozesse und deren Varianten abzubilden und in entsprechenden User Stories darunter abzulegen. Innerhalb der Story Map werden Priorisierungen vorgenommen.

Mit Hilfe dieser Struktur lassen sich Roadmaps erstellen, deren Inhalte den größten Nutzen erzielen. Ein passender Schnitt verlagert Funktionen mit aktuell weniger Wirkung in ein späteres Release.

Viele positive Erfahrungen

Während des letzten Jahres habe ich mit dieser Strukturierung gearbeitet und mehr positive Erfahrungen gemacht, als ich zuerst dachte:

• Die Methode ist geeignet alle Anforderungen aufzunehmen und an geeigneter Stelle abzulegen – es benötigt keinen extra Themenspeicher mehr.
• Die unterschiedlichen Detailebenen von Impact Map, Story Map und User Story lassen auch Iterationen von Schätzungen von grob nach fein zu – Schätzungen bei Unwägsamkeiten werden geübt und auch schon frühzeitig die vermuteten Kosten in die Entscheidungen einbezogen.
• Es ist eine Fokussierung möglich, mit den wirklich relevanten Dingen zuerst anzufangen – nicht alle denkbaren Features einer Impact Map müssen feiner konzipiert werden. Aufwände in der Anforderungserhebung können zielführend gesteuert werden.
• Die konsequente und frühzeitige Trennung nach Rollen führt zu einem stringenten Verständnis für die Anwendergruppe und deren benötigte Features – ein “Feature-Overloading” wird vermieden. Anwendungen wie Word, die alles in einer GUI können, werden verhindert.
• Wenn man das Verfahren umdreht, ist es sogar geeignet, die Domäne des Kunden und seine Probleme besser zu verstehen – ein Lastenheft wird hinterfragbar (6)

Fazit

Die Steuerung des Agilen Festpreis ist möglich, wenn man die richtigen Dinge weglässt oder hinzunimmt. Dabei helfen die geeignete Kombination der Methoden Impact Map, Story Map und User Story.

• Impact Map – Die konsequente Betrachtung von Geschäftsziel und Nutzen: Hervorragend für die Präsentation und Diskussion mit dem Top-Managemenent.
• Story Map – Die gesamte Geschichte des Erlebens eines Features: Sehr Vorteilhaft für den Vertrieb und die richtige Ansprache der Zielgruppe.
• User Story – Die Details eines Features aus Anwendersicht: Die Ansprache an die Entwickler mit deren Hilfe auch die Akzeptanzkriterien festgelegt werden.

In der Summe wird damit nicht nur der Sinn und Zweck einer User Story für den Entwickler transparenter, sondern vielmehr auch eine transparente Entscheidung möglich, was man innerhalb eines Budgets umsetzen sollte und was nicht.

Das Weglassen fällt leicher.

Tassilo Kubitz

 

Quellen:

(1) akquinet AG – Agile Festpreisprojekte – akquinet.de

(2) Tassilo Kubitz – Agile Festpreisprojekte – Risiko oder Chance? – blog-de.akquinet.de 29.04.2014

(3) Atlassian –  The iron triangle of planning

(4) Tassilo Kubitz – Agile Roadmaps in der Softwareentwicklung – blog-de.akquinet.de 08.10.2014

(5) Dr. Monika Schubert (Opitz Consulting) – Von der Impact Map zu User-Storys: Wie Stakeholder und Entwickler gemeinsam eine Strategie verfolgen – OBJEKTspektrum 02/2016 (Seite 20-25)

(6) Tassilo Kubitz – Von der Lösung zum Problem – Impact Mapping mal anders herum – blog-de.akquinet.de 08.10.2014