Basis dieses Artikels ist der offizielle Scrum Guide™ 2017 von den Scrum Erfindern Ken Schwaber und Jeff Sutherland.

Anwendungsgebiete von Scrum

Scrum wird heutzutage neben dem Hauptanwendungsgebiet der Softwareentwicklung in verschiedensten Geschäftsfeldern eingesetzt. Mit Hilfe von Scrum können:

• Produkte, Märkte und Technologien zur Marktreife gebracht werden
• Produkte jedweder Form entwickelt und erweitert werden
• Produkte und Erweiterung in kurzen Releasezyklen ausgeliefert werden
• Produkte und Erweiterungen erhalten werden

Insbesondere in komplexem Umfeld, ist Scrum dank seines inspect&adapt Ansatzes ideal. Das Bedeutet, dass mittels Iterationen kontinuierlich Produkte, Erweiterungen oder anders gearteter Wert geschaffen werden. Nach jeder Iteration, wird das Produzierte überprüft (inspect) und der Plan auf Basis der gewonnenen Erkenntnisse angepasst (adapt).

Inspect & Adapt

Der Inspect & Adapt Ansatz basiert auf der so genannten Theorie empirischer Prozesssteuerung (kurz „Empirie“). Hierbei werden aus iterativ erlangten Erfahrungen Erkenntnisse gewonnen werden und Entscheidungen auf dessen Basis getroffen werden. Durch das iterative Vorgehen in Scrum können somit Prognosen, Pläne und Risiken kontinuierlich überprüft werden und die Prognosen und Pläne werden stetig sicherer und Risiken werden kontinuierlich mitigiert.

Transparenz

Damit der inspect & adapt Ansatz erfolgreich ist, muss ein wesentlicher Aspekt erfüllt sein: Transparenz. Es muss zu jedem Zeitpunkt gewährleistet sein, dass jedem Prozessbeteiligten möglichst alle Informationen bereit stehen, um gute Entscheidungen zu treffen. Dazu ist es auch wichtig, dass alle Beteiligten ein klares Verständnis von „fertig“ haben (Definition of Done).

Prozesstransparenz kann durch Hilfsmittel unterstützt werden:

• Burndown Charts
• Definition of Done
• Definition of Ready
• Sprint Goal

Überprüfen & Anpassen

Das Scrum Team überprüft kontinuierlich die Sprint Artefakte und den aktuellen Status der Sprintzielerreichung. Der Plan wird kontinuierlich überprüft und bei Bedarf neu justiert – es ist besser den Plan auf Basis gewonnener Erkenntnisse ergebnisorientiert anzupassen, als an einem existierenden Plan festzuhalten, wenn eine alternative Vorgehensweise ein besseres Produkt liefern kann.

Warte nicht zu lange damit den Plan zu justieren. Je länger du wartest, desto Aufwändiger wird die Plananpassung.

Im Scrum Prozess gibt es vier formale Ereignisse, bei denen die Überprüfung und Anpassung vorgenommen wird:

• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospektive

Scrum Rollen

Scrum Team

Das Scrum Team besteht aus drei Rollen:

• dem cross-funktionalem Entwicklerteam
• einem Product Owner
• sowie dem Scrum Master

Entwicklerteam

Der Scrum Guide beschreibt das Entwicklerteam als interdisziplinär aufgestellt und dass es über alle Kompetenzen verfügt, die erforderlich sind, um anstehende Aufgaben zu erledigen. Hierzu kann ich aus Erfahrung sagen: es wird sehr schwierig, diese Heile-Welt Vorstellung zu erfüllen. In der Teamzusammensetzung solltet ihr darauf achten, dass nach Möglichkeit so viel notwendige Kompetenz wie möglich im Team vorhanden ist, um so wenig Abhängigkeiten nach Außen wie möglich zu haben.

Wichtig ist ebenso, dass die Entwicklerteam selbstorganisierend sind – also ihre Aufgaben selbstständig planen und umsetzen und Aufgaben nicht von außen im Team geplant oder zugewiesen werden.

Ich empfehle als Teamgröße 4-7 Teammitglieder. Kleinere Teams sind potentiell zu wenig cross-funktional und größere Teams haben in der Regel Schwierigkeiten bei der Arbeitsorganisation – hier entsteht oft ein zu großer Abstimmungsaufwand, damit sich das Team selbst organisieren kann.

Product Owner

