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.

Scrum für Wasserfall-Romantiker

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?

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.

undefined

Es dauert meist zwischen drei und sechs Monate, 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 Monate 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.

Zum Ende des Projekts steigt der Druck und die Arbeitswochen werden länger, weil das Team es sonst nicht schafft, den Plan einzuhalten und die Projektampel „nach oben gegrünt“ ist.

undefined

Zum Go-Live die Liste der Change Requests meist schon sehr lang 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.

undefined

Du kriegst was du brauchst

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.

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 sicher die größte Hürde, die Du nehmen musst.

Stell Dir vor, Du verbringst Deine Zeit nicht damit, Menschen zu kontrollieren und anzutreiben. Du könntest Dich stattdessen um ein gutes Ergebnis kümmern.

Und das wolltest Du doch von Anfang an.

Siehst Du, wir sind gar nicht so unterschiedlich.

Sie haben Fragen? Wir sind für Sie da!

Sie haben Fragen? Wir sind für Sie da!

Kai Dahlke
+49 30 28443399
presse@bitgrip.de