Scrum

Ken Schwaber und Jeff Sutherland (1995)

(als pdf herunterladen)

 

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.

 

scrum_3 säulenAbb. 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.

 

scrum_srum teamAbb. 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.

 

scrum_ereignisseAbb. 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

 

Weiterführende Literatur

 

 

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.

 

Du kennst weitere Theorien und Modelle zu diesem Thema oder hast gute Ideen, wie man dieses Modell ins Training einbauen kann?

Hinterlasse hier einen Kommentar zu deinen persönlichen Erfahrungen und Ideen und hilf so anderen Trainerinnen und Trainern dabei, den Beitrag optimal zu nutzen!