„Ab ins Gedränge!“ Oder, was ist eigentlich Scrum?

Scrum und Rugby – zwei Themen, die für den interessierten Laien auf den ersten Blick nur wenig gemein haben. Allerdings: Der Begriff “Scrum” stammt aus dem Rugby-Sport und beschreibt eine Standardsituation, mit der das Spiel auf Kommando des Schiedsrichters neu gestartet wird. Beim Scrum bilden die Spieler einer Mannschaft ein Gedränge, aus welchem der Ball herausbefördert werden muss. Dabei kommt es auf die Flexibilität, Dynamik und Absprachen innerhalb der Gruppe an, essenzielle Erfolgsfaktoren auch beim Scrum im Projektmanagement.

Abbildung 1: Der Begriff Scrum ist kein Akronym, sondern angelehnt an den Rugby-Sport und wird mit “Gedränge” übersetzt.

Scrum ist ein agiles Rahmenwerk zur Produkt- und Softwareentwicklung, mit Hilfe dessen Produkte in kurzen Zyklen – genannt „Sprints“ – inkrementell entwickelt werden können. Da in jedem Sprint ein potenziell auslieferbares Produkt entsteht, welches durch einen Vertreter der Kundeninteressen* (Product Owner) geprüft und abgenommen wird, wird die Entwicklungsarbeit in regelmäßigen Abständen hinsichtlich des entstehenden Mehrwerts überprüft. Auf diese Weise können Abweichungen zwischen den entstehenden Funktionalitäten und der häufig volatilen Erwartungshaltung des Kunden früh erkannt und mit vergleichsweise geringem Aufwand korrigiert werden.

Dieser Blogartikel basiert zu großen Teilen auf dem „Scrum-Guide™[1]“, einem frei verfügbaren Leitfaden, der auf ca. 15 Seiten die sogenannten „Spielregeln“ gemäß der „Scrum-Erfinder“ Ken Schwaber und Jeff Sutherland zusammenfasst. Er dient als Grundlage für weitere Blogartikel zum agilen Projektmanagement.

Scrum-Werte

Scrum basiert auf den fünf Grundwerten Fokus, Mut, Selbstverpflichtung, Offenheit und Respekt.

	Fokus: Jeder fokussiert sich auf die Arbeit im Sprint und die Ziele des Scrum-Teams.
	Mut: Die Mitglieder des Scrum-Teams haben den Mut, das Richtige zu tun und an schwierigen Problemen zu arbeiten.
	Selbstverpflichtung: Jedes Mitglied verpflichtet sich persönlich dazu, die Ziele des Scrum-Teams zu erreichen.
	Offenheit: Das Scrum-Team und seine Stakeholder sind sich einig, offen mit allen Belangen ihrer Arbeit und den damit verbundenen Herausforderungen umzugehen. Beteiligten teilen ihr individuelles Wissen mit dem gesamten Scrum-Team.
	Respekt: Mitglieder von Scrum-Teams respektieren sich gegenseitig als fähige, eigenverantwortliche Individuen.

Scrum-Team

Ein Scrum-Team besteht aus einem Product Owner, dem Entwicklungsteam (bestehend aus drei bis neun Entwicklern) sowie einem Scrum-Master.

Abbildung 2: Der Scrum-Prozess

Product Owner

Der Product Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, welches vom Entwicklungsteam erstellt wird. Er maximiert den Produktwert, indem er entscheidet, welche Anforderungen des Kunden aus dem Product Backlog in welcher Reihenfolge entwickelt werden. Er ist die einzige Person, die diese Entscheidung treffen darf und muss. Um den Produktwert zu maximieren, arbeitet er eng mit den Stakeholdern des Projekts wie z. B. den Endanwendern, Kunden oder weiteren Unternehmensteilen zusammen. In seiner Rolle als Vermittler zwischen dem Scrum-Team und dem Kunden besetzt er den sog. Single Point of Contact zwischen Entwicklung und Kunde.

Entwicklungsteam

Das Entwicklungsteam besteht aus Fachexperten, die am Ende eines jeden Sprints ein fertiges Produktinkrement übergeben, welches potenziell auslieferbar ist. Es arbeitet selbstorganisiert und entscheidet selbstständig, wie die priorisierten Anforderungen umgesetzt werden. Die drei bis neun Teammitglieder sind untereinander gleichberechtigt.

Scrum-Master

Der Scrum-Master ist dafür verantwortlich, die Umsetzung der Scrum-Regeln im Team bestmöglich zu unterstützen. Er agiert als „Servant Leader“ für das Team und coacht das Entwicklungsteam in der Selbstorganisation und Zusammenarbeit sowie den Product Owner beim Management des Product Backlogs.

Product Backlog

Das Product Backlog ist eine geordnete Liste aller bisher bekannten Anforderungen an das Produkt. Aufgrund ständiger Anpassungen ist es niemals vollständig oder final, sondern wird regelmäßig durch den Product Owner bearbeitet und ergänzt.

Damit eine Anforderung im folgenden Sprint bearbeitet werden kann, muss sie eine Definition of Ready (DoR) erfüllen. Sie definiert die Qualitätsanforderungen des Entwicklungsteams an einzelne Anforderungen, damit sie als „entwicklungsfähig“ angesehen werden. Mögliche Qualitätsanforderungen sind bspw. das Vorhandensein aller nötigen Informationen oder richtiger Zuschnitt und Umfang der Anforderungen.

