Scrum-Grundlagen
Scrum tauchte erstmals 1995 in einem Konferenzbeitrag von Ken Schwaber auf. Dort schrieb er:
Scrum akzeptiert, dass der Entwicklungsprozess nicht vorherzusehen ist. Das Produkt ist die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität.
Der Name »Scrum« bezieht sich auf einen Spielzug im Rugby: Es handelt sich um das angeordnete Gedränge, um das Spiel zum Beispiel nach kleineren Regelverstößen neu zu starten. Das Artikelbild zeigt genau diesen Spielzug.
Inhalt
Warum Scrum?
Scrum adressiert alle Probleme des Wasserfallmodells. Im Vergleich zu anderen Methoden definiert es lediglich den Projektrahmen, macht aber keine Vorgaben bzgl. der Softwareentwicklung (»Extreme Programming« schreibt hier zum Beispiel das Pair-Programming vor). Scrum ist sehr leicht verständlich – der gesamte Prozess kann auf wenigen Seiten beschrieben werden.
Wie alle agilen Methoden führt Scrum – im Vergleich zum Wasserfallmodell – bei den meisten Teams zu einer deutlichen Steigerung der Mitarbeitermotivation.
Aufgrund der hohen Popularität in Deutschland ist die Scrum-Community sehr groß. Dadurch gibt es nicht nur genügend Gesprächspartner für einen Erfahrungsaustausch, sonder es ist auch relativ leicht Scrum-erfahrene Mitarbeiter zu finden.
Die Rollen in Scrum
Scrum kennt drei Rollen:
- den Product-Owner,
- das Team und
- den Scrum-Master.
Wie sich diese Rollen in einem konventionellen Software-Unternehmen besetzten lassen, betrachte ich in einem späteren Artikel.
Der Product-Owner
Der Product-Owner arbeitet eng mit dem Team zusammen und hat folgende Aufgaben:
- Die Vermittlung einer Produktvision.
- Die Beschreibung und das Management von Anforderungen.
- Das Stakeholder-Managemen.
Das heißt, der Product-Owner ist dafür verantwortlich alle Personengruppen, die ein berechtigtes Interesse an dem Projekt haben, auf dem Laufenden zu halten. Er sammelt und konsolidiert deren Feedback und pflegt das Product-Backlog.
Somit entspricht der Product-Owner am ehesten dem klassischen Projektleiter. Er ist allerdings explizit nicht dafür verantwortlich Aufgaben an einzelne Team-Mitglieder zu verteilen oder den Fortschritt einzelner Aufgaben zu überwachen – wohl aber den des Gesamtprojekts.
Das Team
Die zentrale Rolle hat natürlich das Team. Es ist interdisziplinär besetzt, das heißt, es besteht sowohl aus den Entwicklern als auch aus den Testern, die die entwickelten Funktionalitäten prüfen sollen. Das Team sollte aus mindestens fünf, maximal aber aus neun Mitarbeitern bestehen.
Ein agiles Team arbeitet selbstorganisiert und weitestgehend autonom. Das ist extrem wichtig bei der Zusammenstellung des Teams. Handelt es sich zum Beispiel bei einem Mitglied um ein ausgeprägtes »Alpha-Tier«, vor dem die anderen zurückschrecken, so ist das eine schlechte Voraussetzung für ein ausgeglichenes und gut funktionierendes Team.
Der Scrum-Master
Der Scrum-Master trägt die Verantwortung für das Gelingen von Scrum. Um das zu erreichen, führt er folgende Aufgaben aus:
- Er überprüft die Einhaltung der Scrum-Regeln.
- Er moderiert die Scrum-Meetings.
- Er bearbeitet Störungen des Prozesses.
Der Scrum-Master sollte nicht Mitglied des eigentlichen Entwicklungsteams sein. Er sollte eine Führungskraft, nicht aber der Vorgesetzte der Team-Mitglieder sein. Im Idealfall wird er vom Team gewählt.
Das Product-Backlog
Das Product-Backlog definiert die für das Projekt geplanten Anforderungen. Es wird vom Product-Owner erstellt und gepflegt.
In einer tabellarischen Aufstellung beschreibt jede Zeile eine Anforderung bestehend aus:
- einer Priorisierung,
- einer kurzen Beschreibung (zum Beispiel in Form einer User-Story),
- den Akzeptanzkriterien und
- einer Grobabschätzung.
Die Priorisierung kannst Du auch einfach durch die Position der Anforderung innerhalb des Dokuments ausdrücken: Je wichtiger die Anforderung ist, desto weiter oben taucht sie im Dokument auf.
Das Product-Backlog ist ein lebendes Dokument. Um mit Deinem Projekt zu starten, kann es zum Beispiel genügen, wenn nur die zuerst umzusetzenden Anforderungen vollständig definiert sind und die restlichen nur aus dem Titel bestehen.
Der Projektablauf
Auch ein Scrum-Projekt beginnt mit einer Initialisierungsphase, in der der Product-Owner das Product-Backlog aufbaut und eine grobe Planung des Releases vornimmt. Was genau geplant werden muss, hängt von Deinem Unternehmen ab. Im – aus agiler Sicht – Idealfall musst Du keine Termine oder Aufwände nennen und kannst sofort loslegen. In einem eher konventionellen Software-Unternehmen wirst Du einen Liefertermin und die geschätzten Aufwände beziffern müssen.
Im Anschluss an die Initialisierung beginnt die Implementierung, die – ganz wie wir es von agilen Methoden kennen – in kurzen Zyklen abläuft, von denen jeder ein Produkt-Inkrement liefert. In Scrum werden diese Zyklen als »Sprints« bezeichnet.
Gerade in konventionellen Umgebungen wird es nach der Umsetzungsphase noch eine klassische Stabilisierungsphase geben, in der zum Beispiel abschließende Integrations- Security‑, Last- und Performance-Tests durchgeführt werden. Gemäß meiner Erfahrung fallen diese Stabilisierungsphasen aber deutlich kürzer aus als bei der konventionellen Entwicklung: Waren nach 18 Monaten Entwicklung sechs Monate QA früher nicht untypisch, komme ich heute bei der gleichen Länge der Entwicklungsphase mit zwei bis drei Wochen aus. So kurze Zeiten setzen allerdings den Einsatz automatischer Tests voraus.
Eigenschaften eines Sprints
Ziel eines Sprints ist die Erstellung eines Produktinkrements – also die Schaffung eines Mehrwerts für die den Kunden.
Scrum empfiehlt eine Sprint-Länge von ein bis vier Wochen. Ich selbst arbeite inzwischen ausschließlich mit zweiwöchigen Sprints. Eine Woche ist aus meiner Erfahrung zu kurz, um komplexere Features umsetzen zu können. Ab einer Länge von drei Wochen wird der zu überblickende Zeitraum für die Entwickler und Tester zu groß und die Fokussierung geht verloren.
Wichtig ist es für die gesamte Projektdauer mit einer einheitlichen Sprint-Größe zu arbeiten. Das Team gewöhnt sich nach einer gewissen Zeit an diese Dauer und kann die in einem Sprint zu bewältigenden Anforderungen dann schon sehr gut abschätzen. Ausnahmen gibt es bei mir nur, wenn ein Sprint-Wechsel in den Urlaub des Product-Owners (oder in die Weihnachtsfeiertage) fallen würde.
Auch die Tage für einen Sprint-Wechsel solltest Du mit Bedacht wählen. In der Theorie wäre es optimal den Sprint an einem Freitag abzuschließen und den nächsten an einem Montag zu starten. Leider nehmen die meisten Mitarbeiter genau an diesen Tagen gerne Urlaub. Daher solltest Du den Sprint-Wechsel eher in die Mitte der Woche legen, so dass nach dem Sprint-Start noch genügend Woche übrig ist, um Fahrt aufzunehmen.
Unsere Aufgabe als Führungskraft (und der Scrum-Master wird dies überprüfen) ist es einen Sprint vor Veränderungen zu schützen.
Von Skeptikern höre ich häufig, dass Scrum nicht geeignet ist, wenn die Entwickler zum Beispiel für mehrere Produkte verantwortlich sind und Wartung (regelmäßige Fehlerbehebung) betreiben müssen. Das ist so nicht richtig. Du musst lediglich zu Beginn eines Sprints klären, welche Kapazität im Sprint zur Verfügung steht und diese dann auch für die Dauer des Sprints garantieren. Dabei ist es durchaus legitim, jeden Entwickler zum Beispiel für 12 Stunden pro Woche für Fehlerbehebung einzuplanen. Hier kommt uns die Kürze des Sprints entgegen: Es gibt nur selten Notwendigkeiten, die keine zwei Wochen warten können.
Ablauf eines Sprints
Der erste Tag eines Sprints startet mit dem Planungs-Meeting. Danach folgt an jedem Tag der Daily-Scrum. Am letzten Tag wird der Sprint mit dem Review-Meeting und der Retrospektive abgeschlossen. Dazwischen arbeitet das Team autark an den identifizierten Aufgaben.
Planungs-Meeting
Ziel des Planungs-Meetings ist die Erstellung des Sprint-Backlogs durch das Team. Dazu stellt der Product-Owner Anforderungen in der von ihm gewünschten Reihenfolge vor. Das Team entscheidet, welche davon es in den Sprint aufnehmen kann.
Im Anschluss daran zerlegt das Team die Anforderungen in einzelne Aufgaben. Ziel dabei ist es, dass sich jede Aufgabe innerhalb eines Arbeitstages durchführen lässt. Damit kann sich ein Entwickler morgens eine neue Aufgabe nehmen und sich als Ziel setzen, diese bis zum Feierabend abzuschließen.
Daily-Scrum
Der Daily-Scrum ist ein maximal 15-minütiges Meeting, das an allen Tagen des Sprints (außer dem Ersten und letzten) zur selben Zeit am Morgen vom Team durchgeführt wird. Ziel ist es die Selbstorganisation des Teams zu unterstützen, und Hindernisse zu identifizieren.
Dazu beantwortet jedes Teammitglied die folgenden Fragen:
- Welche Aktivitäten habe ich gestern abgeschlossen?
- Was habe ich heute vor?
- Was behindert mich?
Review-Meeting
Ziel des Review-Meetings ist es die fertiggestellten Arbeitsergebnisse vorzustellen, zu begutachten und Feedback von den Stakeholdern einzuholen.
Die Konsolidierung des Feedbacks und die gegebenenfalls daraus resultierende Aktualisierung des Product-Backlogs ist die Aufgabe des Product-Owners. Des Weiteren nimmt er in diesem Meeting die gemäß den Akzeptanzkriterien fertiggestellten Funktionalitäten ab.
Retrospektive
Ziel der Retrospektive ist es, eine kontinuierliche Verbesserung der Arbeitsweise des Teams zu erreichen. Dazu ermittelt der Scrum-Master gemeinsam mit dem Team SMARTe (Spezifisch, Messbar, Akzeptiert, Realistisch, Terminiert) Maßnahmen.
Weitere unregelmäßige Meetings
Zusätzlich zu den regelmäßigen Meetings tauchen in meinem Alltag noch einige weitere auf.
Backlog-Grooming
Das Backlog-Grooming dient der Pflege des Backlogs. Dazu stellt der Product-Owner die Anforderungen (zum Beispiel User-Storys und Mockups) dem Team und dem Kunden vor, die durch diverse Rückfragen Unklarheiten aufdecken.
Abschätzungs-Meetings
Ziel des Abschätzungs-Meetings ist es den Aufwand bzw. die Komplexität von Anforderungen zu beziffern. Die Abschätzung erfolgt durch das Team, üblicherweise klassich in Personentagen oder in Story-Points. Die ermittelten Werte dienen der Release-Planung und der Entscheidungsfindung im Planungs-Meeting.
Das Scrum-Board
Während eines Sprints ist das Scrum-Board das primäre Werkzeug zur Bearbeitung der Anforderungen im Team. Hierbei handelt es sich um ein klassisches Kanban-Board, auf dem alle für den Sprint geplanten Aufgaben in Form von Karten existieren. Der Status einer Aufgabe wird über die Spalte (»Offen«, »In Arbeit«, »Erledigt«) signalisiert, in der sich ihre Karte befindet.
Zusätzlich kommen meist Burndown- oder Burnup-Charts zum Einsatz um den Sprint- und Projektfortschritt zu visualisieren.
Buchtipp
Ich habe schon einige Bücher zum Thema Scrum gelesen. Die meisten kranken daran, dass die Autoren versucht haben, den Inhalt künstlich »aufzublähen« um eine relevante Seitenzahl zu erreichen. Scrum lässt sich nun mal aber auf wenigen Seiten beschreiben. Daher kann ich keines der Bücher empfehlen, die einfach nur den Prozess beschreiben.
Das Buch »Scrum in der Praxis« hingegen beschränkt sich weniger auf die Beschreibung von Scrum, sondern glänzt mit Tipps aus der Praxis zum Beispiel zur Durchführung der diversen Meetings. Hier merkt man, dass die Autoren keine Theoretiker sind. Das Buch eignet sich auch hervorragend als Nachschlagewerk. Mir hat es in jedem Fall in den letzten Jahren mit vielen neuen Denkanstößen und auch konkreten Tipps weitergeholfen.
Fazit
Du siehst: Scrum ist vom Aufbau her überhaupt nicht kompliziert und auch die Umsetzung ist aus rein fachlicher Sicht relativ einfach. Die noch fehlenden Informationen zur effizienten Umsetzung der verschiedenen Meetings und zum Einsatz notwendiger Werkzeuge (Scrum-Board, Backog, usw.) werde ich Dir in einigen Folgeartikeln liefern.
Schwieriger ist es, sich als gesamtes Unternehmen auf die Agilität einzulassen. Dazu müssen wir von der alten Denke »Umfang, Zeit und Kosten müssen bis ins kleinste Detail vor Projektbeginn definiert werden« verabschieden. Nur dann wirst Du vollständig von den Vorteilen agiler Methoden profitieren. Aber selbst eine Umsetzung von Scrum nur innerhalb der Entwicklungsabteilung bietet schon viele Vorteile – und das liegt komplett in Deiner Hand.
Tags:Scrum
Trackback von deiner Website.
Design Thinking im Marketing: in 6 Schritten zur Produktinnovation | Marktding
| #
[…] ganze erinnert sehr stark an die agile Softwareentwicklung und lässt sich sehr schön damit kombinieren – ganz im Sinne des agilen Marketings. Der […]
Reply
Matthias von Mitzlaff
| #
Vielen Dank Herr Wiegand, eine komprimierte, leicht zu überblickende Zusammenfassung, mit deren Hilfe auch Agil-Amateure wie ich schnell in die Materie hineinkommen.
Sehr gut!
Reply
Sven Wiegand
| #
Freut mich, dass der Artikel Hilfreich für sie war. Wenn Sie den Artikel gut fanden, dann empfehle ich Ihnen den AgilManagen-Podcast (»Podcast«-Tab oben auf der Seite). Da habe ich noch deutlich mehr Themen.
Reply