Ken Schwaber und Jeff Sutherland (1995)

Ziel

Die TeilnehmerInnen erhalten einen kurzen Überblick über die Projektmanagementmethode Scrum. Bewusst wird hier nur auf einen ersten verkürzten Einstieg in die Methode gesetzt, ein vollständiges Training bzw. die Begleitung der Implementierung von Scrum würde den Rahmen dieses Beitrags sprengen.

Kontext

Projektmanagement

Theoretischer Hintergrund und Praktische Umsetzung

(basierend auf Ken Schwaber und Jeff Sutherland: Der Scrum Guide (2013))

Scrum ist eine Methode, um komplexe Produkte zu entwickeln. Sie wird hauptsächlich in der Softwareentwicklung eingesetzt, eignet sich aber auch für viele andere Einsatzgebiete.

Scrum wurde von Ken Schwaber und Jeff Sutherland in den 1990ern entwickelt und wie folgt definiert:

„Scrum (n): Ein Rahmenwerk, innerhalb dessen Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.“ [Schwaber 2013]

„Scrum basiert auf der Theorie empirischer Prozesssteuerung oder kurz „Empirie“. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf Basis des Bekannten getroffen werden. Scrum nutzt einen iterativen, inkrementellen Ansatz, um Prognosesicherheit [von Terminen / Ergebnissen] zu optimieren und Risiken zu kontrollieren. Jede Implementierung von empirischer Prozesssteuerung ruht auf drei Säulen: Transparenz, Überprüfung [Inspection] und Anpassung [Adaptation].“ [Schwaber 2013]

Die 3 Säulen

Transparenz Das Wesentliche muss für jene, die Verantwortung tragen, sichtbar sein. Es bedarf dazu unter anderem einer gemeinsamen Prozesssprache und eines gemeinsamen Verständnisses von „Done.“

Überprüfung Laufende Überprüfung des Fortschrittes und der Artefakte (Definition siehe weiter unten) in Bezug auf Erreichung der Sprint-Ziele (Definition siehe weiter unten).

Anpassung Ergibt eine Überprüfung, dass das zu erwartende Produkt nicht akzeptabel sein wird, müssen der Prozess und / oder das Material so schnell wie möglich angepasst werden, um weitere Abweichungen zu minimieren.

Abb. 1: Die 3 Säulen des Scrum

Neben den drei Säulen besteht Scrum aus:

Scrum Team
Ereignissen
Artefakten

Scrum Team
Ein Scrum Team besteht aus dem Entwicklungsteam, dem Product Owner und dem Scrum Master. Sie sind selbstorganisierend und interdisziplinär. Bei der Zusammenstellung macht es Sinn, entsprechende Modelle wie zum Beispiel die Teamrollen nach Belbin oder Schindlers Rangdynamik heranzuziehen.

Product Owner

„Der Product Owner ist für die Wertmaximierung des Produkts sowie die Arbeit des Entwicklungsteams verantwortlich. Wie dies geschieht, kann je nach Organisation, Scrum Team und Einzelpersonen stark variieren.“ [Schwaber 2013]

Er alleine gibt dem Entwicklungsteam die aktuellen Anforderungen vor.

Entwicklungsteam

Das Entwicklungsteam hat gemeinsam alle Fähigkeiten, um das Produkt zu entwickeln. Alle Mitglieder sind „Entwickler“, das Team ist nicht weiter unterteilt und sie sind gemeinsam für das Endresultat dem Product Owner gegenüber verantwortlich. Idealerweise besteht das Team aus 3 bis 9 Personen.

Scrum Master

„Der Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich. Er tut dies, indem er dafür sorgt, dass das Scrum Team die Theorie, Praktiken und Regeln von Scrum einhält.“ [Schwaber 2013]

Er versteht sich als Servant Leader (nach Robert Greenleaf) gegenüber dem Scrum Team. Außenstehenden (Management, Kunden, …) gibt er Rückmeldung, welche ihrer Interaktionen hilfreich waren und welche nicht.

Abb. 2: schematische Darstellung des Scrum Teams

Ereignisse
Durch feste Ereignisse wird Regelmäßigkeit und Transparent hergestellt. Alle Ereignisse haben eine maximale Dauer (Time Boxing). Mit Ausnahme des Sprints dürfen alle beendet werden, sobald die Arbeit erledigt ist.

Sprint

