t2informatik » Wissen kompakt » Scrum

Scrum

Was ist Scrum, welche Events, Rollen, Artefakte gibt es und wo liegen die Vorteile?

Scrum Definition

Scrum ist ein agiles Framework für die Entwicklung und Instandhaltung komplexer Produkte und Services. Ursprünglich für die Softwareentwicklung konzipiert, wird Scrum heutzutage in vielen Bereichen und Industrien für die Produktentwicklung und im Projektmanagement verwendet.

Der Scrum Guide, der die Regeln zur Anwendung von Scrum beinhaltet, definiert fünf Events – auch als Rituale, Aktivitäten oder Ereignisse – bezeichnet:

  • Sprint,
  • Sprint Planung,
  • Daily Scrum,
  • Sprint Review und
  • Retrospektive.

Er kennt drei Rollen:

  • Product Owner,
  • Scrum Master und
  • Entwicklungsteam.

Und er benennt drei Artefakte:

  • Product Backlog,
  • Sprint Backlog und
  • Product Inkrement.

Diese Events, Rollen und Artefakte sind der Kern von Scrum.

Der Ansatz von Scrum ist empirisch, inkrementell und iterativ. Er geht davon aus, dass viele Entwicklungsprojekte zu komplex für eine exakte Planung und Beschreibung sind, da viele Anforderungen und Lösungen zu Projektbeginn unklar sind. Diese Unklarheiten werden durch ein schrittweises Vorgehen und die Entwicklung von potenziell lieferfähigen Inkrementen beseitigt.

Scrum mit Events, Rollen und Artefakten

Erläuterungen:

Scrum adressiert die gemeinschaftliche Entwicklung von komplexen Produkten und Services. Das Team, ausgestattet mit benötigten Kompetenzen, organisiert sich innerhalb fester Zeitspannen selbst, wobei es sich verpflichtet, regelmäßig und so früh wie möglich, fertige Funktionalität zu liefern.

Das Herz von Scrum ist der sogenannte Sprint. Er umfasst die Sprint Planung, in der vereinbart wird, „was“ „wie“ umgesetzt wird. Im Zuge der Implementierung gibt es ein täglich stattfindendes Meeting, Daily Scrum genannt. Es dient der Synchronisation untereinander. Im Sprint Review wird die erledigte Arbeit beurteilt und in der Folge ein Inkrement erzeugt, das funktionsfähig und potenziell lieferfähig sein muss. In Zuge der Retrospektive wird das Miteinander im zurückliegenden Sprint mit dem Ziel erörtert, die zukünftige Zusammenarbeit zu verbessern. Und schon beginnt der Ablauf von vorne.

Vorteile von Scrum

Da Vorhersagen und die Erstellung von realistischen Plänen bei der Entwicklung von Software und Systemen häufig schwierig sind, dreht Scrum den Ansatz um: Wissen entsteht aus Erfahrung und Erfahrung entsteht im Laufe einer Entwicklung. In Verbindung mit dem iterativen Vorgehen, dem Commitment des Teams auf das Sprint-Ziel und dem frühzeitigen Erkennen von Hindernissen (den sogenannten Impediments), erhöht sich die Vorhersagbarkeit und das Entwicklungsrisiko sinkt.

Zusammengefasst bietet Scrum folgende Vorteile:

  • Einfaches Set aus Rollen, Aktivitäten und Artefakten; leicht zu verstehen und anzuwenden.
  • Hohe Flexibilität beim Arbeiten mit Scrum.
  • Konzentrierte Kommunikation zwischen den Scrum Rollen.
  • Unmittelbares Feedback zwischen den Rollen im Zuge der Aktivitäten und durch Stakeholder.
  • Transparenz der Arbeitsschritte und Zwischenergebnisse.
  • Die Fähigkeit, Abweichungen zu erkennen und zu korrigieren.
  • Die Möglichkeit, den gelebten Prozess im laufenden Projekt zu justieren.

 

Das agile Manifest

Im Jahr 2001 formulierten 17 Autoren, u. a. Ken Schwaber und Jeff Sutherland, die Erfinder von Scrum, und Ken Beck, einem der drei Begründer von Extreme Programming, das agile Manifest. Es definiert Leitsätze und Prinzipien, die in Scrum Anwendung finden:

  • Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  • Funktionierende Software ist wichtiger als eine umfassende Dokumentation.
  • Die Zusammenarbeit mit Kunden ist wichtiger als die Vertragsverhandlung.
  • Das Reagieren auf Veränderung ist wichtiger als das Festhalten an Plänen.

