Diese Woche hatte ich das Vergnügen, das Scrum-Seminar meines Koblenzer Kollegen Ayelt Komus zu besuchen. Neben den Grundlagen von Scrum und Kanban ging es auch um den praktischen Einsatz und die Erfahrungen mit diesem Ansatz, auch im Non-IT-Bereich. Hierzu hat das BPM-Labor an der Hochschule Koblenz eine umfassende Studie durchgeführt.
Die Erfahrungen mit agilen Vorgehensweisen wie Scrum sind für Komus den klassischen Projekten meist klar überlegen. „Am Ende werden sie alle agil“, kommentiert er die typischen Großprojekte, die zum Stichtag nicht fertig werden. Häufig wird die Lösung dann anschließend häppchenweise eingeführt. Ganz so, wie es in Scrum von Vornherein vorgesehen ist. Er stellt prinzipiell in Frage, ob jede IT-Maßnahme tatsächlich in Form eines Projektes durchgeführt werden muss. Meist werden noch massenhaft Anforderungen von allen möglichen Stakeholdern auf das Projekt gepackt, wodurch der Umfang und damit auch die Zeit bis zur Fertigstellung und das Risiko eines Fehlschlags steigen. Stattdessen plädiert er in vielen Fällen für eine ständige Weiterentwicklung mit häufigen Releases. Von daher sei Scrum auch keine Projektmanagement-Methode, sondern eher ein Ansatz für die kontinuierliche Entwicklung.
Die allesamt Projekt-erfahrenen Teilnehmer diskutierten lebhaft, ob und wie sich Scrum für verschiedene Arten von Vorhaben anwenden lässt. Komus stellte eine Reihe von Praxisbeispielen vor, wo Scrum z. B. für die Produktentwicklung, das interne Prozessmanagement oder die Entwicklung von SAP-gestützten Lösungen eingesetzt wird. Häufig wurde dabei Scrum modifiziert oder mit Elementen des herkömmlichen Projektmanagements kombiniert. Auch wenn solche „Water-Scrum-Fall“-Praktiken aus Sicht der reinen Scrum-Lehre eher skeptisch betrachtet werden, hat bereits die Anwendung ausgewählter Scrum-Elemente nachweisbare Vorteile gebracht. Ob man diese Vorgehensweisen dann noch Scrum nennen sollte, ist dann eher eine zweitrangige Frage.
Weitere Infos zu dem Seminar (nächste Termine im Oktober und November)