Scrum - So funktionieren komplexe Projekte!

Warum Scrum?

Wie hast du dir dein Leben vorgestellt als du klein warst? Und jetzt? Alles anders?

Nein, nein, das ist kein Aufruf, in Midlifecrisis zu verfallen! Realistisch betrachtet, passiert das jedem von uns. Wenn wir Pläne auf Grundlage unzureichender Informationen machen (z.B. als Kinder) ist es wahrscheinlich, dass unser Masterplan (Feuerwehrmann!) nicht aufgeht. Bei Softwareprojekten ist das genauso.

Planungssicherheit in hochkomplexen Bereichen

Ja. Wir wollen Sicherheit. Wir wollen andere beeindrucken. Wir wollen wissen, was die Zukunft bringt. Aber das ist eine Illusion. Siehe: BER. Klimawandel. Corona. You name it.

Das Leben ist viel komplexer, als wir uns als Kind hätten erträumen lassen. Hättest du versucht, alle Informationen zusammenzutragen, um den perfekten Plan für dein Leben auszuarbeiten - du wärst alt und grau geworden, ohne richtig gelebt zu haben. Und auch Software ist viel komplexer, als sie zu Projektbeginn erscheint.

Kosten minimieren mit Scrum

Noch schlimmer: Mit jedem abgeschlossenen Entwicklungsschritt steigen die Kosten um das Zehnfache, um ein Problem zu beheben (Zehnerregel). In der Planung ist alles noch ganz einfach. Danach steigt die Kurve exponentiell an. Einen Fehler auszubügeln, wenn die App schon beim Kunden ist, kostet also 1000mal (!) mehr, als ihn bereits in der Konzeption zu beheben.

Was nun? Noch akribischer vorausplanen? Viel Glück! Nur: Wie sollst du sonst sicherstellen, dass du Probleme frühzeitig erkennst? Die Lösung heißt Scrum.

Der perfekte Plan - iterative Entwicklung

Statt Dinge zu Beginn festzulegen, von denen man noch gar nicht genau wissen kann, ob sie sich am Ende als die richtige Lösung herausstellen (wie z.B. im Kindergarten schon zu planen, wen man später heiraten wird) geht man hier Schritt für Schritt vor - oder, um es in der Scrum-Terminologie auszudrücken: Sprint für Sprint. Und jeder Sprint beinhaltet eine neue Planungsphase, so dass sich Fehler einfach und kostengünstig beheben lassen.

Was ist Scrum?

Scrum ist ein agiles Framework, oder einfacher formuliert: eine Methode im Projektmanagement. Sie ist besonders gut dazu geeignet, komplexe Aufgaben wie die Softwareentwicklung in handhabbare Unterschritte zu untergliedern, um das bestmögliche Ergebnis zu erzielen.

Die Erfinder von Scrum - Ken Schwaber und Jeff Sutherland - haben es mit Blick auf die besonderen Herausforderungen der IT-Branche entwickelt. Entsprechend ist Scrum in der Softwareentwicklung mittlerweile zum Standard avanciert. Aber auch in anderen Bereichen nutzen viele Unternehmen und Projektleiter die Vorzüge von Scrum, da es auf den bewährten Prinzipien des Lean Development aufbaut.

Vorteile von Scrum

Ein wesentlicher Vorteil von Scrum ist, dass man damit Probleme frühzeitig erkennen und mit geringem Aufwand beheben kann - man denke an die oben beschriebene Zehnerregel. Gleichzeitig ist Scrum flexibel genug, um auf unvorhergesehene Änderungen schnell reagieren zu können.

Daraus ergibt sich, dass Scrum besonders kostengünstig ist. Zwar kann zu Beginn niemand mit Sicherheit sagen, wieviele Sprints es genau brauchen wird, um ein Projekt fertigzustellen - doch wenn man ehrlich ist, kann auch ein lineares Vorgehensmodell bestenfalls eine grobe (und riskante) Schätzung abgeben, was den Zeitaufwand angeht.

