Gelesen: Software in 30 Tagen

Mit dem Buch „Software in 30 Days“ wenden sich Ken Schwaber und Jeff Sutherland, die Väter von Scrum, explizit an die Führungskräfte und IT-Manager von Unternehmen. Sie sollen lernen, warum empirisches Arbeiten mit Scrum dem traditionellen vorhersagenden Wasserfall-Prinzip überlegen ist. Dieses Buch ist jetzt im dpunkt.verlag unter dem Titel „Software in 30 Tagen“ auf Deutsch erschienen.

Software in 30 TagenFast klassischer Einstieg

Das Buch beginnt wie fast jedes Scrum-Training mit dem CHAOS-Report der Standish Group. „Nicht schon wieder!“, denke ich, blättere um – und darf das erste von vielen Fallbeispielen lesen, mit denen die Autoren ihre Konzepte motivieren oder illustrieren. Kernaussage der Beispiele ist, dass Softwareentwicklung ein komplexer Prozess ist (was das bedeutet, wird anhand des Stacey-Diagramms erläutert), für den besondere Bedingungen gelten, die von einem empirischen Prozess gut adressiert werden. Nach einem weiteren Fallbeispiel ist das erste Kapitel zu Ende. Scrum wurde bisher zwar kurz erwähnt, aber noch nicht ausführlich erläutert. Damit werden Schwaber und Sutherland den meisten Führungskräften gerecht, die wenig Begeisterung für die Scrum-Mechanik aufbringen, aber eine schnelle Lieferung neuer Software-Inkremente und eine höhere Qualität der gelieferten Software sehr begrüßen.

Scrum durch die Empirie-Brille betrachtet

Scrum ist ein empirischer Prozess – das ist es, was die Manager im zweiten Kapitel lernen sollen. Deshalb auch hier keine Details weit und breit. Dafür eine Einführung in das Product Backlog und die iterativ-inkrementelle Entwicklung. Mit diesem Wissen kann nun analysiert werden, ob ein empirischer Prozess die Probleme des Wasserfalls lösen kann. Die Antwort ist wenig überraschend: mit Empirie wird alles besser. Allerdings ergeben sich daraus auch Konsequenzen für die Art der Zusammenarbeit: Respekt, Selbstorganisation, multifunktionales Lernen und subtile Kontrolle sind Führungsinstrumente, die zwar nicht neu sind, aber dennoch nicht flächendeckend praktiziert werden. Da mag es den einen oder anderen Manager beruhigen, dass man Scrum zunächst in notleidenden Projekten ausprobieren darf. Hauptsache, man beginnt überhaupt einmal, anstatt nur zu überlegen, ob man vielleicht mal beginnen sollte.

Mut zu Experimenten

Um den Start ins erste Scrum-Projekt zu erleichtern, beschreibt das dritte Kapitel ein beispielhaftes Pilotprojekt. Von der Auswahl des richtigen Projekts über die Zusammenstellung des geeigneten Teams bis hin zum Bauen des ersten Inkrements und der Auswertung der Ergebnisse (sowohl inhaltlich als auch prozessual) führt dieses Kapitel einmal durch den Scrum-Zyklus.

Scrum braucht eine neue Art von Führung

Wer jetzt begeistert oder zumindest interessiert ist, dem vertrauen Schwaber und Sutherland im vierten Kapitel eine unbequeme Wahrheit an: nicht nur die Art der Softwareentwicklung ändert sich, sondern auch die Anforderungen an Führung. Das beginnt mit der Erkenntnis, dass es als Erfolg zu werten ist, wenn man frühzeitig erkennt, dass die gewünschten Ziele nicht erreicht werden können. Anstatt weiter Geld zu verschwenden, wird das Projekt vorzeitig beendet. Damit nicht genug, müssen Führungskräfte lernen, auf ihre Mitarbeiter zu vertrauen und diesen ein Arbeitsumfeld zu schaffen, in dem sie selbstorganisiert zu Werke gehen können und in dem Fehlschläge analysiert, aber nicht gebrandmarkt werden.

