Bereits seit Jahren gelten agile Methoden wie Scrum als der de-facto Standard in der Softwareentwicklung. Der Grund dafür ist die komplexe Natur der Softwareentwicklung. Die Welt der digitalen Produktentwicklung ist so schnelllebig geworden, dass wir während eines Entwicklungsvorhaben ständig mit unvorhergesehenen Änderungen auf sämtlichen Ebenen konfrontiert sind - ein Umstand, der im Wasserfall nicht ordentlich abgebildet ist.   

Dennoch scheint es manchmal, als wolle der Wasserfall das Feld nicht räumen. In den folgenden Punkten ziehen wir Scrum als Vertreter agiler Methoden heran. Wie eine Studie von digital.ai zeigt, ist Scrum nach wie vor der beliebteste agile Ansatz. 66% der Befragten gaben an, dass Scrum das am häufigsten verwendete Framework ist. Daher betrachten wir Beispiele aus der Praxis, bei denen sich der Wasserfall in Scrum eingeschlichen hat. Also: Don’t go chasing Waterfalls. 🎵

Der Mini-Wasserfall

Gleich vorweg: Sollten Sie vom lupenreinen Wasserfall gerade versuchen, auf Scrum umzusteigen, ist dies definitiv ein Schritt in die richtige Richtung. Dieser vermutlich am häufigsten auftretende Antipattern wird typischerweise so umgesetzt, dass die Wasserfall Phasen nun auf zwei Wochen komprimiert immer wieder von vorne begonnen werden. „Gut“ dabei ist, dass man nun versucht, zum Ende eines Sprints funktionierende Software herzustellen - allerdings nur zum Ende und nicht inkrementell innerhalb des Sprints. Häufigstes Symptom: Massiver Stress zum Sprintende, da man mit dem Testen nicht mehr nachkommt. Selten wird hier ein Inkrement nach Definition of Done fertiggestellt.

Sollten Sie tatsächlich in Mini-Wasserfällen arbeiten, seien Ihnen Work in Progress Limits für die im Sprint Planning geplanten und dann umgesetzten Backlog Items nahegelegt. 

Der Wasser-Scrum-Fall

Hier ist es streng genommen so, dass Scrum in den bestehenden Wasserfall eingebaut wird. Es bleibt also bei den ursprünglichen Wasserfall Phasen, diese werden aber nun in zweiwöchige Einheiten aufgeteilt. Auf eine Handvoll Analyse-Sprints folgen die Design Sprints, danach die Coding Sprints und zum Ende Testing- und Integrations-Sprints. Sicherlich eine Bereicherung für den Wasserfall, da dies womöglich das Projektcontrolling erleichtert, aber im Kern wird hier immer noch klassisch gearbeitet und die Komplexität der Softwareentwicklung in keinster Weise abgebildet. 

Das Rollen-getrennte Scrum

Um mit Scrum erfolgreich zu werden, muss ein ideales Entwicklungsteam in Scrum cross-functional sein. Ist dies aus historischen Gründen nicht der Fall, und die Teamorganisation ist nach technischen Komponenten der Software eingeteilt, erhält man viele angebliche Scrum Teams, die aber für sich selbst nicht imstande sind, ein Produkt Feature vollständig umzusetzen. Dies sorgt für enorm erhöhten Projektmanagement- und Integrationsaufwand. Ein typisches Symptom dieses Antipatterns ist, dass die Projektmanager - Rolle immer noch benötigt wird, nämlich um die Komponententeams zu koordinieren. 

‍

Die „Durchklicker“

Normalerweise reicht es aus, nur über Scrum im eigenen Unternehmen nachzudenken, damit klar wird, dass es höchste Zeit wird, seine Tests zu automatisieren. Obwohl Testautomatisierung, sogar in hochkomplexen Umgebungen, heutzutage nur selten ein Problem darstellt, findet man immer noch Organisationen, die sich dem manuellen Testen von Features verschrieben haben. 