Diese Leitsätze – häufig als Werte deklariert oder als Werte-Paare verstanden – beinhalten immer zwei Seiten. Die linke Seite (bspw. „Individuen und Interaktionen“) ist dabei wertvoller als die rechte (bspw. „Prozesse und Werkzeuge“). Natürlich darf die rechte Seite nicht zu weit in den Hintergrund rücken; bspw. lassen sich nicht alle Funktionen einer Software ohne Dokumentation nachvollziehen. Bei der Entwicklung von Lösungen ist also auch auf eine Ausgewogenheit der Werte-Paare zu achten.

In gewisser Weise beschreibt das Agile Manifest einen Verhaltenskodex, um Handlungen einer Entwicklung zu reflektieren und an definierten Prinzipien auszurichten. Darauf aufbauend liefert Scrum einen Rahmen, um die Arbeit gemeinschaftlich zu organisieren und erledigen.

Scrum Events

Sprint

Ein Leitmotiv von Scrum ist die Entwicklung von Produkten in kurzen Zyklen bzw. Inkrementen. Diese kurzen Zyklen werden Sprint genannt. Sie sind das Herz von Scrum. Wichtig ist, dass Sprints im gesamten Entwicklungsablauf eine konsistente Dauer haben. Beim Arbeiten mit parallelen Teams sollten Organisationen darauf achten, dass Sprints synchron verlaufen, so dass es nicht zu unnötigen Wartezeiten zwischen den Teams kommt. Trotz aller Offenheit für Neues, gilt es Änderungen innerhalb eines Sprints zu vermeiden, die das vereinbarte Sprint-Ziel gefährden. Das vereinbarte Sprint-Ziel ist eine Prämisse, die es gemeinsam zu erreichen gilt, so dass ein potenziell lieferfähiges Inkrement und damit eine Lösung entsteht,  die funktioniert und Kunden zur Verfügung gestellt werden könnte. Werden einzelne User Storys nicht umgesetzt, so wird der Sprint nicht verlängert, sondern die entsprechenden User Storys gegebenenfalls für einen der nächsten Sprints eingeplant. Die Anpassung von Qualitätszielen und Akzeptanzkriterien ist nicht vorgesehen, sollte jedoch das Sprint-Ziel obsolet werden, kann der Product Owner einen Sprint auch abbrechen.

Sprint Planung

Zu Beginn eines Sprints findet die Spint Planung – auf englisch: das Sprint Planning – statt. Es ist ein Treffen zur Planung der Anforderungen und Arbeitspakete, die im aktuellen Sprint umgesetzt werden sollen. Die Teilnahme ist für die Entwickler  verpflichtend. Organisiert wird das Meeting vom Product Owner, moderiert vom Scrum Master. Das Sprint Planning teilt sich in zwei Phasen auf:  Beim Sprint Planning 1 wird über das „Was“ gesprochen, also was soll im nächsten Sprint realisiert werden. Ein Sprint-Ziel wird vereinbart und die Entwickler verpflichten sich, die vereinbarten Anforderungen im nächsten Sprint umzusetzen. Beim Sprint Planning 2 einigen sich die Entwickler auf das „Wie“, also wie das Team die Anforderungen realisieren wird. Dazu definieren Sie Tasks und visualisieren diese mit einem Taskboard. Am Ende von Phase 2 sollte das Team in der Lage sein, dem Product Owner und dem Scrum Master zu erklären, wie er als selbstorganisierendes Team arbeiten will, um das Sprint-Ziel zu erreichen und das erwartete Inkrement zu erstellen.

Daily Scrum