Ein Sprint dauert maximal einen Monat, während dessen muss ein fertiges („Done“) Teil-Produkt (Produkt-Inkrement) hergestellt werden. Ein Sprint folgt direkt auf den anderen und alle sollten die gleiche Dauer haben. Ein Sprint umfasst:

Sprint Planning
Daily Scrums
Entwicklungsarbeit
Sprint Review
Sprint Retrospektive

Während eines Sprints

dürfen keine Änderungen vorgenommen werden, die das Sprint-Ziel gefährden
darf der Qualitätsanspruch nicht geschmälert werden
darf der Anforderungsumfang neu verhandelt werden, wenn sich neue Erkenntnisse ergeben

Jeder Sprint ist ein kleines Projekt mit

definiertem Leistungsumfang
einem Entwurf
einem flexiblem Plan

Die maximale Dauer von einem Monat wurde bewusst gewählt, um zu vermeiden, dass die Komplexität, die Kosten und das Risiko unnötig ansteigen. Durch die kurze Dauer sind regelmäßige Überprüfung und Anpassung möglich. Ein Sprint darf nur in Ausnahmesituationen vom Product Owner abgebrochen werden.

Sprint Planning

Das Sprint Planning findet zu Beginn eines Sprints statt. In einer Timebox von maximal 8 Stunden (für einen einmonatigen Sprint) werden folgende Fragen gestellt.

Was kann in diesem Sprint fertiggestellt werden?
Wie wird die ausgewählte Arbeit erledigt?
Was ist das Ziel des Sprints?

Der Scrum Master stellt sicher, dass der Sprint innerhalb der Timebox fertig geplant ist.

Daily Scrum

In einer Timebox von maximal 15 Minuten beantworten alle Entwickler täglich zur selben Uhrzeit am selben Ort die folgenden Fragen:

Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen?
Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen?
Sehe ich irgendwelche Hindernisse [Impediments], die mich oder das Entwicklungsteam vom Erreichen des Ziels abhalten?

Weiters wird der allgemeine Fortschritt im Hinblick auf das Sprint-Ziel beurteilt. Im Anschluss an den Daily Scrum können sich einzelne oder alle Entwickler treffen um detaillierte Diskussionen zu führen sowie Anpassungen oder Umreihungen der Arbeit innerhalb des Sprints vorzunehmen. Der Daily Scrum darf aber niemals mehr als 15 Minuten dauern. Der Scrum Master hilft dem Team, diese Timebox einzuhalten und sorgt dafür, dass nur die Entwickler sich aktiv einbringen.

„Daily Scrums verbessern die Kommunikation, machen andere Meetings überflüssig, identifizieren zu beseitigende Hindernisse, fokussieren sowie fördern die schnelle Entscheidungsfindung und erhöhen den Wissensstand des Entwicklungsteams. Das Daily Scrum ist ein entscheidendes Meeting zur Überprüfung und Anpassung.“ [Schwaber 2013]

Sprint Review

„Am Ende eines Sprints wird ein Sprint Review abgehalten, um das [Produkt-]Inkrement zu überprüfen und das Product Backlog bei Bedarf anzupassen. Während des Sprint Reviews beschäftigen sich das Scrum Team und die Stakeholder gemeinsam mit den Ergebnissen des Sprints. Zusammen mit eventuellen Änderungen am Product Backlog während des Sprints bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert des Produkts steigernden Punkten. Beim Sprint Review handelt es sich um ein informelles Meeting, keinen Statusreport. Die Vorführung des Inkrements ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht.“ [Schwaber 2013]

Sprint Retrospektive

In der Sprint Retrospektive (3 Stunden bei einem Sprint von einem Monat), hinterfragt das Team seine Arbeit und erarbeitet Verbesserungsvorschläge, wie es seine Arbeit innerhalb des Scrum Rahmenwerkes verbessern kann.

Sie findet am Ende eines Sprints statt. Die Ergebnisse können damit direkt in das Sprint Planning des nächsten Sprints einfließen.

Abb. 3: Ereignisse in Scrum

Artefakte

Product Backlog

Das Product Backlog

ist eine geordnete Liste von allem, was in dem Produkt enthalten sein kann
ist die einzige Anforderungsquelle für alle Änderungen am Produkt
ist niemals vollständig
ist dynamisch und lebendig; es passt sich konstant an, um für das Produkt klar herauszustellen, was es braucht, um seiner Aufgabe angemessen zu sein
lebt so lange wie das dazugehörige Produkt
beinhaltet alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen für zukünftige Releases (Versionen) des Produktes

