Scrum vs. Wasserfall: Auch Agilität braucht Planung

Nach wie vor passiert es, dass wir im Projektalltag den Unterschied zwischen Wasserfall und Agilität erklären müssen. Viele Mythen ranken sich vor allem um die Frage: „Wird denn in Scrum überhaupt geplant, und wenn ja, für welchen Zeitraum?“ Bei den Erklärungsversuchen wird schnell klar: Die Unterschiede zum agilen Projektmanagement werden viel einfacher ersichtlich, wenn es ein Verständnis für das gibt, was Scrum nicht ist. Machen wir also einen kleinen Exkurs in die Welt des klassischen Projektmanagements, um diesem Unterschied auf den Grund zu gehen.

Wasserfall: Genaue Spezifikation vorab

Das Wasserfallmodell gilt als charakteristisch für das klassische Projektmanagement der vergangenen Jahre. Dabei werden sequentielle Projektphasen gebildet, die in einer klar definierten Reihenfolge verlaufen. Umgangssprachlich wird das Wasserfallmodell auch "Over-The-Wall-Ansatz" genannt: Es werden aufeinander aufbauende Teilergebnisse geliefert, die auf ein vorab vollständig spezifiziertes Projektziel einzahlen. Diese Teilergebnisse sind klar voneinander abgegrenzt und werden meist wie über eine Mauer in den nächsten Bearbeitungsschritt „geworfen“. Die Mitarbeiter sind bei dieser Vorgehensweise ausschließlich für einen kleinen Bereich des Gesamtprodukts verantwortlich – den Gesamtzusammenhang müssen sie nicht zwingend verstehen.

Scrum: Mit kontinuierlichem Feedback zum passgenauen Ergebnis

Agile Vorgehensweisen basieren auf einem iterativen und inkrementellen Ansatz, es wird mit Feedbackschleifen und Teilprodukten als Lieferungen gearbeitet. Schnelles Kunden- und Nutzerfeedback, kontinuierliche Verbesserung und das Liefern vollständig abgeschlossener Produktfunktionalitäten stehen dabei im Fokus der Entwicklung. Im Gegensatz zum Wasserfallmodell ist es eine Aneinanderreihung vieler PDCA-Zyklen, es gibt also ein kontinuierliches „Plan – Do – Check – Act“ entlang der gestellten Anforderungen. Das ständige Abgleichen des erreichten Status Quo spitzt das Ergebnis besser auf das zu, wofür der Kunde letztendlich wirklich bezahlen möchte. Somit kann es nicht vorkommen, dass lange Zeit in eine falsche Richtung gearbeitet wird, denn Änderungen in den Anforderungen und in der strategischen Stoßrichtung können kurzfristig berücksichtigt und umgesetzt werden. Sinnvoll wird diese Vorgehensweise gerade dann, wenn man sich in einem sehr dynamischen Umfeld befindet, in dem Anforderungen und Technologie noch unbekannt sind oder sich häufig ändern.

Wie plant man eigentlich agil?

Wenn wir nun also die Kollegen fragen, was sie am Wasserfall so sehr schätzen, berufen sich viele auf die Möglichkeit der langfristigen Planung. Das sei mit Scrum schließlich nicht möglich, dort würde nur in Sprints mit einem Horizont von zwei Wochen gedacht. Weit gefehlt. Natürlich wird auch in Scrum in Form eines Releaseplans ein Planungsausblick über eine längere zeitliche Einheit hinweg gewährleistet. Trotzdem wird in Sprints gedacht und der Releaseplan ist in Zwei-Wochen-Abschnitten getaktet. Ein massiver Unterschied zur Wasserfallplanung ist aber die Tatsache, dass es sich stets um eine lebendige Planung handelt und diese, je nach Umständen und Rahmenbedingungen, zu gegebener Zeit angepasst werden sollte. Gerade in dynamisch hochkomplexen Märkten können sich die Anforderungen innerhalb kurzer Zeit ändern, sodass eine agile Anpassung der Planung überlebenswichtig wird.Denn im Vordergrund steht das Produkt, mit dem man einen möglichst hohen Geschäftswert erzeugen möchte. Die Frage lautet also: Welche Funktionalitäten müssen wir in den nächsten Sprints in jedem Fall entwickeln, sodass wir die richtigen Funktionalitäten und damit den maximalen Mehrwert bieten, mit dem wir Käufer gewinnen können?Viel Erfolg in euren Projekten wünschen euch Jessica und Marcel!Foto: CC0 Creative Commons - Pixabay, Pexels

Agile Toolbox
Produktentwicklung
Scrum
Scrum-Begriffe
Marcel Rößner
September 20, 2018

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

ScrumMaster vs. Product Owner? Oder beides?
BG

ScrumMaster vs. Product Owner? Oder beides?

Die Wiederkehr der 80er – Nostalgie als politische Strategie?
BG

Die Wiederkehr der 80er – Nostalgie als politische Strategie?

Remote-First vs. Präsenztrainings – was ist besser?
BG

Remote-First vs. Präsenztrainings – was ist besser?

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang