Scrummerfall

Scrummerfall – die Verwässerung von Scrum

„Wir planen eine Woche unseren nächsten Sprint. Dann sprinten wir vier Wochen, gefolgt von zwei Wochen für die Integration der Lösung und einer weiteren Woche für das Deployment. Zur Sicherheit planen wir eine weitere Woche als Puffer ein.“

Was hat dieses Statement mit Scrum zu tun? Nichts!

Scrum ist ein flexibles Framework für komplexe Projekte und Entwicklungen. Das Herz des Frameworks ist der sogenannte Sprint. Er umfasst alle anderen Events und Tätigkeiten und dauert laut Scrum Guide maximal 4 Wochen. Wer also eine Woche vor einem Sprint und mehrere Wochen nach einem Sprint verplant, macht faktisch Folgendes: Er nimmt einen zentralen Begriff aus Scrum, arbeitet aber mit einem Vorgehen, das nichts mit dem Framework und den Inhalten des Scrum Guides zu tun hat. Oder in anderen Worten: er betreibt Scrummerfall.

Scrummerfall beschreibt die Verwässerung von Scrum mit klassischen Vorgehensweisen. [1] Häufig entsteht diese Verwässerung in Organisationen unbeabsichtigt. Während Teams innerhalb eines Sprints iterativ und inkrementell arbeiten, werden vor- und nachgelagerte, manchmal auch übergeordnete Prozesse, Steuerung und Entscheidungswege weiterhin klassisch gehandhabt. Dies führt zu Widersprüchen, da agile Prinzipien wie Selbstorganisation, schnelle Feedbackzyklen und kontinuierliche Anpassung mit phasenbasierten, stark strukturierten Vorgehensweisen kollidieren.

Der Begriff Scrummerfall kombinert Scrum und das Wasserfallmodell. Alternativ wird häufig auch von WaterScrum, WaterAgile oder WAgile gesprochen; diese synonyme Begriffsverwendungen sind jedoch widersprüchlich und sollten spätestens dann innerhalb einer Organisation thematisiert werden, wenn unsicher ist, ob alle Beteiligten dasselbe unter den Begriffen verstehen. [2]

Die Ursachen für Scrummerfall sind vielfältig: Oft liegt es an unzureichendem Verständnis agiler Prinzipien, an Organisationsstrukturen, die auf klassische Planung und Steuerung ausgerichtet sind, oder an der Herausforderung, bestehende Prozesse mit agilen Methoden zu kombinieren.

Beispiele für Scrummerfall

Scrummerfall tritt  in unterschiedlichen Formen auf. Hier finden Sie einige Beispiele:

• Gestaffelte Sprints kommen zur Anwendung, bspw. arbeiten Business-Analysten einen Sprint vor den Entwicklern, während die Qualitätssicherung einen Sprint hinterherhinkt.
• Sprints werden als Container für Tätigkeiten definiert: Im ersten Sprint geht es um die Anforderungsanalyse, im zweiten um die Projektplanung, im dritten um die Realisierung, im vierten um die Abnahme, etc.
• Sprints haben unterschiedliche Längen, da Unternehmen ihren Kunden feste Lieferzusagen gemacht haben („Sie bekommen das Produkt nach dem nächsten Sprint“) und das Konzept des Timeboxings keine Anwendung findet.
• Ein Team nutzt Praktiken wie Daily Stand-ups, Sprint-Reviews und Retrospektiven, die Teammitglieder dürfen jedoch nicht eigenverantwortlich über ihre Arbeit entscheiden. Entscheidungen zu Architektur, Anforderungen und Prioritäten werden weiterhin von einer zentralen Managementinstanz getroffen, was der agilen Idee der Selbstorganisation widerspricht.

Sicherlich lässt sich die Liste der Beispiele leicht verlängern.

Herausforderungen für Organisationen

Scrummerfall bringt für Organisationen zahlreiche Herausforderungen mit sich, die die Vorteile agiler Methoden schmälern oder sogar ins Gegenteil verkehren können.

• Durch gestaffelte oder sequenzielle Arbeitsweisen verzögert sich das Feedback auf entwickelte Features erheblich. Dies kann dazu führen, dass Probleme erst spät erkannt und korrigiert werden, wodurch sich die Entwicklungskosten erhöhen.
• Organisationen, die Scrum mit formalen Wasserfall-Prozessen kombinieren, verlieren die Anpassungsfähigkeit agiler Entwicklung. Entscheidungen sind oft frühzeitig festgelegt und Änderungen werden durch bürokratische Prozesse erschwert.
• Wenn einzelne Rollen oder Abteilungen in isolierten Sprints arbeiten, fehlt die ganzheitliche Verantwortung für das Produkt. Dies kann dazu führen, dass Missverständnisse zunehmen und die Qualität leidet.
• Ein zentraler Vorteil von Scrum ist die Selbstorganisation der Teams. In einem Scrummerfall-Szenario werden Teams jedoch oft durch externe Abhängigkeiten und strikte Prozesse limitiert, was ihre Eigenverantwortung und Motivation beeinträchtigt.

Um Scrummerfall zu vermeiden, sollten Organisationen ihre Prozesse daher kritisch hinterfragen und prüfen, ob sie agile Prinzipien wirklich unterstützen oder durch traditionelle Elemente konterkariert werden.

Hinweise:

[1] Eine bekannte Definition des Begriffs geht auf Brad Wilson, einen US-amerikanischen Softwareentwickler, zurück: „Scrummerfall is the practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.“

[2] Bei genauer Betrachtung gibt es Unterschiede zwischen Scrummerfall und bspw. WaterScrum: Scrummerfall adressiert die Situation, bei der Scrum nicht im Sinne des Scrum Guides angewandt und durch vorhandene, häufig seit vielen Jahren genutzten Praktiken und Methoden verwässert wird. WaterScrum dreht diesen Gedanken um: In einer Organisation werden klassische Methoden und Vorgehensweisen genutzt, die Organisation möchte aber agiler werden und Scrum – zumindest in Teilen – nutzen. Das Ergebnis sind hybride Modelle oder Vorgehensweisen, bei den bspw. kürzere Iterationen frühzeitigeres Feedback durch Kunden ermöglichen. Das vorhandene Wasserfall-Vorgehen wird also Schritt für Schritt „agiler“.

Hier finden Sie einen Podcast: Scrummerfall – Wenn Scrum scheitert.

Die Inhalte auf dieser Seite dürfen Sie gerne teilen oder verlinken. Und falls Sie sich für Tipps aus der Praxis interessieren, dann testen Sie unseren beliebten Newsletter mit neuen Beiträgen, Downloads, Empfehlungen und aktuellem Wissen. Vielleicht wird er auch Ihr Lieblings-Newsletter!