Das Daily Scrum ist ein täglich stattfindendes Standup Meeting, zu dem sich das Entwicklungsteam trifft, um sich gegenseitig über den Fortschritt, die anstehenden Tätigkeiten und mögliche Probleme auszutauschen. Die Teilnahme an dem Meeting ist für das Entwicklungsteam verpflichtend, zusätzlich sollte der Scrum Master und könnte der Product Owner teilnehmen. Beim Daily Scrum soll jedes Teammitglied drei Fragen – immer mit Bezug auf das Sprint-Ziel – beantworten:

  • Was habe ich seit gestern getan, um dem Entwicklungsteam zu helfen, dass Sprint-Ziel zu erreichen? 
  • Was mache ich bis morgen, um das Entwicklungsteam beim Erreichen des Sprint-Ziels zu unterstützen?
  • Was hindert mich oder das Entwicklungsteam daran, das Sprint-Ziel zu erreichen? 

Durch den Austausch synchronisiert sich das Team untereinander und Redundanzen werden vermieden.

Sprint Review

Das Sprint Review ist ein Treffen am Ende eines Sprints zur Beurteilung und Abnahme der erledigten Arbeit in Bezug auf das gesteckte Sprint-Ziel. Am Sprint Review nehmen das gesamte Entwicklungsteam – also die Entwickler, der Scrum Master und der Product Owner – teil. Auch ausgewählte Stakeholder – Personen oder Gruppen mit einem Interesse an den Sprintergebnissen – also bspw. Anwender, Manager, Vertreter aus Bereichen wie Marketing, Vertrieb oder IT können teilnehmen.

Beim Sprint Review wird sichtbar, was im Sprint erarbeitet wurde und welche User Storys freigegeben werden. Da nur realisierte User Storys und deren Umsetzung live im Produkt präsentiert werden dürfen, ist der Fortschritt der Entwicklung für alle Beteiligten direkt ersichtlich. Durch die Teilnahme von Stakeholdern können diese direktes Feedback und somit Kritik, Lob und Verbesserungsvorschläge äußern, die gegebenenfalls vom Product Owner für den nächsten Sprint eingeplant werden.

Retrospektive

Eine Retrospektive ist ein regelmäßiges Treffen, zu dem sich das Entwicklungsteam trifft, um die jüngere Vergangenheit – also den zurückliegenden Sprint – zu beleuchten und dadurch die zukünftige Zusammenarbeit im Team zu verbessern. Es ist ein Meeting, bei dem Prozesse, Werkzeuge, Fähigkeiten, Beziehungen, Herausforderungen und Erfahrungen reflektiert werden. Das Feedback bietet dabei Chancen sowohl für das Team als Ganzes als auch für jeden einzelnen Teilnehmer.

Ziele sind die Verbesserung der Zusammenarbeit im Team und somit die Verbesserung von Abläufen und Inhalten, sowie die Festlegung von Maßnahmen, von Dos und Don’ts, basierend auf  den gemeinsam gewonnen Erkenntnissen. Darüber hinaus bietet die Retrospektive Raum für offenes Feedback im Team und zur Überprüfung der vereinbarten Maßnahmen der vergangenen Retrospektive. In der Praxis gibt es eine große Anzahl von Möglichkeiten, die Restrospektiven abzuhalten und es empfiehlt sich auch, immer mal wieder die Vorgehensweise anzupassen, um so das Interesse am Austausch untereinander hoch zu halten.

Scrum Whitepaper Download

Jetzt das Scrum Whitepaper kostenlos downloaden.

Alles Wichtige über Scrum, die zentralen Begriffe, Rollen, Events und Herausforderungen auf 29 Seiten zum Mitnehmen.

Hier klicken »

Scrum Rollen

Product Owner

Der Product Owner ist neben dem Scrum Master und dem Entwicklungsteam eine der drei zentralen Rollen in Scrum. Er repräsentiert die Vorstellungen der Stakeholder, erstellt und pflegt das Product Backlog, und arbeitet eng mit dem Entwicklungsteam zusammen. Er legt das Projektziel fest und ist für den Erfolg der Entwicklung verantwortlich. Er steuert die Entwicklung über die Formulierung und Priorisierung von Epics, Features, Anforderungen und User Storys (die jedoch allesamt auch von Kollegen erfasst werden können). Er verantwortet Releases und Releasepläne, pflegt einen Kapazitätsplan und betreibt Risikomanagement. Er vereint somit Produkt- und Projektmanagementaufgaben.

Trotz seiner Verantwortung und seinen zahlreichen Aufgaben ist er aber nicht der Vorgesetzte des Entwicklungsteams. Er sollte sich weder in technische Lösungsdiskussionen oder die Schätzung von Aufwänden einmischen. Damit der Product Owner seine Rolle gut ausführen kann, muss er vom Management bevollmächtigt sein, um bspw. Entscheidungen bzgl. Anforderungen und Funktionsumfang treffen zu können. Darüber hinaus ist es wichtig, dass er sowohl fachlich als auch kommunikativ qualifiziert und stets verfügbar ist.

Scrum Master

Der Scrum Master trägt die Verantwortung für die Einhaltung des Scrum-Prozesses und dessen Implementierung im Unternehmen. Er moderiert die Scrum-Meetings, sorgt für die Einhaltung der vereinbarten Timebox, erfasst und beseitigt Impediments, und schützt das Team vor unberechtigten Eingriffen während der Entwicklung. Er fördert die Kommunikation zwischen Entwicklungsteam und Product Owner und behält dabei verschiedene Artefakte wie das Product und Sprint Backlog, Burndown Charts, Taskboards oder das User Story Mapping im Auge.

Im Rahmen der Retrospektive versucht er die Zusammenarbeit im und mit dem Team, sowie die gelebten Prozesse zu verbessern. Dort hat er auch Gelegenheit, Feedback zu seiner eigenen Tätigkeit zu erfragen. In seiner Rolle ist ein Scrum Master gleichzeitig Coach, Moderator und Vermittler. Seine Rolle sollte aber nicht mit einem Projektleiter verwechselt werden, denn das Entwicklungsteam organisiert sich selbst und kommuniziert auch direkt mit dem Product Owner. Eine Doppelfunktion als Product Owner oder Teammitglied sollte auf jeden Fall vermieden werden.

Entwicklungsteam

Ein Scrum Entwicklungsteam besteht aus 3 bis 9 Personen. Idealerweise werden Entwicklungsteams funktionsübergreifend zusammengestellt, so dass sie gemeinsam alle erforderlichen Fähigkeiten besitzen, um ein Inkrement am Ende des Sprints zu erstellen. Dabei muss das Team vor allem in der Lage sein, Architekturen zu entwerfen oder zu optimieren, sowie Software zu entwickeln und zu testen.

Unabhängig von den Fähigkeiten der einzelnen Mitglieder definiert Scrum keine zusätzlichen Rollen oder Titel für Teammitglieder. Damit betont Scrum die gemeinsame Verantwortung des Teams, ein potenziell lieferbares Inkrement zu liefern. Grundsätzlich gilt, dass Scrum Entwicklungsteams selbstorganisierend sind. Weder der Product Owner noch der Scrum Master sind dem Team vorgesetzt. Damit wird die Kommunikation im Zuge der verschiedenen Scrum Events um so wichtiger.

Scrum Artefakte

Backlogs

Die Verwaltung von Informationen in Backlogs ist in Scrum sehr populär. Ein Backlog ist eine Sammlung von Dingen, insbesondere unvollständiger Arbeit oder Angelegenheiten, die erledigt werden müssen. Oder einfach ausgedrückt: Ein Backlog ist eine Liste von Aufgaben bzw. Anforderungen, die abgearbeitet bzw. realisiert werden sollen.

Obwohl Scrum die Verwendung von Product Backlog und Sprint Backlog (neben dem Product Inkrement) als Artefakte definiert, ist die Organisation von Backlogs in Unternehmen unterschiedlich organisiert. So finden sich häufig  Release Backlogs und Team Backlogs. Beim Sprint Planning 1 definiert der Product Owner sein Selected Backlog als Wunschliste – die abgestimmten User Storys wandern anschließend in das Sprint Backlog oder werden entsprechend referenziert. Der Scrum Master pflegt in einem Impediment Backlog die Hindernisse, die im Zuge der Daily Scrums kommuniziert wurden. Darüber hinaus können Entwickler bzw. Mitarbeiter auch persönliche Backlogs pflegen. Generell ist die Pflege und Priorisierung der Backlog Items eine wichtige und kontinuierliche Aufgabe.

Inkrement