Der Product Owner ist für das Produkt verantwortlich. Er sollte die volle Verantwortung für das Produkt haben. Ebenso ist der Product Owner für das Product Backlog des Teams verantwortlich. Er verwaltet das Product Backlog, in dem er die Product Backlog Items formuliert oder formulieren lässt und sie priorisiert. Er muss sicher stellen, dass das Entwicklerteam versteht, welche Ziele der Product Owner verfolgt und welche Anforderungen er umsetzen möchte.

Der Product Owner ist die Rolle, die das Was? und Warum? einer Anforderung definiert – das Entwicklungsteam definiert das Wie?.

Scrum Master

Der Scrum Master ist als Servant-Leader dafür verantwortlich, dass alle im Scrum agierenden Personen, den Prozess verstehen und einhalten. Er schult alle Prozessbeteiligten, um sich kontinuierlich zu verbessern und die Prozessschritte immer sicherer durchzuführen.

Auf einem Kongress hab ich mal den Satz gehört: „Ein guter Scrum Master ist ein Scrum Master, der es schafft, sich obsolet zu machen“. Ich finde das ist eine ganz treffende Umschreibung, welches Ziel der Scrum Master verfolgen sollte: Arbeite so lange mit dem Team, bis es selbstorganisiert und sicher durch die Iterationen kommt.

Neben den Organisatorischen Aufgaben, wie Organisation und Moderation der Scrum Ereignisse, steht Coaching der Scrum Rollen im Focus des Scrum Masters. Er unterstützt den Product Owner bei der Ausübung seiner Aufgaben und gibt ihm Hilfestellungen und Tools, womit der Product Owner sich stetig verbessern kann. Das Entwicklungsteam verhilft er zur Selbstorganisation und funktionsübergreifender Teamarbeit. Er sorgt dabei für reibungslose Abläufe und ist stets dabei Hinternisse (Impediments) zu beseitigen.

Der Scrum Master schult ebenso die Organisation bei der Einführung von Scrum. Er unterstützt alle Prozessbeteiligten sowie Schnittstellen wie Stakeholder dabei Scrum als auch empirische Produktentwicklung zu verstehen und umzusetzen.

Als weiteres zentrales Ziel steht stetige Verbesserung auf der Agenda des Scrum Masters. Er führt regelmäßige Retrospektiven durch, in denen der Prozess und die Arbeitsweisen kontinuierlich optimiert werden.

Scrum Artefakte

Product Backlog

Das Product Backlog ist eine geordnete Liste von Anforderungen, welche durch das Entwicklungsteam der Reihe nach von oben nach unten abgearbeitet wird. Das Product Backlog kann unterschiedlichste Typen von Aufgaben enthalten – so können neben klassischen User Stories auch Bugs enthalten sein. Die unterschiedlichen Aufgabentypen werden pauschal als Product Backlog Items bezeichnet – unabhängig davon ob es Bugs oder User Stories sind.

Der Product Owner verwaltet das Product Backlog und sorgt für die inhaltliche Aufbereitung der Product Backlog Items, so dass dem Entwicklerteam alle Informationen vorliegen, um die Umsetzung zu machen. Es empfiehlt sich, das Product Backlog im Rahmen eines Backlog Grooming Meetings zu pflegen – dieses optionale Meeting kann vom Product Owner dazu genutzt werden, die Product Backlog Items gemeinsam mit dem Entwicklungsteam durchzugehen und den potentiell nächsten Sprint vorzubereiten. Neben dem Schätzen der Product Backlog Items können auch inhaltliche Fragen oder technische Machbarkeiten besprochen werden.

Sprint Backlog

Das Sprint Backlog beinhaltet alle Product Backlog Items, welche das Entwicklungsteam innerhalb des Sprints bearbeitet. Das Sprint Backlog wird im Sprint Planning wischen Product Owner und Entwicklerteam ausgehandelt und stellt eine Art Liefervertrag dar. Das Sprint Backlog kann während des Sprints angepasst werden (Aufgaben können ergänzt oder auch entfernt werden) – dies geschieht in Absprache mit dem Product Owner, da sich der Liefervertrag ggf. ändert. Anpassungen am Sprint Backlog sind sinnvoll, wenn im Sprint neue Erkenntnisse gewonnen werden.

Abgesehen vom Scope-Change ist das Sprint Backlog vor Veränderungen geschützt. Das Entwicklungsteam hat den gesamten Sprint kein anderes Ziel als den Vertrag zu erfüllen und die Aufgaben im Sprint Backlog zum Ende des Sprints zu liefern – natürlich immer mit Focus auf den Sprint Goal, der vom Product Owner definiert wurde.

