Effektivität ist die neue Effizienz
Für alle Scrum Fans die schlechte Nachricht zuerst: Scrum ist nur ein Kompromiss. Die gute Nachricht, dies ist die einzige schlechte Nachricht.
Allerdings eine mit weitreichenden Folgen. Zum Beispiel die, dass viele Entwickler alles, was sie über Softwareentwicklung zu wissen glaubten über Bord werfen müssen und das Handwerk quasi neu lernen müssen.
Der Grund dafür liegt im Wesen dieses Kompromisses begründet und sollte sehr ernst genommen werden. In der Praxis wird er selten ernst genommen, weil oft nicht wirklich verstanden und das führt in vielen Scrum Projekten zu herben Enttäuschungen.
Es ist Ziel dieses Posts, Ihnen diese Enttäuschung zu ersparen. Die Zauberformel dafür heißt Effektivität statt Effizienz (Scrum vs. Wasserfall). Alle, denen der Unterschied zwischen Effektivität und Effizienz nicht mehr ganz geläufig ist, frischen hier ihre Erinnerung kurz auf.
Scrum vs. Wasserfall – Was ist der Unterschied?
Effizientes Vorgehen mit Wasserfall
Im – sagen wir mal – klassischen Entwicklungsprozess versuchen wir uns eine perfekte Welt zu schaffen, indem wir erst eine Grob- und dann eine Feinspezifikation erstellen, diese durch diverse Review-Prozesse und Approvals schicken, dann ein Architektur-Modell entwerfen, etc.
Kurz, der Projektgegenstand wird transparent gemacht, und damit sehr planbar. Das kostet zwar Zeit und Geld, aber es ermöglicht uns, sehr effizient vorzugehen.
Effizientes Vorgehen bedeutet, ein optimales Verhältnis aus Input und Output herzustellen, welches voraussetzt, dass ich genau weiß, was ich tun muss und mein Tun genau planen kann.
In der Regel führt dies zu einer sehr optimierten horizontalen, also Layer-orientierten Entwicklung (z.B. Datenmodell, Daten-Zugriffs Layer, Business Logik Layer, GUI Layer).
Was aber wenn Sie nicht die Zeit oder das Geld haben, diesen mitunter langwierigen Prozess der Spezifikation zu durchlaufen?
Eine perfekte Welt schafft man nun nicht eben mal so im Vorbeigehen. Oder Ihnen fehlen die Ressourcen oder das Wissen darum, wie man eine solche perfekte Welt beschreibt.
Vielleicht wissen Sie aber auch schon, dass sich die Anforderungen im Verlauf des Projektes ändern können, weil sie auf Marktsituationen reagieren können müssen.
Und schlimmer noch: Im 21. Jahrhundert ist Software wesentlich komplexer geworden. Sie ist außerdem oft viel vernetzter und Time-to-Market Anforderungen sind heute auch deutlich höher und oft wirken alle drei Faktoren gleichzeitig.
Kurz, wir brauchen mehr Funktionalität (und damit Komplexität) in kürzerer Zeit. Und die Spirale dreht sich steil nach oben. Ein Teufelskreis. Denn eigentlich sind diese Faktoren die Gründe warum man gerade eine perfekte Welt schaffen sollte, in der man dann sehr effizient vorgehen kann.
Projektleiter stehen vor einem Dilemma und ein Kompromiss muss her: SCRUM
Effektivität als Kompromiss in Scrum
Scrum ist ein Kompromiss, den wir eingehen, wenn wir keine perfekte Welt vorliegen haben, aber dennoch ein Projekt erfolgreich durchführen wollen.
Da wir aber ohne diese perfekte Welt aus Feinspezifikationen, Architekturmodellen, etc. nicht effizient sein können verschiebt Scrum den Fokus von der Effizienz in Richtung Effektivität. Das heißt:
Die Erreichung eines angestrebten Ziels ist wichtiger als die Herstellung eines perfekten Verhältnisses zwischen Input und Output.
Dieser Kompromiss hat seinen Preis. Denn dieser Kompromiss, die Fokussierung auf die Effektivität statt Effizienz, bringt einen Paradigmenwechsel mit sich: weg von der Effizienz der horizontalen – also Layer-orientierten – Entwicklung und hin zur Effektivität der vertikalen – also Feature-orientierten – Entwicklung.
Und diesen Preis bezahlen zuerst die Entwickler, die nicht nur weite Teile ihres Handwerks neu lernen müssen, auch die Anforderungen an Entwickler steigen enorm.
Ein Umstand übrigens, den Projektleiter bei der Zusammenstellung ihrer Teams oft komplett übersehen. Entwickler müssen nun die Vision des gesamten Projektes mindestens grob kennen, sie müssen ein Feature end-to-end denken, sie müssen in der Lage sein, es durch alle Schichten hindurch zu entwickeln und dabei gleichzeitig die Architektur künftiger Features im Blick behalten, damit später nicht zu viel refactored werden muss.
Untrainierte Teams stoßen da oft schnell an ihre Grenzen und es braucht ein paar Sprints um Teams an diese Herausforderung heranzuführen.
Nicht wenigen Managern und Projektleitern fehlt aber eben dafür die Geduld. Das Mittel der Wahl heißt hier intensives Prototyping.
Zum Schluss möchte ich noch mit einem weit verbreiteten Missverständnis aufräumen
Oft wird verbreitet, dass Scrum wesentlich flexibler ist, dass in Scrum mehr „getalked“ wird (ich gebrauche hier ganz bewusst diesen etwas schrägen denglischen Begriff) und weniger dokumentiert, dass wir flache Hierarchien haben, bzw. gar keine.
D.h. die Erreichung eines angestrebten Ziels ist wichtiger als die Herstellung eines perfekten Verhältnisses zwischen Input und Output.
Mag alles sein. Fatal ist nur, dass oft dadurch der Eindruck eines gewissen „laissez faire“ entsteht, der in Scrum Projekten gepflegt werden kann. Das ist ganz falsch!
Scrum erfordert ein Höchstmaß an Disziplin.
Als Kompromiss in einer nicht perfekten Welt ist Scrum ohnehin schon schwer belastet und damit ein fragiles Gebilde. Noch mehr Kompromisse beim Umgang mit Scrum verträgt diese Methodik nicht, der Vorrat an Kompromissen wurde bereits beim Setup aufgebraucht. Der Rest muss jetzt wesentlich stringenter und präziser, vor allem aber disziplinierter ablaufen.
