Buch-Rezension zu „Waltzing with Bears“

„Waltzing with Bears: Managing Risk on Software Projects“ von Tom DeMarco und Timothy Lister erschien 2003 bei Dorset House. Risikomanagement ist etwas was nicht erst in den letzten Jahren aktuell wurde. DeMarco und Lister haben ihre Erfahrungen in dieses knapp 200 Seiten umfassenden Buch einfliessen lassen. Wie meist bei DeMarco ist das Buch trotz der vielen Theorie sehr angenehm zu lesen.

Die einzelnen Teile des Buches gehen diesen Fragen rund ums Risikomanagement nach:

• Warum?
• Wann nicht?
• Wie?
• Wie viel?
• Wird’s gemacht?

Im ersten Teil wird auf anschauliche Art erklärt was Risiken sind und wieso man vor ihnen nicht weglaufen kann. Projekte die ganz ohne Risiko sind haben meist auch nur sehr wenig finanzielle Anreize, wodurch man früher oder später hinter die risikoreichen Projekte muss.

Wann auf Risikomanagement verzichten?

Teil 2 geht dann auf die Situationen ein, wo man besser auf ein Risikomanagement verzichtet. Dies mag einen erstaunen, doch gibt es solche Situationen wirklich. Es macht schlicht keinen Sinn in einer Firma die nur Ja-Sager will von Dingen wie Risiken zu sprechen. Bei Risiken spricht man von Möglichkeiten und Unsicherheiten. Ein Firmenmotto wie

It’s okay to be wrong, but not okay to be uncertain.

steht diesem Vorhaben im Weg. Eine andere Situation ist wenn Glück integraler Bestandteil des Projektplans ist. Dabei ist nicht gemeint dass man mit ein wenig Glück vielleicht ein wenig früher fertig wird. Sondern das man bei allen Schritten viel Glück braucht damit man überhaupt auch nur im Entferntesten diesen Plan umsetzen kann.

Wie managt man Risiken?

Gut die Hälfte des Buches widmet sich der Frage wie man Risiken managen kann. Als erstes Beispiel dient das Risiko des verpassten Liefertermins. Mittels Terminkurven wird die Wahrscheinlichkeit des Lieferzeitpunktes untersucht. Die eine Grenze bildet der frühestmögliche Zeitpunkt (N) unter optimalsten Bedingungen, die andere ist der Termin bei dem man sicher fertig sein wird (und damit viel weiter in der Zukunft liegt als das Projekt dauern soll).

Der Punkt N wird hier als Nano-Prozent Datum definiert. Die Chancen zu diesem Zeitpunkt zu liefern sind grösser als 0, aber immer noch verschwindend gering. Leider wird dieser Zeitpunkt aber oft als Liefertermin benutzt, was zu all den bekannten „Verzögerungen“ führt.

Wie geht man nun mit diesem Risiko um? Die Autoren schlagen vor Anzeichen für ein Eintreten zu sammeln und zu überwachen. Davon erhofft man sich bei ersten Anzeichen noch reagieren zu können. Allerdings gilt es bei grösseren Risiken Vorkehrungen zu treffen. Genau wie bei einer Versicherung muss man sich vor dem Eintreffen des Schadensereignisses darum kümmern. Dabei muss man wieder abwägen wie viel einem eine Vorkehrung für etwas das nur vielleicht eintreffen wird wert ist. Es wäre kein Buch von DeMarco wenn es dazu nicht auch zahlreiche Formeln und betriebswirtschaftliche Grundlagen gäbe.

Neben der Terminüberschreitung gibt es auch zu anderen häufigen Risiken bei Software Projekten (wie Explosion der Anforderungen oder Personalfluktuation) Beispiele die nach dem gleichen Muster angegangen werden.

Risiken minimieren

DeMarco und Lister haben auch etliche Ansätze zum Reduzieren der Risiken. Für die Lieferverzögerung ist ihr Ansatz die Software in mehreren Teilen zu liefern. Mit doch recht vielen Worten wird ein vorgehen erklärt das anhand des Nutzens für den Kunden Teile abgrenzt und zu Lieferpaketen gruppiert. Aus heutiger Sicht ist einem so ein Vorgehen aus Scrum oder XP bekannt und bräuchte weniger Erklärungsbedarf.

Kosten, Nutzen und Risikobereitschaft

Wie auch bei „Software by Numbers“ sollten für etliche Berechnungen sowohl die Kosten wie auch der Nutzen vorliegen. DeMarco und Lister sind diesbezüglich aber ein wenig realistischer:

Cost = $6,235,812.55 Benefit = „We gotta have it.“

Ein wenig mehr Erklärung wie man dann aber doch zu genügend guten Zahlen kommt hätte in dem Buch noch Platz finden sollen.

Ein weiteres schönes Zitat zur Risikobereitschaft zeigt eines der grossen Probleme bei Software Projekten:

Take lots of risks when the benefit is negligible. How else can we possible get costs down enough to justify this loser project?

Dies steht im Wiederspruch zu dem was man eigentlich erwarten würde: Viel Risiko wenn es viel zu gewinnen gibt, wenig Risiko wenn der mögliche Nutzen minimal ist. All die Death-March Projekte zeigen aber das DeMarco und Lister auch hier recht haben. Leider.

Fazit

Ich finde das Buch ist ein guter Einstieg ins Thema. Es deckt die 20% des Themas Risikomanagement ab die rund 80% des Nutzens beinhalten. Damit ist aber auch klar dass man nach dem Lesen kein Experte für Risikomanagement sein kann.

Ein wenig mehr Wissen über Risiken im Entwicklerteam würde noch so manchem Projekt gut tun. Dazu kann man dieses Buch gut nutzen.

Zum Buch

“Waltzing with Bears: Managing Risk on Software Projects” von Tom DeMarco und Timothy Lister, 2003 Dorset House