Die Darstellung bezieht sich jeweils auf die reine Form der beiden Ansätze. Etwaige Mischformen oder Abwandlungen (z.B.: Water-SCRUM-Fall) werden nicht beleuchtet.

Vor der Umsetzung und eventuellen Outsourcing eines Softwareentwicklung-Projektes gibt es eine wichtige Entscheidung zu treffen und zwar die Wahl der Methode bzw. des Projekt Frameworks. Stark vereinfacht kann man zwischen linearen und iterativen, inkrementellen Vorgehen unterscheiden. In der Praxis haben sich im wesentlichen zwei alternative Herangehensweisen etabliert. Softwareentwicklung nach dem Wasserfallmodell oder nach Scrum (agiles Vorgehen).

Dabei sind die beiden Alternativen in ihrer klassischen Form im Hinblick auf linear, iterativ und inkrementell wie folgt gekennzeichnet:

‍

Wasserfall - eingeschränkt iterativ, nicht inkrementell

Das Wasserfallmodell hat eine nahezu perfekte Sicht auf die Softwareentwicklung. Es wird davon ausgegangen, dass die Ergebnisse der vorhergehenden Aktivitäten fehlerfrei sind. Werden jedoch Korrekturen nötig, können sie in der vorangehenden Aktivität durchgeführt werden. Tatsächlich ist es in der Praxis selten, frühere Aktivitäten zu wiederholen. Eine inkrementelle Lieferung ist klassischerweise nicht vorgesehen.

Scrum - iterativ und inkrementell

Scrum ist sowohl inkrementell als auch iterativ und zwar kontinuierlich und unterstützt somit einen laufenden Lernprozess im Zuge der Umsetzung als auch ein laufende Lieferung von voll funktionsfähigen Software Inkrementen.

Iterativ bedeutet die Wiederholung von Teilen oder der gesamten Entwicklung mit dem Ziel der Verbesserung des Produkts und inkrementelle Entwicklung bedeutet die Wiederholung der gesamten Entwicklung mit dem Ziel der Vervollständigung durch laufende Lieferung des Produkts.

‍

Ob Scrum oder Wasserfall: Der Erfolg Ihres Produktes hängt maßgeblich von Ihrem Software-Partner ab! Verschaffen Sie sich jetzt einen Überblick über die "10 Dinge, die Sie bei der Auswahl Ihres Softwareentwicklung Partners unbedingt beachten müssen".

‍

Welches Vorgehen eignet sich besser?

Welches Vorgehen sich besser eignet hängt von der Art der Problemstellung ab. Es kann also nicht pauschal beantwortet werden, welche Ansätze besser oder schlechter sind, sondern es kommt auf den Einzelfall an. Die Frage ist also was ist passender für eine bestimmte Aufgabenstellung. Dazu mehr weiter unten.

Was ist das Wasser­fall­modell in der Software­entwicklung?

Ein Softwareprojekt, welches nach dem Wasserfallmodell umgesetzt wird, bedeutet, dass die einzelnen Projektphasen direkt aufeinander folgen und nacheinander abgearbeitet und abgeschlossen werden. Somit ist das parallele Arbeiten an unterschiedlichen Arbeitsschritten nicht vorgesehen. 

Das Wasserfallmodell ist eine Methode der Entwicklung, die ursprünglich aus dem Bereich der Bau- und Produktionsindustrie kommt. In diesen Industriezweigen ist es üblich Projekte sequentiell abzuwickeln. Der Bau eines Hauses beispielsweise, wird als Ganzes in Auftrag gegeben und die einzelnen Arbeitsschritte lassen sich nur schwer revidieren. Wenn die Wände erst mal stehen, kann man nicht zurückgehen und Änderungen am Fundament vornehmen.

Ähnlich funktioniert das Wasserfallmodell auch in der Softwareentwicklung, welches ursprünglich nach Royce in unterschiedliche Phasen eingeteilt ist. Obwohl Winston Royce mit Wasserfall keinesfalls eine Methode für die Softwareentwicklung etablieren wollte und darauf hinweist, dass Wasserfall nur eingeschränkt für die Softwareentwicklung geeignet ist, war das Wasserfall Modell viele Jahre lang der de-facto Standard in der Softwareentwicklung. Siehe dazu auch ergänzend V-Modell XT.

In welchen Fällen eignet sich Softwareentwicklung nach dem Wasserfallmodell?

Für einfache und komplizierte Aufgabenstellungen bietet sich durchaus das Wasserfallmodell an. Das Wasserfallmodell geht in seiner reinen Form davon aus, dass mit dem Beginn der Umsetzungsphase (also nach den typischen Phasen Spezifikation, Analyse und Design) bereits alles was für die Umsetzung relevant ist, bekannt ist. 