Inkrement

Als Inkrement bezeichnet man das Sprintergebnis. Es ist das Ergebnis aller fertig gestellten Sprint Backlog Items. Ziel jedes Sprint Plannings sollte die Definition eines releasebaren Inkrements sein, welches nach Abschluss des Sprints einen Mehrwert ausliefert.

Scrum Ereignisse

Sprint

Als Sprint wird die Iteration bezeichnet, welcher einem Zeitraum von bis zu maximal vier Wochen entspricht. Am Ende des Sprints sollte idealer Weise ein Produkt-Inkrement geliefert werden. Sprints sollten immer die gleiche länge haben und die Sprints folgen direkt aufeinander. Dadurch sammelt das Scrum Team kontinuierlich Erfahrungen in der Abarbeitung der Sprints und wird damit kontinuierlich besser.

Der Lerneffekt und die Planungsgenauigkeit ist höher, je kürzer die Sprintdauer ist. Als Ideallänge hat sich für mich ein Zeitraum von 2 Wochen erwiesen, den ich insbesondere bei der Einführung von Scrum empfohle. Selbstverständlich ist es möglich die Sprintlänge an individuelle Bedürftnisse anzupassen – selbst eine Sprintlänge von 1 Tag ist denkbar, jedoch darf die Länge niemals länger als 4 Wochen sein – hier spricht man von einer fest definierten Timebox, also einer Maximaldauer.

Sobald ein Sprint gestartet ist, werden keine Anpassungen vorgenommen, die das Sprint Ziel gefährden. Der Sprint-Umfang kann während des Sprints mit dem Product Owner neu verhandelt werden, sofern sich neue Erkenntnisse ergeben. Sofern der Sprint Inhalt verändert wird, spricht man hierbei von einem Scope-Change.

Ein Sprint kann vom Product Owner – und nur von ihm – abgebrochen werden, wenn der Sprint Ziel Obsolet geworden ist. Ein Sprint Abbruch ist bei kurzen Sprintlaufzeiten selten sinnvoll – somit sollte zunächst über ein Scopechange nachgedacht werden, bevor ein Sprint bewusst abgebrochen wird. Bei einem Sprint Abbruch findet automatisch wieder ein Sprint Review statt und es folgt ein Sprint Planning für den nächsten Sprint.

Sprint Planning

Im Sprint Planning wird der jeweils anstehende Sprint geplant. Das Sprint Planning hat eine maximale Länge von 8 Stunden für einen 4 Wochen Sprint (Timebox). Für 2 Wochen Sprints ist die Timebox entsprechend nur 4 Stunden. Der Scrum Master organisiert das Sprint Planning und moderiert es. Er achtet darauf, dass die Timebox eingehalten wird und schult die Beteiligten dahin, die Timebox einzuhalten.

Am Planning nimmt zwingend das Scrum Team teil. Das Planning ist ein offenes Meeting, zu dem weitere optionale Teilnehmer erlaubt sind.

Das Sprint Planning wird in zwei Teile unterteilt.

Sprint Planning – Teil 1

Im ersten Teil des Sprint Planning Meetings präsentiert der Product Owner die Product Backlog Items, welche er im anstehenden Sprint umsetzen möchte. Er und das Entwicklungsteam diskutieren über die Machbarkeit und potentielle Abhängigkeiten oder Risiken. Der Product Owner beschreibt das Ziel des Sprints und handelt mit dem Entwicklungsteam einen Sprintskope aus. Das Team gibt dem Product Owner ein Versprechen (Commitment) über den Scope ab – damit entsteht ein Liefervertrag zwischen Entwicklungsteam und Product Owner.

Nur das Entwicklungsteam entscheidet, was sie sich in der nächsten Iteration schaffen werden – es gibt keine Vorgabe. Der Product Owner entscheidet was in welcher Reihenfolge gemacht werden soll, das Entwicklungsteam entscheidet, was im Sprint gemacht werden kann. Über die Zeit gewinnt das Entwicklungsteam ein relativ gutes Gefühl darüber, wieviel es in einer Sprint Iteration schafft. Die Velocity kann hierbei als Anhaltspunkt helfen.

