Wenn ein IT-Projekt in Not gerät und gerettet werden muss, ist dies eine besondere Situation. Die Beteiligten stehen unter erheblichem Stress, alle sind angespannt. Nicht selten herrscht hektisches Chaos. Zu viele Anforderungen, zu wenig Zeit, die Komplexität nimmt ständig zu und es ist kein Ende abzusehen. Die Mitarbeiter hätten eigentlich eine Pause dringend notwendig, aber das Unternehmen braucht schnelle, vorzeigbare Ergebnisse.

Eigentlich verspricht Scrum gerade für solche komplexen Szenarien Hilfe: "Scrum ist ein Framework, mit dessen Hilfe Menschen komplexe Probleme lösen können und gleichzeitig produktiv und kreativ Produkte von höchstmöglichem Wert liefern." (Schwaber, Sutherland, 2013) Trotzdem ist gerade in einer Notsituation die Bereitschaft für einen umfassenden organisatorischen Wandel meistens nicht vorhanden. Er bringt nach Meinung der Betroffenen zu viele Risiken mit sich, und es fehlt schlicht die Zeit, sich damit auseinanderzusetzen.

Aber warum geraten Projekte in Not? Und wie kann man sich ohne den großen organisatorischen Befreiungsschlag retten? Dieser zweiteilige Beitrag schildert typische Probleme in IT-Projekten sowie deren Lösung mithilfe von Scrum-Techniken – und beschreibt vor allem, wie diese Techniken reibungslos im Projektalltag eingesetzt werden können, ohne gleich das große Agilitäts-Evangelium zu predigen.

100% Scrum einzuführen ist nicht immer möglich

Werfen wir kurz einen Blick auf das Prinzip "Shu-Ha-Ri", das aus dem japanischen Kampfsport kommt. Es beschreibt drei Stufen zur Meisterschaft. Übertragen auf Scrum bedeutet es Folgendes: am Anfang beginnt man mit Scrum aus dem Lehrbuch (Shu). Nachdem man die reine Lehre perfekt beherrscht, kann man einzelne Regeln anpassen, um damit besser und effizienter zu werden (Ha). Auf der obersten Stufe schließlich – der Ebene der Meisterschaft (Ri) – macht man sich um Regeln keine Gedanken mehr, sondern das Gelernte wird in einem natürlichen Fluss angewandt – so wie es in der jeweiligen Situation am wirkungsvollsten ist (Scrum Inc., 2012). Wer vor ein paar Jahren mit Scrum angefangen hat, lernte wahrscheinlich nach dem Shu-Ha-Ri-Prinzip, versuchte also zunächst, Scrum lehrbuchmäßig umzusetzen, bevor er einzelne Punkte auf die spezifische Projektsituation angepasst hat.

Gleichzeitig war vor einigen Jahren auf Konferenzen "Scrum-But-Bashing" ein beliebtes Thema. D.h. es wurde alles verdammt, was nicht 100% Scrum war (Scrum But: "wir machen Scrum, aber (but) ohne …"). Wer es aus irgendwelchen Gründen nicht geschafft hat, Scrum zu 100% anzuwenden und es auch noch wagte, davon zu erzählen, dem wurde öffentlich erklärt, warum das so auf keinen Fall funktionieren könne und es prinzipiell falsch und verwerflich wäre. Dieses Klima hat dazu geführt, das einige angehende Scrum Master, die frisch von Scrum-Schulungen oder Scrum-Konferenzen kamen, sich gar nicht mehr trauten, Scrum anzuwenden. Sie haben in ihrem Umfeld nicht die Möglichkeit gesehen, Scrum zu 100% umzusetzen.

In der Scrum-Community wird weiterhin viel und heftig über den richtigen Weg der Scrum-Einführung diskutiert. Mittlerweile ist das Klima weniger hart: aus "Scrum But" wurde "Scrum And" ("Ich setze Scrum ein und wir haben einen Daily Build & Test etabliert"). Es ist also heutzutage möglich, darüber zu sprechen, dass man Scrum in mehreren Stufen einführt.

Einigkeit besteht darin, dass eine Scrum-Einführung auf jeden Fall einen kulturellen Wandel mit sich bringt oder sogar voraussetzt. Ein Change-Projekt ist notwendig, entsprechendes Coaching unabdingbar. Die Unterstützung des Top-Managements ist Voraussetzung, da sich einige Hürden bei einer Scrum-Einführung nur durch die Geschäftsleitung beseitigen lassen (vgl. z.B. Zeitler, 2011).

Zusammenfassend lässt sich sagen, dass man Scrum nicht "einfach so" einführen kann, sondern nur über einen koordinierten, unternehmensweiten Change-Prozess, der vermutlich über einige Monate oder gar Jahre laufen wird (Schwaber, 2012). Dass es dennoch möglich ist, einzelne Scrum-Techniken gewinnbringend bei einer Projektrettung einzusetzen, zeigt das nachfolgende Beispiel.

Warum eigentlich keine Methodenrevolution – Beispiel: eine reale Projektsituation

Nehmen wir folgendes Szenario an: Unser zu rettendes (fiktives) IT-Projekt "HelloWorld" ist für das Unternehmen von strategischer Bedeutung. Der Unternehmenserfolg hängt wesentlich vom Gelingen dieses Projekts ab. Am Projekt sind ca. 100 Mitarbeiter sowie mehrere externe Dienstleister beteiligt. Es gibt ein – von einer unbestreitbar erfolgreichen und angesehenen Managementberatung – erarbeitetes Projektvorgehen und -organisationsmodell, das in enger Zusammenarbeit mit dem Projektauftraggeber erstellt wurde. Der Auftraggeber hat das Vorgehen und das Modell an alle Projektbeteiligten und Stakeholder kommuniziert.

Das Projektvorgehen ist phasenorientiert: Grobspezifikation, Feinspezifikation, Realisierung, Test, Pilot, Einführung. Jeder Phasenübergang wird durch ein Managementgremium überwacht. Erst nach dessen OK kann die nächste Phase begonnen werden. Die Projektorganisation ist ebenfalls phasenorientiert unterteilt. Es gibt Teilprojekte für Fachkonzeption, Realisierung, Test und Einführung.