IT-Projekte mit Scrum-Techniken retten

Teil 1: Die Taktik der kleinen, schnellen Schritte
Um in Not geratene IT-Projekte zu retten, wählt Frederik Dahlke einen ungewöhnlichen Ansatz: Er bedient sich verschiedener Scrum-Elemente und setzt diese punktuell ein, um typische Probleme in IT-Projekten zu lösen. Auf diese Weise lassen sich viele Krisensituationen entschärfen – selbst dann, wenn agile Methoden bisher in der Organisation nicht zum Einsatz kamen. In diesem zweiteiligen Beitrag schildert er anhand eines Beispielszenarios, wie die Projektrettung mit Scrum-Techniken gelingen kann.

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

Anzeige
Der vollständige Artikel ist für Abonnenten frei zugänglich.
Artikel kaufen (4,50 €)
  • 8 Seiten Praxiswissen
  • PDF-Download
Kostenlos weiterlesen!
  • Diesen Beitrag kostenlos lesen
  • 4 Wochen Online-Zugriff auf alle Artikel, Methoden und das Glossar
Tech Link