Als Ergebnis des ersten Teils, steht das so genannte Sprint Backlog bereit, welches alle Product Backlog Items beinhaltet, die das Entwicklungsteam beabsichtigt im kommenden Sprint abzuschließen.

Sprint Planning – Teil 2

Im zweiten Teil des Sprint Planning Meetings erstellt das Entwicklungsteam den Arbeitsplan für den Sprint. Für jedes Product Backlog Item im Sprint Backlog werden nun die Aufgaben definiert, welche für die Erfüllung der Anforderung notwendig sind. Am Ende des zweiten Teils, hat jedes Product Backlog Item alle notwendigen Tasks, welche auf dem Sprint Board visualisiert werden, dieses kann ein haptisches Board mit Zetteln sein oder ein digitales Board.

Zum zweiten Teil ist die Anwesenheit des Product Owners nicht notwendig. Es ist aber hilfreich, wenn der Product Owner verfügbar hält, um potentielle Fragen zu beantworten oder auch den Scope neu zu verhandeln, sofern dem Entwicklerteam bei der Arbeitsplanung Erkenntnisse gewonnen hat, die es notwendig machen, einen Scopechange zu machen.

Daily Scrum

Das Daily Scrum Meeting ist, wie der Name es bereits verrät, ein tägliches Abstimmungsmeeting für das Scrum Team. Das Daly Scrum Meeting hat eine Timebox von maximal 15 Minuten und findet täglich zur selben Zeit statt. Es hat sich bewährt, das Daily Scrum Meeting am Vormittag zu machen, so dass das Entwicklerteam sich für die Arbeitsorganisation des Tages abstimmen kann.

Die Struktur des Meetings kann vom Entwicklerteam festgelegt werden. Das Entwicklerteam berichtet der Reihe nach und beantwortet folgende drei Fragen:

• Was habe ich gestern getan?
• Was beabsichtige ich heute zu tun?
• Was blockiert mich?

Da das Daily Scrum für eine vollumfängliche Arbeitsorganisation nicht ausreicht, können bei Bedarf anschließende Detaildiskussionen geführt werden, oder Fragen erörtert werden, die im Daily Scrum Meeting die Timebox gefährdet hätten.

Der Scrum Master organisiert die Daily Scrum Meetings und achtet auf Einhaltung der Timebox. Im Daily Scrum Meeting redet in der Regel nur das Entwicklerteam. Sofern andere Personen anwesend sind, wird vom Scrum Master sicher gestellt, dass sie das Meeting nicht stören.

Im Daily Scrum können Erkenntnisse gewonnen werden, die nötig sind, um ggf. eine Planänderung vorzunehmen – hierzu ist es ratsam, dass immer der Product Owner teilnimmt, um etwaige Planänderungen direkt mit ihm zu besprechen.

Sprint Review

Das Sprint Review Meeting findet am Ende des Sprints statt. Das Scrum Team schaut gemeinsam auf das Sprint Ergebnis und überprüft die Erreichung der Sprintziele. Das Sprint Review hat bei vier Wochen Sprints eine Timebox von maximal vier Stunden – bei zwei Wochen Sprints maximal zwei Stunden. Beim Sprint Review sind zwingend das Scrum Team anwesend. Grundsätzlich sollten aber möglichst alle Personen anwesend sein, die dazu beitragen können, dass das Inkrement erfolgreich wird – somit sollten auch alle Stakeholder auf die Sprint Ergebnisse schauen und Feedback geben.

Der Scrum Master organisiert das Sprint Review Meeting und moderiert es. Der Product Owner hat die Aufgabe alle notwendigen Personen außerhalb des Scrum Teams einzuladen.

Das Entwicklungsteam präsentiert die Sprint Ergebnisse und der Product Owner stellt sicher, dass alle Anforderungen erfüllt sind – er entscheidet, ob eine Anforderung abgenommen wird oder nicht.

Sprint Retrospektive

Die Sprint Retrospektive hat den Zweck, das Team und den Prozess zu analysieren und Verbesserungen zu erzielen. Die Sprint Retrospektive ist hierbei ein sehr mächtiges Werkzeug, mit dessen Hilfe sich der Scrum Prozess in eine Organisation einpasst. Reibungspunkte von Scrum innerhalb der Organisation werden diskutiert und durch gezielte Maßnahmen adressiert. Hierbei sollte man aber unbedingt darauf achten, dass man den vorgegebenen Scrum Prozess nicht verändert, sondern die Rahmenbedingungen um den Scrum Prozess!