Als Dozent an der TU-Berlin hat unser Geschäftsführer, Steffen Eßers, sein Wissen zur „Psychologie der agilen Entwicklung“ mit seinen Studenten geteilt. Hierbei sind Artikel entstanden, welche die Studenten in unserem Blog veröffentlichen.
Nachfolgend beschreibt Anica Kleinjan, was Scrum ist und welche Vor- und Nachteile damit in der agilen Entwicklung einhergehen.
Scrum
Scrum stellt heutzutage einen der bekanntesten agilen Prozesse dar. Gründe dafür sind, dass Scrum eine einfache Struktur hat und die einzelnen Rollen, die die beteiligten Personen einnehmen, klar definiert sind. Die Prinzipien lassen sich relativ schnell erlernen, produktiv einsetzen und die Vorteile von Agilität können so schnell ausgenutzt werden. Es ist anzumerken, dass Scrum keine Entwicklungsmethode (wie zum Beispiel Paarprogrammierung) ist, sondern mehr ein Management-Framework darstellt, welches vorgibt, wie Software-Projekte durchgeführt und geplant werden sollen.
Scrum wird durch drei Rollen, drei Artefakte und fünf Zeremonien definiert, welche ein Team in die Lage versetzen Funktionalitäten eines Produktes innerhalb von einer festgelegten Zeitspanne auszuliefern.
Im Folgenden sollen das Team und dessen Rollen, Artefakte und Zeremonien beschrieben werden.
Das Scrum-Team
Das Team setzt sich aus dem Entwicklerteam, dem Product Owner und dem Scrum Master zusammen. Diese drei Komponenten bilden die drei Rollen in Scrum. Wichtig ist, dass sich das Team selbst organisiert. Das heißt, dass das Team selbst bestimmt, welche Aufgaben als nächstes erledigt werden müssen und in welcher Form diese am besten erledigt werden ohne Vorgaben von Personen außerhalb des Teams (z.B. der Geschäftsführung) zu erhalten. Das Team ist außerdem interdisziplinär zusammengesetzt, sodass alle Kompetenzen, die für die Entwicklung des Produktes notwendig sind, im Team enthalten sind.
Scrum Teams liefern Produktinkremente, was den Vorteil bietet, dass immer ein funktionierendes Produkt vorliegt und bessere Möglichkeiten für Feedback bestehen.
Product Owner
Der Product Owner vertritt die fachliche Auftraggeberseite und stellt so die Verbindung zwischen dem Scrum Team und dem Kunden dar. Er gibt die Anforderungen und die strategische Richtung vor. Außerdem priorisiert er die Aufgaben, welche erledigt werden müssen. Diese werden dann in Absprache mit dem Entwicklerteam im sogenannten Product Backlog festgehalten und als User Stories erfasst. User Stories beschreiben eine Anforderung aus Sicht des Users und werden einfach formuliert. Der Product Owner ist für die Pflege des Backlogs verantwortlich und muss außerdem dafür sorgen, dass das Backlog für das gesamte Team einsehbar ist.
Entwicklerteam
Das Entwicklerteam ist für die technische Umsetzung, der im Product Backlog festgelegten Anforderungen und Funktionalitäten zuständig. Dabei hat das Team mehr Entscheidungsfreiheiten als Programmierer in traditionellen Softwareentwicklungsprojekten. Das Team organisiert seine Arbeit selbst und übernimmt die Verantwortung als Team. Das heißt, dass sowohl gute als auch schlechte Ergebnisse auf das ganze Team bezogen werden und nicht auf einzelne Teammitglieder.
Scrum Master
Der Scrum Master ist Coach und Moderator des Scrum Teams. Er ist dafür zuständig, dass Scrum funktioniert. Wichtig ist hier, dass der Scrum Master keine Führungspersönlichkeit darstellt, sondern lediglich unterstützend wirkt. Er führt Scrum ein und sorgt dafür, dass Scrum-Regeln eingehalten werden. Außerdem moderiert er alle anfallenden Meetings und ist für die Beseitigung von Störungen und Hindernissen zuständig. Dieses können Kommunikationsprobleme und Konflikte innerhalb des Entwicklerteams oder zwischen dem Entwicklerteam und dem Product Owner sein. Er schützt das Team außerdem vor externen Störungen und hilft Personen außerhalb des Teams zu verstehen, welche Interaktionen mit dem Scrum Team sinnvoll sind.
Der Prozess
Der Prozess besteht aus fünf Zeremonien. Der Sprint Planung, dem Daily Scrum, dem Sprint Review, der Sprint Retrospektive und dem Sprint selbst. In Abbildung 1 ist der Scrum Prozess dargestellt.
Abbildung 1 Scrum Prozess
Sprint
Der Sprint ist ein festgelegter Zeitrahmen (in der Regel zwei oder vier Wochen), in dem ein Produktinkrement entwickelt wird. Nach jedem Sprint wird ein funktionsfähiges Produktinkrement fertiggestellt und ausgeliefert.
Spint Planung
Jeder Sprint beginnt mit einem Meeting in dem der jeweilige Sprint geplant wird. Hier trifft sich das gesamte Entwicklerteam, der Product Owner und der Scrum Master um das Ziel des bevorstehenden Sprints zu definieren. Das Sprint Ziel beschreibt kurz und bündig das zu erzielende Produktinkrement. Dabei diskutiert das Team mit dem Product Owner die am höchsten priorisierten User Stories und nimmt sich dann so viele User Stories, wie es annimmt, bearbeiten zu können. Das Team entscheidet selbst, wie viele User Stories es in der Zeit bearbeiten kann (Pull-Prinzip). Die Liste mit den zu bearbeitenden Aufgaben wird im sogenannten Sprint Backlog festgehalten. Anschließend wird besprochen, wie das Sprint Ziel technisch erreicht werden kann.
Daily Scrum
Das Daily Scrum ist ein Meeting, welches während des Sprints einmal täglich stattfindet. Das Meeting dauert in der Regel 15 Minuten, findet immer am selben Ort zur gleichen Zeit statt und wird im Stehen durchgeführt. Am Ende des Daily Scrums sollte jedes Teammitglied verstanden haben, wie weit das Team in der Erreichung des Sprint Ziels ist, wo Probleme liegen und was noch zu tun ist. Dazu beantwortet jedes Teammitglied kurz was es seit dem letzten Meeting gemacht hat, was es heute machen wird und wo Probleme aufgetreten sind.
Sprint Review
Das Sprint Review erfolgt am Ende eines Sprints. Hier stellt das Team die neue Software, also das neue Produktikrement vor. Im Sprint Review sind auch die Kunden anwesend, welche Feedback geben können. Es werden Produktverbesserungen entwickelt, die dann in das Backlog und in die Sprint Planung einfließen können.
Sprint Retrospektive
Neben dem Sprint Review findet nach jedem Sprint die Sprint Retrospektive statt. Es treffen sich der Scrum Master, der Product Owner und das Entwicklerteam, um den Sprint zu reflektieren. Es werden positive und negative Erkenntnisse zusammengetragen, um daraus Verbesserungen für den kommenden Sprint abzuleiten. Es geht hierbei nicht darum das Produkt, sondern den Arbeitsprozess zu verbessern.
Artefakte
Scrum definiert drei Artefakte. Das Product Backlog, das Sprint Backlog und das Produktinkrement.
Product Backlog
Das Product Backlog enthält die vollständige Auflistung von priorisierten Anforderungen an ein Produkt. Es ist dynamisch anpassbar und auch die Priorisierung der Anforderungen kann sich im Laufe des Projektes ändern. Die Anforderungen werden in Form von User Stories formuliert, welche die Anforderungen an das zu entwickelnde Feature in kurzer Form aus Sicht des Nutzers beschreiben. Die User Story wird detaillierter beschrieben, je näher sie vor der Umsetzung steht. Nach jedem Sprint kann das Product Backlog angepasst werden, wenn sich beispielsweise im Sprint Review neue Anforderungen ergeben. Das Product Backlog wird vom Product Owner gepflegt und ist für alle Teilnehmer einsehbar.
Sprint Backlog
Im Sprint Backlog sind alle Aufgaben festgehalten, die erledigt werden müssen, um das jeweilige Sprintziel zu erreichen. Hier wird der Arbeitsaufwand für die einzelnen Tasks festgesetzt. Die Liste wird permanent von den Team Mitgliedern gepflegt, sodass Transparenz über den aktuellen Bearbeitungszustand bewahrt wird. So ist es für den Scrum Master einfacher zu erkennen, ob er eingreifen muss, damit das Sprint Ziel nicht gefährdet wird.
Produktinkrement
Jeder Sprint produziert ein Produkt Inkrement. Das Produkt Inkrement ist das Ergebnis aus dem abgeschlossenen Sprint und den Erzeugnissen aus allen vorherigen Sprints. Es muss funktionsfähig sein, sodass es an den Nutzer gegeben werden kann.
9 Vorteile von Scrum
- Kurze Kommunikationswege
- Ausgeprägter Team-Gedanke
- Höhere Effektivität und Motivation durch Selbstorganisation
- Hohe Transparenz durch regelmäßige Meetings und die Backlogs
- Kontinuierlicher Verbesserungsprozess durch Retrospektive und Review
- Kurzfristige Problem-Identifikation
- Geringer Administrations- und Dokumentationsaufwand
- Frühzeitige Ergebnisse
- Es kann besser auf den sich ändernden Markt reagiert werden
6 Limitationen von Scrum
- Kein Überblick über die gesamte Projektstrecke
- Scrum ist zwar einfach, aber dadurch an vielen Stellen unklar
- Die Koordination mehrerer Scrum Teams kann komplex sein
- Potenzielle Verunsicherung, weil Zuständigkeiten und Hierarchien fehlen
- Scrum ist nicht immer vereinbar mit bestehenden Unternehmensstrukturen
- Zeitverluste bei zu defensiver Sprintplanung
Zusammenfassung zu Scrum
Scrum ist eine Methode um Softwareprojekte zu managen und durchzuführen. Es werden klare Rollen definiert, ein einfach zu verstehender Prozessablauf verfolgt und wenige Regeln festgelegt. Scrum bietet viele Vorteile, insbesondere wenn das Projektziel nicht von Anfang an klar ist und sich die Anforderungen während des Projektes stetig ändern können. Unter der Anwendung von Scrum bleibt das Team in der Lage flexibel auf Änderungen zu reagieren. Außerdem wird eine höhere Motivation der Teammitglieder erreicht, dadurch dass sich das Team selbst organisieren kann. So kann eine höhere Effektivität erreicht werden.
Nichtsdestotrotz gibt es auch Limitationen, die Scrum aufweist. So ist es schwierig Scrum in bereits bestehende Unternehmensstrukturen einzuführen, in denen die Führungsebene Anweisungen gibt und Entscheidungen trifft. Zum Einen ist es nicht einfach für die Führungsebene Verantwortung abzugeben und zum Anderen kann die Selbstverantwortung bei den Teammitgliedern zu Verunsicherung führen.
Zusammenfassend stellt Scrum für einige Softwareprojekte eine gute Lösung dar und bietet die Möglichkeit agil auf Projektänderungen zu reagieren. Es sollte jedoch gut überlegt sein, ob Scrum für das entsprechende Projekt sinnvoll ist. Scrum sollte nicht eingesetzt werden, wenn das gewählte Entwicklungsziel nicht in Teilziele herunter gebrochen werden kann, die sich in iterativer Form lösen lassen. Außerdem muss das Team hinter der Entwicklungsweise von Scrum stehen und Vertrauen in sich selbst haben. Die Teammitglieder sollten kommunikativ, teamfähig, selbstbewusst und in der Lage sein, sich selbst zu organisieren. Außerdem muss der Kunde akzeptieren, dass er keinen Überblick über die gesamte Projektstrecke hat.
Quellen
- http://www.contentmanager.de/cms/portalmanagement/scrum-ist-nicht-planlos/
- https://improuv.com/scrum/methode/was-ist-scrum
- http://www.computerwoche.de/a/scrum-das-rahmenwerk,2352556
- http://www.scrumguides.org/scrum-guide.html
- http://scrum-fibel.de/artefakte/sprint%20backlog.html
- http://agiles-projektmanagement.org/scrum-voraussetzungen/
Danke an Wikipedia für die Scrum Prozess Grafik.
apliki.wordpress.com 
Hallo Anica, lieben Dank für deinen interessanten Artikel zu Scrum! Ich finde, du hast mit wenigen Worten das Konzept von Scrum sehr schön und verständlich beschrieben.
Auch dank der Struktur des Artikels und der Visualisierung des Scrum-Prozesses fiel es mir sehr leicht, dem Text zu folgen und die Ansätze von Scrum zu verstehen.
Wenn ich mal die Sicht eines Kundens einnehme, sehe ich persönlich den größten Vorteil in der Flexibilität von Scrum – meist hat der Kunde ja auch nach Unterzeichnung des Pflichten- und Lastenheft noch viele Änderungswünsche, die sich während des Projekts ergeben. Hier kann dank Scrum sehr flexibel reagiert werden.
Dennoch stelle ich es mir gleichzeitig als Kunde schwierig vor, eine Zusammenarbeit ohne klar kommunizierte Deadline und festes Budget aufzubauen. Gerade auch, weil Kunden oft wiederum mit anderen Dienstleistern zusammenarbeiten müssen und dadurch viele Abhängigkeiten entstehen. Ich kann mir gut vorstellen, dass aus Sicht eines Kunden sich hier der größte Nachteil von Scrum verbirgt.
Hallo Anica, Vielen Dank für deinen Blogeintrag.
Ich finde dein Beitrag sehr übersichtlich und gut strukturiert. Kurz und informativ.
Besonders gefällt mir die Grafik über den Prozess und die Übersicht über Vorteile und Limitationen.
Vllt hättest du noch Ergebnisse aus der Praxis mit einbauen können. Ich hatte mal eine Studie gelesen wobei Scrum in einem studentischen Labor getestet wurde. Dabei wurde an den einzelnen Phasen genau beschreiben wo Probleme, welche Art auftreten können. Z.B. wurde die Überbeanspruchung des Product Owners anschaulich dargestellt. Außerdem wurde in der Studie beobachtet, dass die selbstständige Auswahl der Aufgaben durch Mini-Teams mit heterogenen Entwicklern dazu führen kann, dass unerfahrene Entwickler sich mit hochkomplexen Aufgaben überfordern. Als Tipp für die Einführung von Scrum könnte man festhalten, dass am Anfang schon darauf geachtet werden sollte, wer sich welche Aufgaben annimmt. Vllt muss auf ein System zur koordinierten Aufgabenverteilung, Bsp. während der Sprintsizuungen hingewiesen werden.
Allerdings handelte es sich ja bei dem Experiment um unerfahrene Entwickler im Scrum. Und diese Probleme müssen lediglich beim Einführungsprozess bedacht werden. Die Problematik und Schwierigkeiten des Einführungsprozesses hast du gut herausgestellt.
Vielen Dank dafür.
Lg Betti
Hallo Anica,
vielen Dank für deinen informativen und sehr verständlichen Blogeintrag. Ich finde du hast das Konzept Scrum kurz und prägnant wiedergegeben. Als Entwicklerin, die bereits seit drei Jahren mit Scrum arbeitet, hat mir in deiner Ausführung nichts gefehlt.
Drei Punkte, die ich gerne noch erweitern bzw. ergänzen würde:
Scrum ist zwar als Konzept durchaus übersichtlich, aber wie die Erfahrung in der Praxis zeigt, ist am Ende nicht das theoretische Wissen über das Konzept und deren Anwendung erfolgsentscheidend, sondern Scrum muss von allen Beteiligten gelebt werden. Das Konzept ist nur dann maximal erfolgreich, wenn das Team den Prozess wirklich verinnerlicht hat und sich mit der Arbeitsweise identifizieren kann und es eine „Lebenseinstellung“ wird.
Es darf unter keinem Umständen unterschätzt werden, wie wichtig und entscheidend die Formulierung der User Stories ist – hiermit fällt und steht die ganze Entwicklung und Zielerreichung. Es ist nicht leicht in einfachen Worten den Mehrwert, die genaue Abgrenzung (Entwickler schießen gerne mal übers Ziel hinaus) und die genauen Zielkriterien zu definieren.
Und schließlich bin ich der Meinung, dass es kein Entwicklungsziel geben kann, welches man nicht in kleine Teilziele herunterbrechen kann. Es ist bestimmt durchaus schwierig, in der typischen hierarchischen Struktur Scrum einzuführen, aber ich kann mir nicht vorstellen, dass es an der Unzerteilbarkeit des Produktes liegt. Am Ende kann ein Produkt auch mit Scrum-Methoden entwickelt werden, aber erst nach der x-ten Iteration an den Kunden ausgeliefert werden, wenn der Kunde sich mit iterativen Erweiterungen nun so gar nicht anfreunden kann.
LG Steffi