Da das Testergebnis eines manuellen Tests aber ab der ersten Codezeile, die nach Testausführung geschrieben wird, ungültig ist, müssen diese Tests immer und immer wieder ausgeführt werden. Und zwar für alle Features, die bisher entwickelt wurden (Stichwort: Regressionstests). Ohne Testautomatisierung werden die Tester schon bald länger als den ganzen Sprint brauchen, um überhaupt das Bestehende zu testen. Die Lösung dafür ist eindeutig Testautomatisierung, glücklicherweise gibt es ausreichend Werkzeuge im Bereich Code Review um diese umzusetzen. Die Symptombekämpfung wäre wiederum „back to waterfall, also die Tests nach hinten zu schieben - mit all den damit verbundenen Konsequenzen.

„Wer später integriert ist länger schnell“

Continuous Integration beschreibt die laufende (und zwar mehrmals tägliche!) Integration des entwickelten Codes zu einem großen Ganzen - im Scrum Terminus zum Inkrement. Vollautomatisiert, inklusive Ausführung aller Tests, entsteht ein Feedbacksystem, das mehrmals täglich Auskunft über den Zustand des Inkrements gibt. Und bei Fehlern den Entwicklern rasch auf die Finger klopft - und zwar so rasch, dass die Entwickler noch bestens wissen, wo denn die Fehlerquelle liegt, die es auszumerzen gilt. 

Bequemer kann es sich leider manchmal anfühlen, sich beim Entwickeln in einen Zustand der Isolation zu begeben, nämlich auf seinen eigenen „Branch“. So valide manche Branching-Konzepte auch sind, so steigt der spätere Integrationsaufwand mit der Lebensdauer eines Branches, man schiebt also den Integrationsaufwand nach hinten, möglicherweise bis zum Ende des Sprints - wo dann das böse Erwachen kommt, da die Integration plötzlich zahlreiche bisher nicht bekannte Fehler bringt, die Zeit zur Behebung dieser aber eigentlich nicht mehr vorhanden ist. 

Scrum mit Change Requests

Diese Variante ist meisten gepaart mit einem initialen Lasten- und Pflichtenheft. Man beginnt also mit Wasserfall, möchte aber dann, wenn die Umsetzung losgehen soll, doch auf Scrum umschwenken. Wenn diese Dokumente jedoch vertraglich festgelegt sind, nimmt man seiner Scrum Implementierung jegliche Möglichkeit zur Agilität von Anfang an weg, da man nicht  mehr auf sich ändernde Anforderungen bzw. neue Erkenntnisse eingehen kann -- schließlich muss man ja den Plan exekutieren. Für Änderungen bräuchte man nun ein vertraglich festgelegtes Change Requests Verfahren, und schon winkt der Wasserfall. 

Fixed Scrum

„Bis zu diesem Datum muss diese Funktionalität zu diesem Preis umgesetzt werden. Innerhalb dieses Rahmens könnt ihr so agil arbeiten wie ihr wollt.“ Wie agil kann man sein, wenn diese drei Faktoren fixiert sind? Hier bleibt so gut wie kein Spielraum, die Enttäuschungen nach wenigen Sprints werden gleichermaßen hoch sein, da keiner der Vorteile eines agilen Vorgehens in der Softwareentwicklung oder Software Modernisierung hier realisiert werden. 

In diesem Fall empfehlen wir, ein festes Budget für Ihre Investition in das Produkt zu definieren und den Product Owner damit zu beauftragen, mit diesem Budget möglichst viel Business Value zu erzeugen. Damit wird’s nicht unnötig teuer und mit cleverer Priorisierung im Backlog lassen sich unnötige Features leicht wegrationalisieren.

‍

Worauf Sie bei der Evaluierung Ihres Software­entwicklungs-Partner achten sollten? Die 10 wichtigsten Punkte für Ihre Entscheidung finden Sie hier!