Die Möglichkeit bei Scrum, den Plan im Laufe des Projekts immer weiter zu konkretisieren, bietet zudem eine höhere Sicherheit, dass das Projekt erfolgreich abgeschlossen werden kann. Völlige Fehlkalkulationen sind unwahrscheinlich, wenn der Zeitabschnitt, den man betrachtet, nur zwei bis vier Wochen beträgt.

Wie funktioniert Scrum?

Alles schön und gut. Aber was bedeutet das praktisch? Wie funktioniert Scrum als Methode?

Um das zu verstehen ist es wichtig, zunächst einmal die Grundelemente von Scrum zu kennen. Es gibt drei verschiedene Rollen, drei Artefakte und fünf Events. Wir stellen dir hier im Einzelnen vor, wer was wann macht. In dieser Reihenfolge.

Wie ist die Aufgabenverteilung in Scrum?

In Scrum gibt es drei verschiedene Rollen: den Product Owner, den Scrum Master und das Development Team. Die Rollen legen die Zuständigkeiten im Team fest und garantieren einen reibungslosen Ablauf.

Scrum Rollen - Product Owner (PO)

Der Product Owner (PO) ist derjenige, der die Vision des Produkts immer im Auge behält und sie dem Team vermittelt. Er steht im Kontakt mit Kunden und Stakeholdern und vertritt ihre Anliegen gegenüber dem Scrum-Team. Entsprechend legt der Product Owner fest, was in welcher Reihenfolge entwickelt wird, legt die Akzeptanzkriterien fest und prüft am Ende eines Sprints, ob sie eingehalten werden. Der Product Owner ist somit teils Wirtschaftsanalyst, teils Tester.

Zu Beginn eines jeden Projekts findet ein Workshop statt, in dem Aufgaben – sogenannte Product Backlog Items (PBIs) – definiert und bezüglich Arbeitsaufwand geschätzt werden. Auf dieser Basis legt der Product Owner einen Release-Plan an, den er später durchgehend aktualisiert.

Der Product Owner steht immer zur Verfügung, um eventuelle Fragen schnellstmöglich zu klären, sobald sie auftauchen. Entsprechend arbeitet er auch eng mit dem Scrum Master und dem Entwicklungsteam zusammen. Jedoch sollte ein PO niemals auch gleichzeitig im Entwicklungsteam sein, geschweige denn Scrum Master. Der Scrum Master ist das Gegengewicht zum PO.

Scrum Rollen - Scrum Master

Der Scrum Master übernimmt bei Scrum die Rolle des Facilitators. Das bedeutet, der Scrum Master unterstützt das Entwicklungsteam, den eigenen Arbeitsprozess zu definieren und einzuhalten. Insbesondere hilft er allen Beteiligten, den Scrum-Prozess sowie die Scrum-Werte und -Prinzipien zu verstehen und anzuwenden.

Der Scrum Master agiert als Moderator, um Probleme zu lösen und den Scrum-Prozess optimal nutzen zu können. Ein weiterer Aspekt: Er beseitigt äußere Hindernisse, die der Produktivität des Development Teams im Wege stehen. Parallel dazu unterstützt er auch den Product Owner bei seinen Tätigkeiten hinsichtlich des Scrum-Prozesses.

Scrum Rollen - Development Team

Das Entwicklungsteam - auch Scrum-Team oder Development-Team genannt - besteht aus allen, die aktiv daran beteiligt sind, das Produkt zu entwerfen, zu bauen und zu testen - im besten Fall zwischen fünf und neun Personen mit T-förmigen Fähigkeiten: Ihre Spezialgebiete müssen sie sehr gut beherrschen (z.B. UX), sollten aber auch in anderen Bereichen genügend Kenntnisse haben, um bei Engpässen aushelfen zu können (z.B. Testen, Dokumentation).

