Warum Scrum-Einführungen scheitern

CIO.de: Wenn ein CIO den ersten Schritt machen will, wie fädelt er das am besten ein?

Schwaber: Eins vorab: Wenn er mit allen Arbeitsabläufen zufrieden ist, sollte er nicht auf Scrum umsteigen. Wer agile Prinzipien einführen will, sollte mit Pilotprojekten beginnen - auf keinen Fall den Test gleich über die ganze Firma ausdehnen. Man kann sein Team aufteilen in eine Gruppe, die ProjekteProjekte nach agilen Methoden umsetzt und eine, die weiter arbeitet wie bisher. Grundbedingung ist, dass die Mitarbeiter bereit dafür sind. Will die Mannschaft partout nicht überzeugt werden, kriegt man es nicht hin. Alles zu Projekte auf CIO.de

IT-Chef muss Rahmenbedingungen für Scrum schaffen

CIO.de: Wie verändert Scrum die Rolle des CIO?

Schwaber: Einerseits erhöhen agile Methoden sehr stark die Transparenz. Außerdem verändert sich die Verantwortung des CIO. Wird mit Scrum gearbeitet, ist er eher für Rahmenbedingungen und Strukturen verantwortlich. Die Verantwortung für die Produkte, die herauskommen, geht stärker auf den Kunden über.

CIO.de: Scrum hat ja nicht nur Freunde. In Internetforen liest man zum Beispiel Klagen, Scrum sei eine Art Akkordarbeit. Einer schreibt, es sei "eine Methode, die Entwickler am Laufen zu halten". Was sagen Sie dazu?

Schwaber: Schauen Sie sich mal die Arbeitsweise nach dem klassischen Wasserfall-Modell an: Die Leute bekommen gesagt, was sie tun sollen. Dann arbeiten sie, gehen nach Hause und vergessen die zurückliegende Arbeit schnell. Scrum bindet den einzelnen ganz anders ein: Man hat eine Vereinbarung mit dem Kunden, erledigt in jedem Sprint kleine Dinge - und man erinnert sich, was man erarbeitet hat. Sicher, alle Kritiker wird man nie überzeugen. Ich würde sagen, im Durchschnitt ist immer etwa ein Fünftel der Leute gegen Arbeitsweisen wie bei Scrum.