Mich würde interessieren, wie viele Führungskräfte an diesem Punkt das Buch aus der Hand legen und nicht mehr weiterlesen…

Die Mechanik im Schnelldurchlauf

Wer weiterliest, der bekommt zu Beginn von Teil II die Scrum-Mechanik im Schnelldurchlauf präsentiert. Allen Detailverliebten sei Anhang B empfohlen. Hier ist der komplette Scrum Guide angedruckt – allerdings in der älteren Version vom Oktober 2011 (die aktuelle Version stammt aus dem Jahr 2013).

Anschließend betrachten Schwaber und Sutherland Scrum auf verschiedenen organisatorischen Ebenen: beginnend im Projekt, entwickeln sie das Konzept des Softwarestudios, das als Kompetenzzentrum das nötige Wissen und geeignete Werkzeuge und Metriken für konkrete Scrum-Projekte bereithält. Zahlen und Kurven nehmen in diesem Kapitel viel Raum ein – wohl auch, um dem weit verbreiteten Vorurteil entgegenzuwirken, dass Scrum ein chaotischer, nicht messbarer Prozess ohne Kontrollmöglichkeiten sei.

Nach ein paar Fallbeispielen erfolgreicher „agilisierter“ Unternehmen widmen sich die Autoren der Frage, wie man eine Scrum-Transition organisiert und durchführt. Hier werden Elemente des klassischen Change Management mit dem agilen Vorgehen nach Scrum kombiniert. Ein geschickter Schachzug, denn so wird einerseits die Anschlussfähigkeit zur klassischen Managementlehre sichergestellt, andererseits aber auch der Transfer in die agile Welt geleistet. „Scrum ist ein Prozess, um komplexe Arbeit zu managen. Nichts ist komplexer als Unternehmensumgestaltungen.“ Ein starkes Argument.

Anhänglich

Die Anhänge nehmen rund 30 Prozent des 189 Seiten starken Buches ein. Neben einem Glossar und dem bereits erwähnten Scrum Guide findet der Leser hier den Abdruck des bisher unveröffentlichten Dokuments „A Playbook for Achieving Enterprise Agility“, das Ken Schwaber im Jahr 2005 gemeinsam mit der Rally Corporation geschrieben hat.

Fazit

Ich werde dieses Buch veränderungsbereiten Managern weiterempfehlen, weil es die Vorteile von Scrum erläutert, ohne Scrum im Detail zu behandeln. Stattdessen werden die Vorteile und die Konsequenzen des empirischen Vorgehens in einer managementtauglichen Sprache und Argumentation beschrieben und mit vielen Fallbeispielen belegt. An einigen Stellen lehnen sich Schwaber und Sutherland für meinen Geschmack zu weit aus dem Fenster. Aussagen wie „Wir machen uns nicht länger Sorgen, dass wir um mehr Budget bitten müssen“ können missverstanden werden. Plötzlich steht Scrum dann wieder als das Allheilmittel da, das es weder ist noch sein möchte. Auch das ist in diesem Buch eindeutig benannt („Für das Unternehmen ist Scrum der ‚Kanarienvogel in der Kohlemine‘“), klingt aber natürlich weniger euphorisch. Euphorie ist aus meiner Sicht nicht Ziel dieses Buchs, sondern vielmehr Aufklärung, um mit Vorurteilen und ungesundem Halbwissen aufzuräumen. Das dürfte diesem Buch gut gelingen. Etwas mehr Sorgfalt hätte ich mich bei der Übersetzung gewünscht. Der Satzbau und so manches Wort ist zu nah am amerikanischen Original, und das Korrektorat scheint unter Zeitdruck gewesen zu sein. Die handwerkliche Präzision, die wir von Scrum-Projekten erwarten, finden wir dann hoffentlich in der zweiten Auflage dieses Buchs.

Ken Schwaber, Jeff Sutherland
Software in 30 Tagen
Wie Manager mit Scrum Wettbewerbsvorteile für ihr Unternehmen schaffen
Aus dem Amerikanischen von Stefan Roock
dpunkt.verlag, Dezember 2013
ISBN 978-3-86490-074-7