Folgende Annahmen sind somit unterstellt:

• Die Umfeld- und Marktbedingungen bleiben während der Projektumsetzung im Wesentlichen stabil.
• Das Verhalten der zukünftigen Anwender kann weitestgehend prognostizieren werden.
• Es besteht abschließendes Wissen hinsichtlich der technologischen und fachlichen Anforderungen sowie deren Lösungen.
• Es kann davon ausgegangen werden, dass es während der Umsetzungsphase zu keinen neuen Erkenntnissen kommt, die für den Wert des Produktes einzahlen. Ein nutzbringender Lerneffekt während der Umsetzung kann weitestgehend ausgeschlossen werden.
• Die einzelnen Phasen können linear aneinandergereiht und weitestgehend perfekt abgeschlossen werden.
• Eine laufende und enge Zusammenarbeit bzw. Feedback Schleifen zwischen Auftraggeber und Auftragnehmer ist während der Umsetzungsphase nicht notwendig bzw. liefert keinen Mehrwert.
• Eine kontinuierliche Lieferung von funktionsfähigen Software Inkrementen ist nicht erforderlich. Das Produkt kann zum Ende der Umsetzungsphase als ein Lieferobjekt zum Test an den Auftraggeber übergeben werden.
  
  

Die Phasen des Wasserfallmodells 

1. Systemanforderungen

Zu Beginn werden sämtliche Anforderungen, die nicht direkt das Produkt betreffen - also die sogenannten nicht-funktionalen Anforderungen, wie zum Beispiel der Preis oder Security Anforderungen gesammelt.

‍

2. Softwareanforderungen

Danach geht es um die funktionalen Anforderungen der Software. Im Lastenheft wird unter anderem festgelegt, “WAS” die Software können und welche Funktionen die Software haben muss. 

‍

3. Anforderungsanalyse

In der Anforderungsanalyse entsteht das Pflichtenheft, in dem festgelegt wird, welche Anforderungen das Produkt erfüllen muss. Dazu werden die Funktionen der Software weiter unterteilt (“WIE”), sodass diese im Detail in Bezug auf die Realisierung überprüft werden können. 

‍

4. Design 

In dieser Phase wird das technische Design, wie zum Beispiel die Architektur oder die Programmiersprache festgelegt.

‍

5. Implementierung

In der Implementierungsphase wird die Software entsprechend den Anforderungen und dem Design umgesetzt. 

‍

6. Testen

Das im Zuge der Implementierung bzw. Umsetzungsphase erstellt Produkt wird dem Auftraggeber zum kundenseitigen Test (üblicherweise für den User Acceptance Test) übergeben. Änderungsanforderungen, die sich nicht aus der Abweichung von Pflichtenheft (und den darin beschriebenen funktionalen und nicht funktionalen Anforderungen) und der Umsetzung ergeben, werden durch ein Change Request Verfahren behandelt.

‍

7.  Auslieferung 

Die fertige Software wird an dieser Stelle vom Kunden final abgenommen und geliefert.

Jede Phase muss zu 100% abgeschlossen sein, bevor das Team mit der nächsten Phase fortfahren kann. 

Was sind die Vor- und Nachteile des Wasserfallmodells?

Vorteile Wasserfallmodell:

• Passend für Entwicklungsvorhaben von einfacher als auch komplizierter Natur, die also deterministisch planbar sind, bevor mit der eigentlichen Ausführung begonnen wird. 
• Genaue Budgetierung - im Fall eines konfliktfreien Verlaufs des Projektes können die Gesamtkosten (Input) bei definiertem Funktionsumfang (Output) relativ exakt geschätzt werden.
• Geringer Abstimmungsaufwand zwischen Auftraggeber und Auftragnehmer während der Umsetzungsphase.
• Klare Definitionen von “WAS” und “WIE” vor Beginn der Umsetzung.

Nachteile Wasserfallmodell: 

• Nicht anwendbar bei komplexen Softwareentwicklungsvorhaben 
• “Späte” Änderungen führen in der Regel zu zusätzlichen Kosten bei Änderungsanforderungen, also Change Requests.
• Lange Zeitspanne bis zur Marktreife kann dazu führen, dass das Produkt bei Fertigstellung bereits veraltet ist.
• Höheres Risiko eines Projektausfalls (21 % gegenüber 8 % bei Agile).
• Benötigt vollständige Anforderungen, um das Projekt zu starten und typischerweise wird nicht nur das WAS sondern auch noch das WIE vorgegeben.
• Erfordert eine äußerst umfangreiche und detaillierte Vorabplanung und eine umfangreiche Dokumentation.
• Fehlentwicklungen werden erst spät entdeckt und führen in der Regel zu hohen Kosten.