Das Development-Team legt fest, wie das erreicht werden kann, was der Product Owner haben möchte, und wieviel davon im jeweiligen Sprint realistischerweise zu schaffen ist. Somit gilt: Das Team organisiert sich selbst und entscheidet gemeinschaftlich, wie die Arbeit geplant, ein- und aufgeteilt, ausgeführt und kommuniziert wird.

Circa 10% seiner Zeit sollte das Team für die Backlog-Pflege einplanen. In dieser Zeit kann es zufällig entdeckte Technische Schulden bis zu einem vernünftigen Schwellenwert beheben. Alles, was diesen Aufwand übersteigt, hält es im Schulden-Backlog fest.

Grundvoraussetzung für die erfolgreiche Zusammenarbeit ist, dass alle Teammitglieder offen und transparent kommunizieren. Dadurch entwickeln sie gegenseitiges Verständnis und Vertrauen. Das Entwicklungsteam stellt das Rückgrat des agilen Arbeitens dar. Um optimale Ergebnisse zu erzielen, sollten Teams daher längerfristig zusammen arbeiten.

Welche Hilfsmittel nutzt man in Scrum?

Um eine bessere Übersicht zu schaffen, nutzt man in Scrum verschiedene Artefakte. Sie dienen zum einen der Orientierung und der Kommunikation im Team, zum anderen geben sie Auskunft über die erzielten Resultate.

Scrum Artefakte - Product Backlog

Das Product Backlog ist eine priorisierte Liste aller Anforderungen an das Endprodukt - soweit zum jeweiligen Zeitpunkt bekannt. Das Product Backlog fällt in die Zuständigkeiten des Product Owners, der es immer auf dem aktuellen Stand halten muss. Das Product Backlog hält immer nur den aktuellen Zwischenstand fest und bleibt offen für Veränderungen, ist also niemals "final". Die Backlogpflege bezeichnet man auch als Grooming oder Refinement.

Scrum Artefakte - Sprint Backlog

Das Sprint Backlog enthält alle Aufgaben für den jeweiligen Sprint. Es ist eine detaillierte Liste, wie das Team im Sprint Entwurf, Aufbau, Integration und Test der ausgewählten Funktionen durchführen will. Jede Aufgabe enthält eine Aufwandseinschätzung.

Das Development Team erstellt das Sprint Backlog während der Sprint-Planung und aktualisiert und präzisiert es im Laufe des Sprints. Entsprechend spiegelt das Sprint Backlog immer den aktuellen Stand wider - einschließlich der noch ausstehenden Aufgaben als auch dem veränderten Wissensstand.

Scrum Artefakte - Inkrement

Das Inkrement ist die Summe aller Backlog-Items, die das Develompent Team während eines Sprints fertig gestellt hat und der Gesamtwert aller Inkremente aller bisherigen Sprints.

Am Ende eines Sprints muss das neue Inkrement der "Definition of Done" des Scrum-Teams entsprechen. Das heißt, es muss einsatzfähig sein und alle zuvor beschlossenen Kriterien für qualitativ hochwertige Software erfüllen.

Das Inkrement ist ein konkreter Beitrag, um die Vision des Projekts Wirklichkeit werden zu lassen. Der gesamte Sinn von Scrum ist es, das gewünschte Produkt - so wie im Product Backlog konzipiert - inkrementell zu erschaffen.

Wie funktioniert die Zeitplanung in Scrum?

Scrum funktioniert in regelmäßigen Zeitintervallen, die sich immer wiederholen und bestimmte Zwecke erfüllen:

Scrum Events - Sprint

Ein Sprint ist die Basiszeiteinheit bei Scrum und dauert je nach Art des Produkts 1-4 Wochen. Bei Apps empfiehlt sich eine Sprintlänge von 1-2 Wochen. In dieser Zeit erzeugt das Entwicklungsteam ein "Done"-Inkrement. Für jeden Sprint legt das Scrum-Team ein Sprintziel fest, das definiert, welches Inkrement am Ende des Sprints erzeugt worden sein soll.

