Scrum auf den Hund gekommen – Von der agilen Schätzung bis zum agilen Vertrag

Als wahres Energiebündel zeigte sich Adriana Ardelean am 13.7. beim Treffen der .NET Usergroup in Friedrichshafen. Die Projektmanagerin von activeDevelop in Lippstadt teilte hier ihre langjährige Erfahrung in der Planung und Umsetzung von agilen Softwareprojekten nach Scrum. Unter dem Titel „Die agile Unsicherheitsversicherung“ verpackte sie teils skurrile, aber wirkungsvolle Ideen zum Schätzen in agilen Projekten und den Weg zu einem fairen agilen Vertrag.

Kauf Dir Deine Features

Eine wesentliche Voraussetzung für den Aufbau eines Product Backlog in Scrum ist die Priorisierung der Features oder Epics durch den Kunden. Aber wie bekomme ich den Kunden dazu, den Business Value eines Features zu bestimmen? Die klassische Bewertung mit Hilfe von Fibonacci Zahlen ist dem Kunden meist zu abstrakt. Die Lösung ist ganz einfach. „Gib dem Kunden einen begrenzten Geldbetrag und klebe an die Features Preisschilder.“ In der Diskussion um die beste Anlagemöglichkeit kristallisieren sich schnell die richtigen Prioritäten heraus. Am Beispiel einer Foto-App diskutieren wir die Benutzerverwaltung weg und konzentrieren uns auf das Teilen in sozialen Netzwerken.

Wer kennt die Größenordnung einzelner Features besser, als der Kunde? Der Entwickler. Aber solange die Inhalte der Features noch nicht genau bekannt sind, vermittelt die Diskussion mit dem Kunden wertvolle Erkenntnisse darüber, was er sich vorstellt. Mit den in gängigen Schätzverfahren wie Magic Estimation oder Poker Estimation verwendeten Fibonacci Zahlen sind die Kunden nach unserer Erfahrung aber oft überfordert. Adriana hat auch hier eine spielerische Idee. „Gib dem Kunden eine Skala, die leicht verständlich und vorstellbar ist.“ Wir suchen im Workshop Hunderassen aus. Eine immer doppelt so groß wie die andere. Ein Terrier Feature wurde bestimmt und mit jedem nächsten nur noch gefragt. „Größer oder kleiner? Chihuahua oder Schäferhund?“

Nachdem der Kunde seine Sichtweise auf das Projekt eingebracht hat, sind nun Product Owner und Entwickler dran, die Features in User Stories zu zerlegen und mit Story Points zu bewerten. Adriana empfiehlt den Weg über die Schätzung von T-Shirt Größen.

Den Terrier „Benutzerverwaltung“ haben wir im Workshop erst in User Stories zerlegt und uns für diese dann über Komplexität, Risiko und Aufwand Gedanken gemacht. Für diesen ersten Terrier ging das mit der geballten Entwicklungserfahrung in der Gruppe recht schnell. Die T-Shirts bekommen nun Story Points anhand einer Fibonacci-Skala. Der Terrier ist nun mit einer Summe von Story Points bewertet. Und jetzt wird’s simpel. Jeder andere Terrier bekommt die gleiche Punktzahl, wie die Benutzerverwaltung. Jeder Chihuahua bekommt die Hälfte, jeder Schäferhund das Doppelte und jeder Löwenhund wieder das Doppelte. Die Schätzung für die gesamte Beispiel-App lag im Workshop schnell vor. „Diese Schätzung ist nicht schlechter, als eine bottom up Schätzung auf ungenauen Grundlagen. In der Nachbetrachtung hat sie meistens gestimmt.“, weiß Adriana.

Story Points vs. Aufwandstage

Story Points sind schön und gut. Der Vertrieb fragt sich nun natürlich: „Wo bleiben die Personentage und das Preisschild für mein Angebot?“ Das können wir nur liefern, wenn wir das Team, das schätzt und gleichzeitig entwickelt, ganz genau kennen. Was der Spaß dann für den Kunden kostet, bekommen wir aber erst raus, wenn das Team 3-4 Sprints hinter sich hat und klar ist, wie viele Story Points es in einem Sprint schafft. Auf Basis der Team Velocity kann man dann den Angebotswert hochrechnen. Nach unserer Erfahrung liegt hier der kritischste Punkt bei der Vereinbarung einer agilen Projektvorgehensweise. Denn meist wird der Mehrwert einer Initialphase vom Kunden nicht gesehen und es bleibt Unsicherheit zurück.

Der richtige Vertrag mit dem Kunden macht am Ende den Unterschied zwischen Qual oder Spaß im Projekt. Adriana hat eine klare Meinung: „Lasst euch niemals auf einen Festpreis ein.“ Ihr Vorschlag für den agilen Vertrag setzt konsequent auf die Instrumente von Scrum und eine Win-Win-Situation für beide Vertragspartner.

Adriana erklärt uns ihren Ansatz für einen agilen Vertrag:

• Indikativer Festpreisrahmen auf Basis einer groben Schätzung

• Checkpointphase mit Ausstiegsmöglichkeit für beide Parteien. In dieser Phase wird die Velocity des Teams gemessen.

• Neuvereinbarung nach dem Checkpoint. Vereinbart werden auf Basis der bisherigen Velocity Umfang, Termin und Aufwände

• Riskshare für beide Parteien und beide Phasen.

• Weitere Ausstiegspunkte. In Scrum wird zu jedem Sprintende auslieferfähige Software geliefert. Ein Ausstieg passiert also immer mit einem verwendbaren Zwischenergebnis.

Was bei Adriana einfach klingt läuft in der Praxis nicht immer straight forward. Oft fehlt den Vertragspartnern schlichtweg die Erfahrung mit dem agilen Vorgehen. Aber auch in einem festpreisigen Rahmen lassen sich agile Elemente einbauen, erfahren wir immer wieder in unseren Projekten. Voraussetzung dafür ist eine Vertrauensbasis zwischen den Vertragspartnern und eine gemeinsame Verpflichtung auf das übergeordnete Projektziel.

Fazit:

Jedes Softwareprojekt ist zu Beginn mit Unsicherheiten behaftet, die im Projektverlauf zum Risiko werden können, oder auflösen. Ein fairer agiler Vertrag wie von Adriana vorgestellt ist sehr gut geeignet, diese Unsicherheiten zu managen und Chancen wie Risiken zu teilen.

Nicht selten fordern Unternehmen allerdings eine sehr frühzeitige Festschreibung von Projektumfang und Preis. Es wird versucht, alle Unsicherheiten über Paragraphen abzusichern. Dabei können erst während der Produktentstehung die Anforderungen und Aufwände genauer spezifiziert werden. Eine agile Zusammenarbeit im Festpreisrahmen scheint ein Widerspruch. Tatsächlich ist sie ein Kunststück, das mit gegenseitigem Vertrauen durchaus gelingen kann.