Wie im Scrum Guide beschrieben, ist ein Inkrement die Summe aller während eines Sprints abgeschlossenen Backlog Items und der Wert der Inkremente aller vorherigen Sprints. Am Ende eines Sprints muss das neue Inkrement „Done“ sein, d.h. es muss sich in einem brauchbaren Zustand befinden und der Definition of Done des Entwicklungsteams entsprechen. Darüber hinaus muss das Inkrement „potenziell lieferfähig“ sein, d.h. es muss funktionieren, es muss getestet sein, es muss sich in Betrieb nehmen lassen, es sollte dokumentiert sein und dem Anwender Mehrwerte bieten.

In der Praxis wird nicht jedes fertige Inkrement den Kunden zur Verfügung gestellt, da dies viele Kunden und ihre Organisationen überfordern könnte. Bei einer App, die sich automatisch im Hintergrund auf einem Handy aktualisiert, ist eine Lieferung pro Monat durchaus denkbar, bei einer Anwendung, die unternehmensweit mit mehreren 100 Anwendern betrieben wird, würde das ggf. zu viel Aufwand erzeugen. Hier sind Marketing und Vertrieb gefordert, eine sinnvolle Releasestrategie zu definieren.

Wollen Sie mehr über Scrum erfahren?

Dann erfahren Sie hier mehr über ScrumButs, die Verwendung von Story Points oder die Skalierung mit Scrum of Scrums.

Herausforderungen für Unternehmen

Mindset und Werte

Die Anzahl der Organisationen, die Scrum nutzen, wächst kontinuierlich. Unternehmen erhoffen sich mehr Flexibilität, schnellere Entwicklungszyklen oder niedrigere Kosten. Durch die Sprints, die Kommunikation zwischen Product Owner und Stakeholder und die gemeinsame Sprint Planung lässt sich die Flexibilität häufig steigern. Doch diese Flexibilität ist nicht kostenlos. Scrum erfordert regelmäßige Kommunikation zwischen den Beteiligten in Form von Daily Scrums, Sprint Planungen, Sprint Reviews, Retrospektiven und gegebenenfalls Scrum of Scrums. Hinzu kommt der Aufwand, Backlogs zu pflegen, Arbeitspakete zu definieren, Aufwände zu schätzen und den Fortschritt zu dokumentieren. In anderen Worten: Scrum ist keine Abkürzung zu Unternehmenserfolg. Technische Herausforderungen bleiben bestehen, sie lassen sich aber vermutlich im Laufe einer Entwicklung mit neuem Wissen besser beurteilen als zu Projektbeginn. Damit sinkt das Risiko falscher Projektpläne und Versprechungen.

Damit das Vorgehen funktioniert, müssen Organisationen aber nicht nur lernen, die Regeln von Scrum anzuwenden, und die Scrum Rollen mit geeigneten Mitarbeitern zu besetzen. Es ist notwendig, ein agiles Mindset zu entwickeln und die Scrum Werte mit Leben zu füllen. Das Management muss sich von einem Command-and-Control-Führungsstil lösen. Das Team muss lernen, mit Verantwortung umzugehen und sie bewusst in Anspruch zu nehmen. Der Product Owner muss verstehen, dass er nicht der Vorgesetzte des Entwicklungsteams ist. Und der Scrum Master darf sich nicht als Projektleiter verstehen. Es geht also um

  • Selbstverplichtung (das sogenannte Commitment),
  • Mut,
  • Offenheit,
  • Fokus und
  • Respekt.

Erst mit einem Mindset, das diese Werte lebt, entfaltet Scrum die größten Vorteile.

Gerne stellen wir Ihnen Wissen, Erfahrung und 100% Leidenschaft für Ihre Softwareentwicklung und Anforderungsanalyse zur Verfügung. Wir helfen Ihnen bei der Erhebung, Strukturierung und Verwaltung von Anforderungen und achten dabei auf Konsistenz, Vollständigkeit und Nachvollziehbarkeit. Wir stellen Ihnen ein agiles Projektteam aus sehr guten Softwarearchitekten und Softwareentwicklern zur Verfügung, das Ihre Anforderungen in kurzen Iterationen in enger Abstimmung mit Ihnen umsetzt. Unser Vorgehen basiert auf den agilen Methoden Scrum und Kanban und vereint diese mit den technischen Praktiken aus Extreme Programming (XP).

Hier erfahren Sie mehr zum Thema Softwareentwicklung »

Weitere Details und Hintergründe ...