Ein Sprint besteht jeweils aus:

Sprint-Planung
Ausführung
Sprint-Review
Sprint-Retrospektive

Was das im Einzelnen bedeutet, erläutern wir im Folgenden.

Scrum Events - Sprint-Planung

In der Sprint-Planung einigen sich Entwicklungsteam und Product-Owner auf ein Sprint-Ziel. Zunächst stellt der Product Owner die Items aus dem Product Backlog mit der höchsten Prio vor und beantwortet alle dazu entstehenden Fragen. Anschließend wählt das Entwicklungsteam daraus eine Teilmenge an Items aus, die für einen Sprint realistisch erscheint.

Idealerweise nimmt das Scrum-Team dafür das Element mit der höchsten Priorität aus dem Product Backlog, zerlegt es in Teilaufgaben und prüft, ob es bequem in einen Sprint passt. Wenn ja, wiederholt das Team den Vorgang, bis die Kapazitäten für den Sprint (abzüglich der 10% Puffer, s.o.) ausgeschöpft sind. Sollte ein Backlog Item zu groß sein, geht es mit dem nächstpriorisierten Element weiter.

Selbstverpflichtung Sprint-Ziel

Auch wenn das Ergebnis nur eine Prognose des Entwicklungsteams ist, sollte es trotzdem wie eine (Selbst-)Verpflichtung behandelt werden. Entsprechend wichtig ist es, die Kapazitäten des Teams nicht zu überschätzen, sondern möglichst präzise zu planen. Dieser Einschätzungsvorgang wird im Verlauf eines Projekts immer genauer, da Erfahrungswerte in zukünftige Schätzungen mit einfließen.

Die Sprint-Planung für einen zweiwöchigen Sprint dauert ungefähr vier Stunden, für einen vierwöchigen sogar acht. In diesem Zeitraum werden offene Fragen geklärt, Komplexitätslevel ermittelt und ein Gruppenkonsens geschaffen.

Scrum Events - Daily Scrum

Das Daily Scrum dient der täglichen Synchronisierung von Entwicklungsteam, PO und Scrum Master. Gleichzeitig wird der aktuelle Stand begutachtet und geplant, wie weiter vorzugehen ist.

Dazu stellt der Scrum Master der Reihe nach jedem der Teilnehmenden drei Fragen:

Was habe ich seit dem letzten Daily erreicht?
Woran möchte ich bis zum nächsten Daily arbeiten?
Welche Hürden oder Hindernisse haben meinen Fortschritt aufgehalten?

Dieses Event darf höchstens 15 Minuten dauern. Der Scrum Master achtet mit Timeboxing darauf, dass der Zeitrahmen eingehalten wird.

Scrum Events - Sprint-Review

Die Sprint-Review findet am Ende eines Sprints statt. Ihr Ziel ist es, das aktuelle Inkrement zu inspizieren und gegebenenfalls das Product Backlog so anzupassen, dass das Projektziel erreicht wird.

Sowohl die Stakeholder als auch PO, Scrum Master und Scrum-Team sind beteiligt, aber auch Sponsoren oder interessierte Mitglieder anderer Teams können teilnehmen.

Zunächst stellt das Entwicklungsteam die Ergebnisse des Sprints in einer Live-Demo vor und beantwortet Fragen. Anschließend erarbeiten alle Teilnehmer zusammen, was als nächstes zu tun ist und geben durch den gegenseitigen Austausch wichtigen Input für die nächste Sprint-Planung.

Der Informationsfluss läuft hierbei in beide Richtungen:

Außenstehende erhalten Einblick in den aktuellen Stand der Entwicklung und beeinflussen die künftige Zielrichtung des Produkts.
Das Entwicklungsteam erhält durch das Feedback ein tieferes Verständnis für Geschäfts- und Marketingziele.