Im Refinement (Verfeinerung) werden die einzelnen Punkte umgereiht, mit Details angereichert und Zeitschätzungen erstellt. Der Product Owner entscheidet alleine, wird aber vom Entwicklungsteam dabei unterstützt. Als Richtwert sollte die Arbeit am Product Backlog nicht mehr als 10% der Zeit der Entwickler beanspruchen.

Sprint Backlog

„Das Sprint Backlog ist die Menge der für den Sprint ausgewählten Product Backlog-Einträge, ergänzt um den Plan für die Lieferung des Produkt-Inkrements sowie zur Erfüllung des Sprint-Ziels.

Das Sprint Backlog ist eine Prognose des Entwicklungsteams darüber, welche Funktionalität im nächsten Inkrement enthalten sein wird, sowie über die erforderliche Arbeit, um diese Funktionalität in einem fertigen – „Done“ – Inkrement zu liefern.“ [Schwaber 2013]

Inkrement

„Das Inkrement ist das Ergebnis aus allen in einem Sprint fertiggestellten Product Backlog Einträgen und dem Resultat der Inkremente aller früheren Sprints. Am Ende eines Sprints muss das neue Inkrement „Done“ sein; das heißt es muss in einem verwendbaren Zustand sein und die Definition von „Done“ des Teams erfüllen. Es muss auch dann im einsatzfähigen Zustand sein, wenn der Product Owner es aktuell noch gar nicht ausliefern will.“ [Schwaber 2013]

Definition von „Done“

Um Transparenz bei den Artefakten zu gewährleisten muss das gesamte Scrum Team über eine gemeinsame Definition von „Done“ verfügen. Diese kann und wird je nach Team und Einsatzgebiet von Scrum anders sein. Mit der Zeit sollte das Scrum Team seine Definition von „Done“ laufend verbessern, um die Qualität des ausgelieferten Produktes zu erhöhen.

Kommentar

Der Zusammenhang zwischen Dauer, Komplexität, Risiko und Kosten und die Auswirkungen auf Organisationen werden – in anderem Kontext – sehr gut von Nassim Nicholas Taleb in „Antifragilität: Anleitung für eine Welt, die wir nicht verstehen“ beschrieben.

Außerhalb der Softwareentwicklung ist Scrum noch nicht weit verbreitet. Es gibt Berichte wonach es in manchen Werbeagenturen eingesetzt wird. In der Theorie lässt es sich überall dort einsetzen, wo Anforderungen zu Beginn nicht klar feststehen, diese sich somit laufend ändern und das Endprodukt in kleinen Zyklen entwickelt werden kann.

Richtiger Zeitpunkt/Voraussetzungen

Scrum ist nur ein Rahmen. Um Scrum wirklich leben zu können, helfen vor allem der Scrum Master aber auch alle anderen Mitglieder des Scrum Teams, ein umfangreiches Methodenwissen rund um Moderation, Kommunikation, Ideenfindung, Kreativitäts-techniken, Konfliktmanagement und Gruppendynamik mit Sicherheit weiter. Diese können vor oder nach diesem Einstieg in Scrum erlernt werden.

Querverweise

Agile Produktentwicklung
Servant Leadership
Time Boxing
Teamrollen nach Belbin
Rangdynamik nach Schindler
Premortem

Weiterführende Literatur

Ken Schwaber und Jeff Sutherland (2013): „Der Scrum Guide“ (Deutsche Übersetzung) [Schwaber 2013]
http://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf

Beispiel-Training (75 Minuten)

Zeit	Beschreibung	Material
15’	Gemeinsames erarbeiten welche Probleme es bei Projektmanagement Methoden gibt	Flipchart (sammeln)
30’	Scrum (3 Säulen, Scrum Team, Ereignisse und Artefakte) vortragen	Flipchart
30’	Transfer in die Praxis. Wie löst Scrum einige der genannten Probleme? Wie kann Scrum die Zufriedenheit in den konkreten Teams steigern? Welche Teile von Scrum wollen wir uns näher anschauen? Welche nächsten Schritte wären notwendig um Scrum einsetzen zu können?

Dieser Eintrag basiert in weiten Teilen auf dem deutschen Scrum Guide und steht dessen Lizenzbedingungen zu Folge unter der Creative Commons „Namensnennung – Weitergabe unter gleichen Bedingungen 4.0 International“ Lizenz zur Verfügung.