Wie funktioniert agile Softwareentwicklung mit Scrum? 

Lange Zeit galt das Wasserfallmodell als Standardansatz im Bereich der Softwareentwicklung. Mittlerweile wurde es allerdings von den agilen Entwicklungsmethoden vom Thron gestoßen. Die Mehrheit der Softwareentwicklungsprojekte wird nun agil umgesetzt. 

Um das ganze noch ein bisschen besser zu verstehen, hier ein Beispiel. Nehmen wir eine wunderschöne, aber sehr aufwendige Hochzeitstorte. Um diese herzustellen, muss man eine Schicht nach der nächsten backen. Eine solche Torte braucht viel Zeit und ist im Grunde wertlos, bis man alle fertigen Schichten zusammensetzt und sie als krönenden Abschluss mit dem Hochzeitspaar dekoriert. 

Ähnlich besteht jede Software aus mehreren Schichten, die für den Kunden meist unsichtbar sind. Genau wie bei unserer Torten-Analogie sind nur vollständige Funktionen für den Endbenutzer von Wert. In den meisten Fällen möchte der Kunde das Produkt so schnell wie möglich auf den Markt bringen, um den BenutzerInnen einen Vorgeschmack auf das zu geben was kommen wird, und von Feedback zu profitieren.

Zurück zum Kuchen. Anstatt den ganzen Kuchen auf einen Sitz zu backen, ermöglicht die Anwendung von agilen Methoden die Aufteilung in vertikale Stücke (inkrementell), sodass jedes Stück für sich funktionsfähig ist und einen gewissen Wert für den Endnutzer hat.

Im Kern von Scrum steht ein iteratives, inkrementelles Vorgehen, das den Kunden durch laufendes Feedback einbezieht und somit den Kundennutzen als auch den Geschäftswert des Produktes maximiert. Es kann sichergestellt werden, dass ein werthaltiges Produkt frühzeitig verfügbar ist, auch wenn sich Anforderungen ändern sollten. 

Durch die Arbeit in nahtlos aufeinander folgenden Sprints, die in der Regel alle 2-4 Wochen stattfinden, werden jeweils die höchst priorisierten Elemente des Product Backlogs, die User Stories, gemäß der „Definition of Done“ umgesetzt und an den Kunden geliefert. 

Während der Entwicklung werden Vision und Ziele im Blick behalten, jedoch nur die unmittelbar nächsten Anforderungen im Detail betrachtet.

Das iterative Vorgehen erlaubt es, Details auch später, noch während der Umsetzung, zu ändern und die Erkenntnisse aus den vorangegangenen Sprint Review Meetings in den Sprint Plannings der Zukunft einfließen zu lassen. Darüber hinaus unterstützt dieses Vorgehen die Fähigkeit sich nur mit jenen Details zu beschäftigen, die auch Geschäftswert erzeugen.

‍

In welchen Fällen eignet sich individuelle Softwareentwicklung nach Scrum? 

Der Einsatz von agilem Vorgehen bietet sich insbesondere bei komplexen (im Gegensatz zu einfachen, komplizierten und chaotischen) Problem- bzw. Aufgabenstellung, siehe auch Stacey Matrix, an. 

‍

Komplexe Aufgabenstellungen sind im Wesentlichen durch folgende Merkmale gekennzeichnet:

• Mit Beginn der Umsetzung ist nicht alles bekannt. Anforderungen und Lösungswege sind nicht abschließend definiert bzw. festlegbar.
• Kausalität bzw. Ursache- und Wirkungszusammenhänge sind unklar.
• Das Verhalten der Anwender kann nicht eindeutig prognostiziert werden.
• Die Umfeld- und Marktbedingungen sind durch eine hohe Dynamik gekennzeichnet (Stichwort: VUCA-Welt)
  
  

Was sind die Vorteile von Scrum gegenüber von Wasserfall und was sind Nachteile? 

Vorteile Scrum:

• Adressiert die Komplexität der Softwareentwicklung und Software Modernisierung.
• Frühzeitiges Feedback hilft, das Produkt zu verbessern und das Risiko einer “Fehlentwicklung” zu minimieren.
• Bessere Qualität der Software durch kontinuierliches Testen (Unit- und Integrationstest für jedes Software Inkrement) und Abstimmung mit Kunden und Anwendern. Vermeiden von technischen Schulden.
• Schnellere Time-to-Market und ROI.
• Flexible Anpassungen innerhalb eines definierten Budget Rahmens. Methoden wie Planning Poker helfen bei der agilen Aufwandsschätzung.
• Maximierung des Geschäftswerts des Produktes (Outcome) bei Minimierung von Output (Features) und Input (Budget). Ziel: Leichtgewichtiges Produkt mit maximalem Business Impact. Mehr zu Impact Mapping hier.
• Adressiert die kontinuierliche Verbesserung der Zusammenarbeit zwischen Auftraggeber und Auftragnehmern während der Umsetzung in Retrospektiven.
• Erfolgreicher Abschluss des Projektes ist 1,5 x höher als bei Wasserfall.
• Erhöht die Transparenz während der Entwicklung des Produktes. 

‍

Nachteile Scrum:

• Der Product Owner muss während der Umsetzungsphase laufend verfügbar sein, aktiv gestalten und weitestgehend autonom hinsichtlich Product Backlog Items entscheiden und priorisieren können. Er muss also organisatorisch “empowered” werden, Entscheidungen auch ohne Rücksprache mit diversen Stakeholdern treffen zu können.
• Selbstorganisation und Autonomie kann für manche Beteiligten überfordernd sein, insbesondere, wenn noch keine Erfahrung vorhanden ist. 
• Scrum setzt für ein reibungsloses Gelingen auch gewisse organisatorische Rahmenbedingungen (wie Werte, Prinzipien, Mindset, Leadership Verständnis) - siehe dazu agiles Manifest - voraus. Es gibt somit eine gewisse Abhängigkeit zum Reifegrad der Organisation bzw. zum “fit for purpose”. Bei Missverständnissen wie die Scrum Methode in der Praxis funktioniert, entstehen manchmal Fehler in der Umsetzung von Scrum die einfach zu vermeiden wären.
• Scrum setzt eine ausgeprägte Kommunikations- und Teamfähigkeit voraus.
• In einem idealen Scrum Entwicklungsteam müssen alle Kompetenzen vorhanden sein, um ein Produkt Ende-zu-Ende (Konzeption, Design, Frontend, Backend, Testing, DevSecOps, agile Frameworks) zu entwickeln. Das setzt relativ hohe Anforderungen an die Fähigkeiten und Erfahrungen des EntwicklerInnen-Teams.

Fazit

Bei der Betrachtung von Wasserfall versus Scrum geht es nicht um die Frage “besser oder schlechter” sondern, um die Frage welches Vorgehen für welche Problemstellung geeigneter erscheint und das gesteckte Ziel optimal unterstützt. Dabei sind gewisse organisatorische und kulturelle Rahmenbedingungen ebenfalls in den Blick zu nehmen, um das Gelingen der einen oder anderen Variante sicherzustellen.

Darüber hinaus ist die grundsätzliche Sichtweise in Bezug auf das Entwicklungsteam eine durchaus unterschiedliche. Bei Scrum unterstellen wir dem EntwicklerInnen-Team einen Expertenstatus mit der Fähigkeit autonome Entscheidungen zum Wohle des Produktes hinsichtlich dem “Wie” zu treffen (das “Was” wird überwiegend durch den Product Owner bestimmt).

Wohingegen beim Wasserfallmodell neben dem “Was” auch das “Wie” der Umsetzung durch das Pflichtenheft bestimmt ist. Zugespitzt kann man sagen, dass das Wasserfallmodell die EntwicklerInnen in die Rolle eines reinen “Coders” mit eingeschränkte Gestaltungsspielraum versetzt, wohingegen Scrum den Anspruch in Richtung digitaler Produktentwicklung mit deutlichem Einfluss auf den Geschäftswert des Produktes erhebt. 

Darüber hinaus ist das Projekt Erlebnis und die Zusammenarbeit zwischen Auftraggeber und Auftragnehmer deutlich unterschiedlich. Vereinfacht kann man das Wasserfall orientierte Vorgehen mit einem Tennisspiel vergleichen. Der Ball ist während der typischen Phase überwiegend entweder im Feld des Auftraggebers oder des Auftragnehmer. Bei Scrum formieren Product Owner (Auftraggeber) und Entwicklungsteam (Auftragnehmer) unterstützt durch einen Scrum Master ein gemeinsames Team, das laufend an der Entwicklung des Produktes eng zusammenarbeiten.

‍

Sie sind auf der Suche nach einem Umsetzungs-Partner im Bereich Softwareentwicklung? Hier geht's zum Leitfaden „10 Dinge, die Sie bei der Auswahl Ihres Softwareentwicklung Partners unbedingt beachten müssen."