Scrum für Wasserfall-Romantiker
Wer aus klassischen Projekten kommt, schaut manchmal voller Bedenken auf agile Projekte. Sie sehen planlos aus und riechen nach Aktionismus.
Gute Projekte haben einen Plan und erreichen ein Ziel. Das trifft auch auf agile Projekte zu. Die konsequente Priorisierung qualifizierter Anforderungen bildet in beiden Fällen die Grundlage. Die Welten liegen dichter beieinander als man erstmal denkt.
Ist es für Dich auch beeindruckend auf einen großen Projektplan zu schauen und Du suchst dann, wie auf einer Landkarte, wo wir sind? Oder wo wir sein könnten?
Es ist schön, viel Wissen für so einen Plan zusammen zu tragen. Das gibt Dir ein gutes Gefühl. Verunsichert Dich dagegen das Gerede über agiles Arbeiten? Macht es Dir vielleicht Angst, weil Du nicht weißt, ob es noch Platz für Dich oder ordentliche Projekte gibt?
Hier bist Du zu Hause
Der erste große Brocken, den ein klassisches Projekt liefert, ist das Ergebnis einer umfassenden und detaillierten Anforderungsanalyse: das Lastenheft.
Da steht alles drin, was gebraucht wird. In vielen Workshops wurde hervorragende Arbeit geleistet, um aus der Aussage „Wir wollen das was wir jetzt haben, nur modern“ eine verlässliche Referenz zu formulieren, an der am Ende die Ergebnisse gemessen werden. Es ist die Bibel des Projekts. Dank des Lastenhefts weiß man auch, was man am Ende bekommt.
Es dauert meist zwischen drei und sechs Monaten, bis das Werk fertig ist, ein immenser Aufwand und ein respektabler Stoß Papier.
Die Reihenfolge aller Arbeiten findet sich im Projektplan. Ebenfalls detailliert mit Abhängigkeiten und Zuständigkeiten, jeweils beziffert mit zeitlichen Aufwänden.
Sobald ein Team gefunden ist, das das Vorhaben umsetzt, geht’s los. Wie die Anforderungen umgesetzt werden, wird in einem Pflichtenheft festgelegt. Dann wird nach dem Plan gearbeitet und immer darauf geachtet, dass er eingehalten wird. Dafür gibt es ein Reporting nach oben. Denn nur ein Projekt, das nach Plan läuft, bleibt im Budget und erreicht das Ziel in der geplanten Zeit. So ein Projekt ist erfolgreich.
Das Team arbeitet alle Aufgaben des Plans ab. In der vorgedachten Reihenfolge, so dass man merkt, wann etwas aus dem Ruder läuft.
Oft dauert diese Phase zwischen zwölf und 24 Monaten und endet mit dem Go-Live. Das ist der magische Moment, in dem der Auftraggeber das erste Mal das fertige Ergebnis sieht.
Die umgesetzten Anforderungen sind zu diesem Zeitpunkt wenigstens 15 Monate, oft sogar schon mehrere Jahre alt.
Alle Wünsche oder Korrekturen, die sich im Projektverlauf ergeben, werden als Change Request erst nach dem Go-Live umgesetzt und extra abgerechnet. Sonst kann nicht für den Erfolg des Projekts garantiert werden.
Das ist eine saubere Herangehensweise, die sich auf die Weisheit derer verlässt, die das Projekt geplant haben. Und es funktioniert. Solange sich weniger als vier Prozent der Anforderungen ändern oder man nicht mit echten Menschen arbeitet.
Ernüchterung tritt ein
Oft stellen Auftraggeber erst beim Go-Live fest, dass sie sich ein anderes Ergebnis vorgestellt haben, als sie das Lastenheft beschrieben hat.
Oft steigt der Druck zum Ende des Projekts und die Arbeitswochen werden länger, weil das Team es sonst nicht schafft, den Plan einzuhalten und die Projektampel „nach oben gegrünt“ ist.
Oft ist zum Go-Live die Liste der Change Requests schon sehr lang und teuer und das Ergebnis erst dann ansprechend, wenn die meisten davon umgesetzt sind.
In echt ist das also nicht mehr ganz so rosig. Vergessen wir bitte trotzdem nichts von dem was wir als Projekt-Manager gelernt haben! Schauen wir nur kurz von den Zahlen auf und schalten den Verstand ein.
Geht es besser?
Wie wäre es, wenn wir die Zeit zwischen Anforderung und Ergebnis von Jahren auf Wochen oder Tage verkürzten? Könnte man nur überschaubare Zeitabschnitte planen und controllen, um realistischer zu sein? Könnten wir auf Change Requests verzichten und Änderungen direkt umsetzen? Könnten wir darauf verzichten, Leute zu kontrollieren und sie ungestört arbeiten lassen?
Ja, das können wir. Das ist Scrum.
Scrum ist keine neue Erfindung. Es ist keine neue Welt. Es ist nicht die Lösung aller Probleme und gibt nicht auf alles Antwort. Vieles, was wir gelernt haben, funktioniert noch. Wir backen mit Scrum nur kleinere Brötchen, dann läuft auch die Backstube und die Gourmets bekommen, was ihnen wirklich schmeckt.
Gut gereift
Scrum ist kein “alter Wein in neuen Schläuchen”. Scrum ist die Essenz der letzten 50 Jahre Untersuchung zum Thema „Was machen sehr erfolgreiche Teams anders als die anderen“.
Der kleinste gemeinsame Nenner ist im Scrum Guide formuliert. Scrum gibt der Wolke „agil“ eine klare Struktur. Deshalb können klassische Projekt-Manager es leicht lieb gewinnen.
Scrum erfordert Disziplin. Weicht man vom Vorgehen im Scrum Guide ab, kostet es Erfolg.
Scrum definiert Rahmenbedingungen in Form von Rollen, Regeln und Events. Es ermöglicht das Reagieren auf Veränderung. Die Arbeit muss man immer noch selbst erledigen.
Du kriegst was du brauchst
Eine weit verbreitetes Vorurteil klassischer Projekt-Manager lautet: “Bei Scrum weiß man nicht, was man bekommt!” Doch. Man bekommt das, was tatsächlich dem Bedarf entspricht.
Bei Wasserfall-Projekten hat man lediglich den Eindruck zu wissen, was man bekommt. Ob man überhaupt etwas bekommt, weiß man erst am Tag des Go-Lives. Und Vertragsstrafen lösen dann auch kein Problem mehr.
Mit Scrum bekommt man regelmäßig und in kurzen Abständen Ergebnisse serviert und kann direkt Einfluss auf den weiteren Verlauf nehmen.
Geht’s schneller oder dauert’s länger?
Scrum-Projekte können kürzer sein, müssen sie aber nicht. Man kann einfach aufhören, wenn das Ergebnis gut genug ist.
Scrum-Projekte haben eine flachere Stress-Kurve, weil es keine Meilensteine oder Go-Live-Termine gibt. Es gibt aber auch keine entspannte Anfangsphase, in der man sich erstmal gemütlich einrichtet.
Scrum-Projekte beginnen mit einem Kick-Start und haben durch die Sprints eine etwa gleichbleibende Belastungskurve. Urlaubssperre, Wochenendarbeit oder angeordnete Überstunden kenne ich aus Scrum-Projekten nicht.
Du trägst Verantwortung — wie jeder im Team.
Scrum-Projekte haben keinen Projekt-Manager. Keine Sorge, Du wirst nicht arbeitslos. Du musst Dich nur entscheiden: Übernimmst Du die Verantwortung für klare und priorisierte Anforderungen, so dass das Team in kurzer Zeit das Bestmögliche bauen kann? Dann wärst Du Product Owner. Oder unterstützt Du alle Beteiligten dabei, Ihre Aufgaben zu erledigen und jeden Tag besser zu werden? Dann wärst Du Scrum Master.
Der Spieß dreht sich um: Das Team ist nicht mehr für Dich da und sichert Deinen Erfolg. Mit Scrum bist Du für das Team da.
Das klingt vielleicht nach Anarchie. Es bedeutet, dass Du Dich nicht auf den Plan verlässt.
Verlass Dich auf Menschen
Die Sache mit dem Vertrauen, dass jeder im Team seine Arbeit erledigen will, ist sicherlich die größte Hürde, die Du nehmen musst.
Stell Dir vor, Du müsstest Deine Zeit nicht damit verbringen, Menschen zu kontrollieren und anzutreiben. Du könntest Dich stattdessen darum kümmern, dass das Ergebnis gut ist.
Und das wolltest Du doch von Anfang an.
Siehst Du, wir sind gar nicht so unterschiedlich.
Wie Du ein Projekt mit Scrum anfängst, indem du zunächst Dein Ziel genau definierst, erfährst Du im Artikel Projektstart mit Scrum: Am Anfang steht das Ziel.