Um die einzelnen Anforderungen „ready“ zu machen, haben sich in der Scrum-Praxis sogenannte Refinement Meetings zur Verfeinerung des Product Backlogs etabliert. In diesen Terminen wird ein gemeinsames Verständnis der Anforderungen entwickelt und einzelne Anforderungen werden ggf. mit fehlenden Details angereichert. Teilnehmer am Refinement Meeting sind der Product Owner, das Entwicklungsteam sowie ggf. weitere Stakeholder.

Scrum-Ereignisse

Sprint

Der Kern von Scrum ist der Sprint, ein Zeitraum von zwei bis maximal vier Wochen, innerhalb dessen ein fertiges, nutzbares und potenziell auslieferbares Produktinkrement hergestellt wird. Dies bedeutet nicht, dass ein potentiell auslieferbares Produktinkrement zwingend nach jedem Sprint ausgeliefert werden muss. Nur bloß, weil das Produktinkrement potenziell auslieferbar ist, muss es nicht zwingend nach jedem Sprint ausgeliefert werden.

Alle Sprints innerhalb eines Entwicklungsvorhabens sollen die gleiche Dauer haben. Eine konstante Dauer der Sprints ermöglicht es dem Entwicklungsteam, besser abzuschätzen, welchen Umfang an Anforderungen es im Sprint schafft.

Sprint Planning

Im Sprint Planning wird die Arbeit für den kommenden Sprint gemeinsam im Scrum-Team geplant und ein – vom Product Owner vorgeschlagenes – Sprint-Ziel wird festgelegt. Im ersten Teil des Planungsmeetings schätzt das Entwicklungsteam den Umfang der im Sprint zu entwickelnden Funktionalitäten. Anschließend plant das Entwicklungsteam, wie es die Anforderungen im kommenden Sprint umsetzen möchte.

Die festgelegte Liste der Anforderungen für den kommenden Sprint sowie der festgelegte Umsetzungsplan wird als Sprint Backlog bezeichnet. Während das übergreifende Product Backlog durch den Product Owner verantwortet wird und jederzeit bearbeitet und ergänzt werden kann, wird das Sprint Backlog ausschließlich durch das Entwicklerteam gepflegt und kann während des Sprints nicht von „außen“ beeinflusst werden, damit das Entwicklungsteam über eine stabile Grundlage für die Entwicklungsarbeit verfügt.

Daily Scrum

Im Rahmen des Daily Scrums überprüft das Team täglich den Fortschritt und plant, wie es in den nächsten 24 Stunden auf das Ziel hinarbeiten kann. Das Daily Scrum ist ein interner Termin des Entwicklungsteams mit einer maximalen Dauer von 15 min. Jedes Teammitglied beantwortet im Rahmen des Daily Scrums die folgenden drei Fragen:

1. Was habe ich gestern getan, das dem Entwicklungsteam geholfen hat, das Sprint-Ziel zu erreichen?
2. Was werde ich heute erledigen, um dem Entwicklungsteam beim Erreichen des Sprint-Ziels zu helfen?
3. Sehe ich irgendein Hindernis, das mich oder das Entwicklungsteam daran hindert, das Sprint-Ziel zu erreichen?

Abbildung 3: Der Scrum-Prozess

Sprint Review

Am Ende eines Sprints wird ein Sprint Review abgehalten, um die entwickelten Funktionen zu überprüfen und den Stakeholdern sowie dem Product Owner vorzustellen. Im Rahmen der anschließenden Diskussion besteht die Möglichkeit, Ideen für zukünftige Verbesserungen oder Erweiterungen des Produktes zu sammeln sowie Feedback zu den vorgestellten Entwicklungen zu geben. Mögliche Ergänzungen werden vom Product Owner ins Product Backlog aufgenommen.

Damit eine Anforderung abgenommen werden kann, sind neben den definierten Akzeptanzkriterien eine Liste von weiteren Fertigstellungskriterien hinsichtlich Qualität, Skalierbarkeit, Dokumentation, Tests etc. zu erfüllen. Die gesammelten Anforderungen an eine „fertige“ Anforderung werden als Definition of Done (DoD) bezeichnet.

Das Gesamtergebnis aller, in diesem und in früheren Sprints, fertiggestellten Anforderungen wird als Produkt Inkrement bezeichnet.

Sprint Retrospektive

Die Sprint Retrospektive ist ein zentrales Element im Scrum Prozess und findet nach dem Sprint Review und vor Beginn des nächsten Sprints statt. In der Retrospektive soll das Scrum-Team die interne Zusammenarbeit reflektieren, um Verbesserungspotenziale zu identifizieren. Am Ende des Termins wird mindestens eine konkrete Verbesserungsmaßnahme für den folgenden Sprint festgelegt.

ScrumBut und ScrumAnd

Scrum in seiner von Schwaber und Sutherland beschriebenen „Reinform“ wird in der Praxis nur von den wenigsten Organisationen für die Produktentwicklung angewendet. Die Abweichung vom Scrum-Standard wird als ScrumBut bezeichnet. Durch ScrumButs kann das Scrum-Vorgehen an die konkreten Bedingungen von Organisationen angepasst werden und kann sich sowohl auf Rollen, als auch auf die Ereignisse und Artefakte beziehen. Häufig betreffen ScrumButs insbesondere die Dauer und Frequenz der Scrum-Ereignisse.

Im Gegensatz zum ScrumBut ergänzen ScrumAnd das Scrum-Framework um spezifische Praktiken und Vorgehensweisen wie bspw. der Verwendung von User Stories, Epics oder Taskboards.

Quelle

[1] https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf

• In diesem Fall kann der Kunde sowohl intern als extern sein.