Lesezeit: 5 Minuten

Was kann verändert werden? Was wäre die Lösung?

Agiles Controlling & Contracting | Teil 2

Kurzer Rückblick

Im ersten Blogbeitrag "Alte Vorgehensweisen & warum diese Methodiken scheitern (müssen)" zeigte ich auf, warum das bisherige klassische Vorgehen "Projekt Webseite" scheitern musste. Das war für viele hoffentlich nicht überraschend. Nur die Erkenntnis bringt ja leider noch keine Lösungen. Also welche Schlussfolgerungen ziehe ich daraus.

Mein Weg zur Lösung

Umsehen, umhören, zuhören, lesen, diskutieren

Seit geraumer Zeit beschäftige ich mich mit agilen Methoden. Das ist auch meiner vorigen Tätigkeit als Projekt Manager geschuldet. Ich besuche sowohl agile Konferenzen als auch einigermaßen regelmäßig den Agile Round Table der DB Systel und die Agile UG Unterfranken. (Mein Weg nach Würzburg ist einfach kürzer als der nach Frankfurt.). Hier entstand mein Kontakt zur Mayflower GmbH. 

Als Account Manager beschäftige ich mich notgedrungen mit agilen Vertragswerken. Wir haben versucht ein Projekt mittels eines agilen Festpreises umzusetzen und sind krachend gescheitert. Relativ schnell tun sich hierbei ähnliche Probleme wie bei klassischen Projekten auf. Die Entscheidungswege auf Kundenseite waren viel zu lange. Dadurch hätte das Projekt immer wieder gestoppt werden müssen. Das wiederum hätte in einer Stop-and-Go-Entwicklung gemündet, wodurch Leerlaufzeiten bei den Entwicklern und eine nicht kalkulierbare Laufzeit des Projektes entstanden wäre. Meine persönliche Erkenntnis daraus war, dass wir das nicht wiederholen sollten und dürfen.

Außerdem drehten sich meine Gedanken zunehmend darum, wie wir unseren Kunden bessere und verständlichere Angebote schreiben können. Die von uns eingesetzten, auf Excel basierenden Backlogs waren keine Hilfe. Im Gegenteil, unser Kunde verstand sie nicht, da sie viel zu technisch und teilweise unspezifisch waren oder sein mussten. Das Format einer Excel-Tabelle störte die Übersichtlichkeit. In Zeile 6 hatte man häufig schon vergessen, was in Zeile 1 stand. Wir hatten also Vertragswerke mit einem Backlog die nicht funktionierten.

Ein entscheidender Fortschritt für mich war der Workshop „Agile Controlling und Contracting“ von Björn Schotte, Geschäftsführer der Mayflower GmbH. In diesem Workshop zeigte Björn weniger, welche Verträge zum agilen Arbeiten taugen, sondern, was agiles Arbeiten in der Zusammenarbeit mit dem Kunden alles bedeutet. Björn erwähnte im Workshop auch, welche Verträge zur agilen Vorgehensweise passen. Dies war allerdings schnell abgehandelt, da dies seiner Erfahrung nach nur Dienstleistungsverträge sein können. Er erklärte noch, dass Mayflower ihren Kunden einige Klauseln zu deren Sicherheit gewähren. Diese Mechanismen wären kundenseitig aber noch nie wirklich in Anspruch genommen worden. Wir investierten viel Zeit in Controllingmechanismen und -metriken, auch außerhalb der reinen Effizienzbetrachtung, und in das Handling der Stakeholder. Zusammengefasst war es für mich ein sehr wertvoller Workshop. 

In diesem Workshop machte er auch auf das Buch „User Story Mapping“ von Jeff Patten aufmerksam. Ein sehr anschauliches Buch zum Anforderungsmanagement. Aktuell versuchen wir diese Techniken des Anforderungsmanagements nach und nach bei uns zu etablieren. Meine Erfahrungen sind überwiegend positiv. Auf jeden Fall erscheint es ein probateres Mittel, als die bisherigen Backlogs.

Einen äußerst wichtigen Austausch hatte ich mit Sven Ditz von sitegeist. Als mich mein Weg aufgrund eines Kundentermins nach Hamburg führte, nutzte ich die Gelegenheit, ihn in seiner Agentur zu besuchen. Dort sprachen wir 6 Stunden über Kunden, Projekte, Verträge und sein RE.A.L-Modell. Diese Vorgehensweise faszinierte mich sofort. Er hatte mich schnell davon überzeugt, dass es funktionieren kann.

Für mich die Lösung

Mit dem festen Wunsch, es in der dkd mit diesem Modell zu probieren, trat ich an unsere Geschäftsführung heran. Schnell kamen wir zur Übereinkunft, es zu probieren. Im Nachhinein bin ich mir nicht mehr so sicher, ob ich sie wirklich überzeugt hatte oder unsere Geschäftsführer der Meinung waren, dass es sowieso nicht klappen würde und ich es deshalb ruhig ausprobieren könne. 