Scrum Events - Sprint-Retrospektive

Nach der Sprint-Review aber vor der nächsten Sprint-Planung trifft sich das Scrum-Team zur Retro. Das Team reflektiert den Scrum-Prozess, der eingesetzt wurde, um das Produkt zu schaffen.

Das Ergebnis der Retro ist eine konkrete Anzahl an Aktionen, die alle folgenden Sprints effektiver machen sollen. Dazu können Änderungen im Product Backlog ebenso wie Anpassungen im Entwicklungsprozess zählen.

Formen von Feedback in Scrum

Scrum lebt davon, zeitnahe Rückmeldungen über die aktuelle Entwicklung des Projekts in die weitere Planung mit einfließen zu lassen. Feedback ist also unentbehrlich, um getroffene Annahmen validieren und präzisieren zu können. Entsprechend sind im Scrum-Framework vielfältige Feedback-Loops in unterschiedlichen Zeithorizonten und Setups integriert:

Sprint-Review (Feedback pro Iteration)
Backlog-Pflege (Feedback pro Woche)
Daily Scrum (tägliches Feedback)
Test-Driven Development (empfohlen, minütliches Feedback)
Pair-Programming (bei Bedarf sekündliches Feedback)

Unterschiede zur klassischen Entwicklung

Der Mensch ist ein Gewohnheitstier. Doch um die Vorteile von Scrum voll ausschöpfen zu können, muss man sich von einigen überholten Vorgehensweisen trennen und neue etablieren. Hier eine kleine Auswahl:

In den Sprints werden Funktionen als Gesamtpaket betrachtet. Fragmentiertes Denken oder das Unterteilen in Phasen (wie „Design“) haben hier keinen Platz.
Das Team trifft irreversible Entscheidungen erst so spät wie möglich – im „Last Responsible Moment“. Nur so steht so viel Wissen & Feedback zur Verfügung, wie man für eine fundierte Entscheidung benötigt.

Die Anforderungen werden anfangs nur grob formuliert. Im Laufe des Projekts gewinnt das Team neue Erkenntnisse und kann die Details ergänzen. Die Planung lässt Unsicherheiten zu, um sie im richtigen Moment zu klären, statt blinde Vorgaben zu machen.
Auch Dinge wie Designs oder Testfälle werden „just in time“ produziert.
Das Team validiert alle Annahmen. Dadurch erkennt es falsche Annahmen, anstatt sie für das ganze Projekt als korrekt vorauszusetzen.
Alle Mitarbeiter 100% der Zeit beschäftigen zu wollen ist weniger effizient als 80% Auslastung. Man versucht stattdessen, Wartezeiten zu verringern, indem Mitarbeiter im Zweifelsfall unerledigte oder unerledigbare Aufgaben angehen. Eine zu hohe Auslastung erhöht die Verzögerungskosten und ist teurer als untätige Arbeiter.
Bei Scrum-Teams handelt es sich stets um Funktionsteams. Sie vereinen alle Fertigkeiten in sich, die notwendig sind, um an Endbenutzerfeatures zu arbeiten und sie fertigzustellen. In Scrum ist außer für Wissenstransfer kein Platz für klassische Komponententeams (z. B. „Design-Team“, „iOS-Team“, etc.), die unnötige Übergabemodalitäten, Missverständnisse und Verzögerungen verursachen.

Löst Scrum alle meine Probleme?

Nein. Scrum löst nicht alle Probleme. Aber es hilft. Es schafft eine solide Grundlage, um qualitativ hochwertige Software schnell und zu einem vernünftigen Preis entwickeln zu lassen. Die Vorgaben sind dabei so reduziert wie möglich, damit Teams sich selbst organisieren können. So können sie komplexe Probleme mithilfe eines erfahrungsorientierten Ansatzes lösen.

Entscheidend ist aber auch, dass weitere Best Practices der agilen Softwareentwicklung genutzt werden. Dazu zählen unter anderen: