Wasserfallmodell versus agile Vorgehensweise

Werfen wir zunächst einen Blick auf die grundsätzlichen Unterschiede zwischen einem klassischen Wasserfallmodell und der agilen Vorgehensweise:

Wasserfall:

Beim Wasserfallmodell werden einzelne Phasen linear, aufeinander aufbauend abgearbeitet. Jede Phase besitzt einen definierten Start- und Endpunkt sowie ein definiertes Resultat. Die Nutzung eines Wasserfallmodells bedarf also einer sehr präzisen Planung; auf Änderungen im laufenden Projekt einzugehen, ist oft nur mit zusätzlichen Planungsaufwand möglich. Nutzbare Ergebnisse (z.B. eine Software) entstehen bei Nutzung der Wasserfallmethode erst am Ende des Projekts, dann allerdings (im Idealfall) vollumfänglich und unter Berücksichtigung aller geplanter Aspekte.

Agil:

Häufig stellt sich (gerade im Bereich der Softwareentwicklung) heraus, dass eine Planung aller Aspekte im Vorfeld nur schwer möglich ist, so dass sich fast immer Änderungen im laufenden Projekt ergeben. Außerdem ergeben sich bei Test und Nutzung der entwickelten Systeme oft weitere zu berücksichtigende Punkte, die „am grünen Tisch“ nicht vorherzusehen sind. Daher greifen agile Vorgehensmodelle das Thema „Änderung“ proaktiv auf und sehen dies nicht als Nachteil, sondern als Chance, ein Projekt aufgrund von „echter“ Erfahrung erfolgreich zu gestalten.

So wird bei der agilen Entwicklung in Iterationen gearbeitet (bei Scrum z.B. „Sprints“ genannt). Am Ende jedes zeitlich genau definierten Sprints steht ein „Stück Software“ zur Verfügung, welches ein potentielles Release darstellt und real oder unter realen Bedingungen genutzt werden kann. Dies wiederum generiert Feedback seitens der User, welches in weiteren Iterationen berücksichtigt werden kann. So entsteht Schritt für Schritt eine immer bessere und vollständigere Software.

Herausforderung beim Einsatz von agilen Vorgehensmodellen ist oft die Tatsache, dass sich alle Beteiligten auf die Agilität einlassen müssen. Dies betrifft auch den Auftraggeber, der als Vorteil erkennen muss, dass im Vorfeld eben nicht genau bekannt ist, wie sich die Software im Verlauf des Projekts entwickeln wird.

Scrum – kurz und bündig

Scrum ist wahrscheinlich das prominenteste agile Vorgehensmodell und sei in diesem Abschnitt kurz und bündig beschrieben. Diese Darstellung ist leicht vereinfacht und soll dem ersten Grundverständnis von Scrum dienen.

Ein Scrum Team besteht aus folgenden Rollen:

Product Owner:

Der Product Owner ist für die Eigenschaften und damit für den (wirtschaftlichen) Erfolg der zu entwickelnden Software verantwortlich. Er spezifiziert und priorisiert Anforderungen – und befüllt damit das sogenannte „Product Backlog“, eine Liste der umzusetzenden Anforderungen.

Entwicklungsteam:

Das Entwicklungsteam ist für die Umsetzung der vom Product Owner spezifizierten Anforderungen zuständig. Dabei kümmert sich das Entwicklungsteam um alle relevanten Tätigkeiten: Von der Softwarearchitektur, über die Programmierung bis hin zum internen Testen der Software, und dies alles innerhalb eines Sprints.

Scrum Master:

Man könnte zunächst meinen, dass der Scrum Master eine Art „Projektleiter“ ist. Dies ist jedoch nicht richtig, denn Scrum setzt auf sehr flache Hierarchien. Vielmehr ist der Scrum Master dafür verantwortlich, dass die Nutzung von Scrum als Vorgehensmodell erfolgreich ist. Er hilft dabei, die Scrum-Regeln einzuhalten und Störungen bei der Nutzung von Scrum zu entfernen.

Folgende Aktivitäten finden bei Scrum statt:

Sprint Planning:

Hier besprechen die Mitglieder des Scrum Teams, welche Einträge des Product Backlogs im kommenden Sprint bearbeitet werden. Auch werden die einzelnen zu bearbeitenden Themen im Detail besprochen und in feingranulare „Tasks“ aufgeteilt, so dass das Entwicklungsteam mit der Arbeit loslegen kann. Die zu bearbeitenden Einträge aus dem Product Backlog werden dann in das Sprint Backlog für den jeweiligen Sprint übernommen.

Daily Scrum:

In einem täglichen, 15 Minuten andauernden Meeting trifft sich das Entwicklungsteam. Dabei berichtet jedes Mitglied, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum zu erreichen gedenkt, und ob es aktuelle Hindernisse oder Probleme gibt. Scrum Master und Product Owner können bei diesem Meeting anwesend sein, die inhaltliche Beteiligung obliegt jedoch dem Entwicklungsteam.

Sprint Review:

Hier werden die Ergebnisse eines Sprints präsentiert und es wird überprüft, ob die für den Sprint gesteckten Ziele erreicht wurden. Wichtig ist, dass Stakeholder, wie z.B. Kunden oder Anwender, sich beim Sprint Review aktiv beteiligen, so dass Feedback eingeholt werden kann, um Verbesserungen bei nachfolgenden Sprints zu erreichen.

Sprint Retrospective:

Ein internes Meeting des Scrum Teams am Ende eines Prints, um Feedback zu besprechen und eine ständige Verbesserung der Arbeitsweise zu erreichen.

Was deckt Scrum nicht ab?

Unter anderem ist hier zu erwähnen, dass Scrum sehr stark auf die eigentliche Lieferung der Software fokussiert ist. Eine übergeordnete Planungs- und Projektmanagement-Ebene ist hier nicht vorgesehen. So kann es gerade bei komplexeren Projekten wichtig sein, diese Ebene zu ergänzen. Ein Lösungsansatz kann hier der Einsatz von PRINCE2 sein, eine umfassende und gut adaptierbare Projektmanagementmethode, welche seit Ende 2015 mit PRINCE2 Agile auch für den agilen Einsatz angepasst wurde.

PRINCE2 im Überblick

PRINCE2 (Projects in Controlled Environments) ist eine skalier- und adaptierbare Projektmanagementmethode, welche dem „Best-Practice“-Gedanken folgt. PRINCE2 sieht unterschiedliche Phasen für ein Projekt vor, welche von der Vorbereitung bis zum Abschluss des Projekts alle Hierarchien, von der Leitungsebene, über das Projektmanagement bis hin zur ausführenden Ebene, einbeziehen. Dies sorgt für klare Aufgaben und Verantwortlichkeiten.

PRINCE2 sieht dabei sieben Phasen für ein Projekt vor, welche in Ausgestaltung und Umfang sehr stark an die jeweiligen Projektanfordernisse angepasst werden können.

Ebenso einbezogen werden Themen wie beispielsweise die fortlaufende, geschäftliche Rechtfertigung sowie Risiko- und Qualitätsmanagement.

PRINCE2 kann sowohl nach dem Wasserfallmodell, wie auch als PRINCE2 Agile in Verbindung mit agilen Vorgehensmodellen (wie z.B. Scrum) genutzt werden. Die im vorhergehenden Abschnitt genannten Grenzen von Scrum lassen sich dabei gut mit PRINCE2 erweitern.

PRINCE2 Agile

Hier werden die Vorteile von PRINCE2 und agilen Vorgehensmodellen (wie z.B. Scrum kombiniert). Während die Werkzeuge von PRINCE2 in den oberen Managementebenen des Projekts greifen, können Vorteile und Flexibilität von Scrum beim Managen der Produktlieferung genutzt werden. Je nach Ausgestaltung der Prozesse und der jeweiligen Rollen kann dabei auch der Grad der Agilität verändert und an die jeweilige Projektumgebung angepasst werden.

Wie agil darf es denn für Sie sein?

Agilität im Projekt ist keine Frage, die mit „ja“ oder „nein“ beantwortet werden muss. Vielmehr kann der Grad der Agilität (speziell auch bei der Verwendung von PRINCE2 Agile) an die jeweiligen Anforderungen angepasst werden. PRINCE2 Agile beschreibt in diesem Zusammenhang auch Bewertungsmethoden, um anhand verschiedener Aspekte den optimalen Grad der Agilität im Projekt zu ermitteln.

Gerne berate ich Sie in diesem Zusammenhang. Als zertifizierter Scrum Master, Scrum Product Owner und PRINCE2 Practitioner helfe ich Ihnen dabei, die für Sie und Ihr Projekt optimale Vorgehensweise zu finden. Dabei unterstütze ich Sie bei allen Projekten im Themenbereich „Marketingtechnologie“ – als Scrum Master, Product Owner oder Projektmanager (je nach eingesetzter Methode).

Haben Sie Fragen, oder möchten Sie weitere Details zu den vorgestellten Themen mit mir besprechen? Kontaktieren Sie mich jederzeit. Von der Anforderungsanalyse bis hin zum Rollout unterstützt Sie die rb omnichannel GmbH gerne.

Herzliche Grüße

Ihr Roland Bühler