Ich habe das Modell bei potentiellen Neukunden vorgestellt und bin überraschenderweise sofort auf offene Ohren gestoßen. Spätestens bei den - im vorigen Blogbeitrag - erwähnten Projektproblemen kam immer Kopfnicken und Zustimmung auf Kundenseite. Im weiteren Projektanbahnungsverlauf blieb es natürlich nicht aus, dass angemerkt wurde, dass das Vorgehen mit ihrem Einkauf nicht machbar wäre. Allerdings war es zu diesem Zeitpunkt mehrfach äußerst hilfreich, dass wir die Kunden mit unserer fachlichen Expertise bereits überzeuget hatten. Allerdings war ich auch konsequent genug, auf der Vorgehensweise zu bestehen und dem Kunden zu bedeuten, dass eine Zusammenarbeit nur unter RE.A.L-Bedingungen möglich wäre. Der Akquise-Erfolg hat mich dann ehrlich gesagt selbst überrascht. Wir konnten innerhalb kürzester Zeit, vier von fünf potentiellen Neukunden von uns und unserem Vorgehen überzeugen. Ob wir dies auch mit dem klassischem Vorgehen erreicht hätten, ist nicht zu beantworten. Allerdings war mit dem klassischen Modell früher unsere Abschlussquote wesentlich geringer.

Aber wofür steht RE.A.L eigentlich

Sicher brauche ich dem ein oder anderen RE.A.L nicht mehr erklären, da Sven Ditz es schon seit einigen Jahren propagiert. Diejenigen können gleich mit meinem vorläufigen Fazit fortfahren. Der Rest sollte hier weiterlesen.
RE.A.L ist ein Akronym für Raw Estimation, Agile and Lean.

Raw Estimation

Zu Beginn steht nur grob fest, was das neue Produkt denn überhaupt können soll. Deshalb können diese Projekte auch nur grob geschätzt werden. Wir sehen uns also diese Anforderungen an und schätzen auf Basis unserer Erfahrung, wie lange wir dafür mit wie vielen Leuten ungefähr brauchen werden.

Agile

Unsere Teams bedienen sich agiler Methoden, um das Produkt zu entwickeln. Das Framework definieren wir im Vorfeld nicht. Was wir aber definieren, ist die Länge der Entwicklungszyklen (Sprints oder Releases). Die dauern normalerweise zwei Wochen. 

Nach jedem Entwicklungszyklus bekommt der Kunde ein Budget- und Epic Burndown. So hat nicht nur der Kunde regelmäßig einen Überblick, wo die Produktentwicklung gerade steht und ob es Missverhältnisse gibt. Außerdem kommunizieren wir regelmäßig und viel mit unserem Kunden, um frühzeitig auf Änderungen zu reagieren. 

Lean

Wir konzentrieren uns auf die wesentlichen Dinge. Sonderlocken werden hinten angestellt und bei Bedarf gegen Ende des Projekts umgesetzt. Oder auch nicht!

Wir setzen zuerst eine MVS (Minimum Viable Solution) um und gehen dann weiter. Wenn der Kunde ein konkretes Projektziel nennen kann, macht es meines Erachtens Sinn, jede Anforderung gegen dieses Ziel zu prüfen und ihr einen Wert beizumessen. Mit dem Quotienten aus Wert und Komplexität lässt sich dann relativ einfach und sachlich priorisieren. Bei Sonderlocken ist der Wert des Quotienten von Natur aus niedrig. Lean bedeutet für uns, dass wir keine Verträge schließen. Verträge diskutieren und abschließen kostet Zeit und Geld. Habe ich schon erwähnt, dass Verträge selten funktionieren?

Welchen Vorteil hat der Kunde?

Neben den bereits beschriebenen Vorteilen, wie ständiges Controlling und frühe Kommunikation hat der Kunde vor allem einen Vorteil: Er kann jederzeit aussteigen. Somit minimiert sich sein Risiko. Wenn er für eine Leistung nicht bezahlen will, lässt er es halt. Er hat ja keinen Vertrag.

Welchen Vorteil haben wir als Agentur?

Wir haben keinen Vertrag. Es gibt keinen Point-of-no-Return in der Entwicklung. Somit verringert sich unser kaufmännisches Risiko in den Projekten. Da aber auch der Kunde jederzeit aussteigen kann, haben wir einen zusätzlichen Ansporn, unserem Kunden ein tolles Produkt zu liefern. Sollte der Kunde oder wir merken, dass die Zusammenarbeit nicht (mehr) klappt, beenden wir sie. Das ist weniger schmerzhaft, als verzweifelt das Produkt fertig zu entwickeln. Somit hat auch der Kunde ein gesteigertes Interesse daran, auf Augenhöhe mit uns zusammen zu arbeiten.

Funktioniert RE.A.L?

Das kann ich noch nicht beantworten, da wir noch kein RE.A.L-Projekt abgeschlossen haben. Die ersten Projekte laufen gerade und irgendwie fühlt sich der Ablauf wesentlich entspannter an. Der Austausch mit dem Kunden ist intensiver als früher. Ein für mich beispielhaftes Zitat eines unserer Product Owners war: „Ich suche noch den Haken in diesem Projekt.“ Worauf ein Entwickler entgegnete: „Es ist die schiere Masse an Aufgaben.“

Da hatten wir in anderen Projekten ganz andere Probleme als nur viel Arbeit vor der Nase.

P.S.: Im nächsten Teil dieser Blogreihe versuche ich einen unserer Kunden zu Wort kommen zu lassen, um über seine Erfahrungen mit RE.A.L zu berichten. Das wird aber noch etwas dauern.