Scrum – Agil in Sprints arbeiten

Wer sich mit Agilen Methoden beschäftigt, der wird schnell auf die SCRUM Methode stoßen. Anfangs als Handlungsrahmen für agile Softwareentwicklung entwickelt, in der ein Entwicklerteam eigenverantwortlich und ohne Projektleiter agieren kann, findet SCRUM heute Anwendung in weiteren Gebieten von der Prozessoptimierung bis hin zur Organisationsentwicklung und Change Management.

Was ist Scrum?

Im Kern bietet Scrum einen Rahmen, um komplexe Produkte innerhalb eines eigenständigen Teams entwickeln zu können. Hierzu wird das Produkt in seine Eigenschaften aufgeschlüsselt, die dann Stück für Stück durch das Scrum-Team erarbeitet werden. Dabei werden dem Team nur Eigenschaften vorgegeben, die das fertige Teilprodukt haben soll – der Lösungsweg bleibt dem Team selbst überlassen. Die Zyklen, in denen diese Arbeit geschieht, heißen Sprints. Nach jedem Sprint wird dem Produktverantwortlichen – dem Product Owner – das Arbeitsergebnis vorgestellt.

Ein Beispiel: Um ein Dashboard für die Wirkung von Marketing-Maßnahmen zu entwickeln, können verschiedene Teilaufgaben identifiziert werden. Zunächst müssen geeignete Datenquellen identifiziert und per Schnittstelle verfügbar gemacht werden. Anschließend müssen geeignete Analyseverfahren angewendet werden, um verschiedene Kennzahlen zu erhalten. Das können die Conversion Rate, die Retourenquote, die Bounce Rate und die Daily Visits sein. Die Ergebnisse müssen grafisch aufbereitet werden, so dass sie für den Anwender aufschlussreich sind. Anschließend kann das Dashboard implementiert werden.

Im klassischen Projektmanagement wird sich ein Projektleiter hinsetzen, einen Projektplan und vielleicht ein Pflichtenheft mit detaillierter Auflistung aller Funktionen und Eigenschaften des Dashboards verfassen und Milestones definieren. Wahrscheinlich wird er sogar jeweils definieren, wie die einzelnen Arbeitsschritte auszuführen sind. Dann wird er ein Team zusammenstellen und in mehr oder weniger langer Zeit zu einem Ergebnis kommen. Diese klassische Methode wird im Scrum-Umfeld etwas herablassend als “Wasserfall-Methode” bezeichnet, da Informationen, Anweisungen und Umsetzung strikt ihrem Weg von oben nach unten folgen.

Im Scrum hingegen werden dem Team in einzelnen Sprints jeweils Teilaufgaben überlassen, deren Ergebnis und Lösungsansatz – also das wie – nicht exakt definiert ist. Vielmehr ist definiert, was das Ergebnis dieser Aufgabe sein soll. Das Team wird seine Erfahrung einsetzen, um das jeweilige Ziel auf bestmögliche Art und Weise zu erreichen. Vermutlich wird das Team auf Hindernisse stoßen – vielleicht sind bestimmte Werte nicht in der Datenbasis zu finden oder haben eine geringe Aussagekraft. Diese Erkenntnisse können dann im jeweils folgenden Sprint berücksichtigt werden, ohne dass es zu einer Verzögerung des gesamten Projektes kommt. Dieses Vorgehen wird als iterativ bezeichnet. In jedem Sprint wird das Produkt also iterativ weiterentwickelt.

Die Aufgaben werden dabei aus Sicht des späteren Anwenders als User Story verfasst, um dem Team bestmögliche Einsichten in der Verwendungszweck zu geben:

Als Marketing-Manager möchte ich die Daily Visits und die Conversion-Rate einsehen können, um die Wirksamkeit meiner AdWords-Kampagne tracken zu können.

Beispiel für eine User-Story

Um allen Beteiligten die bestmöglichen Rahmenbedingungen zu bieten, ist der genaue Ablauf der Arbeit im Scrum Team sehr genau definiert. Dies hilft auch “klassischen” Projektbeteiligten, sich schnell im agilen Arbeitsumfeld des Scrum-Teams zurecht zu finden. Zur Definition gehören die Rollen des Scrum-Teams sowie die Termine, die sich von Sprint zu Sprint jeweils wiederholen.

Die Rollen im Scrum-Team

Folgende 3 Rollen sind im Scrum-Team unverzichtbar:

Der Product-Owner

Der Product-Owner ist die Person, die im Unternehmen Verantwortung für das Produkt und dessen Wertschöpfung trägt. Im Scrum Team ist er (und NUR er) derjenige, der Aufgaben als User-Stories formuliert und diese in das Backlog sortiert. Das Backlog ist eine Sammlung der Anforderungen und Aufgaben, die das Team zu bearbeiten hat. Die Sortierung des Backlog obliegt ebenfalls dem Product-Owner. Das Team zieht die User-Story mit der höchsten Priorität immer zuerst aus dem Backlog.

Der Product-Owner ist eine einzelne Person. Das Scrum-Team empfängt Arbeitsaufträge ausschließlich von dieser Person.

Das Entwicklerteam

Das Entwicklerteam besteht aus Fachleuten, die in der Lage sind, die gestellten Aufgaben aus eigener Kraft zu bearbeiten. Ausschließlich das Entwicklerteam bearbeitet die als User-Stories gestellten Aufgaben. Am Ende des Sprints übergibt das Entwicklerteam dem Product-Owner ein fertiges Teilprodukt, das Inkrement genannt wird.

Das Entwicklerteam ist selbstorganisiert und entscheidet eigenständig, welche Arbeitsschritte zur Erledigung der jeweiligen Aufgabe notwendig sind. Das Entwicklerteam ist interdisziplinär und verfügt über alle notwendigen Fähigkeiten. Innerhalb des Entwicklerteams gibt es keine vorgeschriebene Hierarchie und keine fest zugewiesenen Aufgaben. Das Team als Ganzes ist verantwortlich für alle Arbeitsergebnisse – auch wenn einzelne Spezialisten naturgemäß bestimmte Aufgaben übernehmen.

Für die Größe des Entwicklerteams gilt, dass es nicht weniger als drei und nicht mehr als neun Personen umfassen sollte. Bei größeren Teams wird die Administration und Koordination zu komplex. Bei kleineren Teams entsteht zu wenig Interaktion, um die Produktivität zu realisieren.

Der Scrum-Master

Der Scrum-Master sorgt dafür, dass die Regeln und Prinzipien der Scrum-Methode eingehalten werden. Außerdem hilft der Scrum-Master dem Team auf methodische Weise (nicht inhaltlich) dabei, das beste Ergebnis zu erzielen. Der Scrum-Master ist dabei der Diener zweier Herren, denn er spielt für den Product-Owner wie auch für das Entwicklerteam eine jeweils gewichtige Rolle.

Gegenüber dem Product-Owner tritt der Scrum-Master als Berater auf. Er hilft, das Verständnis für Scrum und agiles Arbeiten zu schärfen und geeignete Formulierungen für die User-Stories zu wählen. Bei Scrum-Events (siehe unten) tritt er als Moderator auf und unterstützt den Product-Owner bei der effektiven Durchführung.

Gegenüber dem Entwicklerteam gilt der Scrum-Master zunächst einmal als Coach für Selbstorganisation und hilft bei der konfliktfreien und zielgerichteten Bearbeitung der Aufgaben. Besonders in Organisationen, in denen Scrum neu eingeführt oder bis dato nicht richtig verstanden wurde, ist er somit absolut unverzichtbar für die Implementierung der Methode. In einem späteren Reifegrad des Teams beschränkt sich seine Aufgabe dann primär darauf, Hindernisse für das Team zu identifizieren und zu beseitigen und das Team innerhalb der Scrum-Events zu unterstützen.

Ein guter Scrum-Master verfügt über eine Vielzahl an Methoden, um Entscheidungen innerhalb des Teams konfliktfrei herbeizuführen. Er erkennt, wenn das Team Hilfe braucht oder sich in eine gedankliche Sackgasse manövriert hat. Er ist Fan der Scrum-Methode und führt einem neuen Team die Sinnhaftigkeit der Methode vor Augen. Er moderiert Scrum Events wie die Retrospektive und nutzt diese Gelegenheit, um (verdeckte) Konflikte zu identifizieren und zu schärfen. Er ist Moderator, Coach und Vertrauensperson.

Die Scrum-Events

Innerhalb der Scrum-Methode sind verschiedene Events vorgeschrieben, die jeweils ihren eigenen, bestimmten Zweck verfolgen. Das Ziel dieser fixen Events ist es, weitere Termine auf ein Minimum zu reduzieren und eine regelmäßige Verlässlichkeit herzustellen. Alle Events sind mit einem begrenzten Zeitfenster versehen – der sogenannten Time Box.

Der Sprint

Kern der Scrum-Methode ist der Sprint. Das maximale Zeitfenster für einen Sprint beträgt einen Monat. Diese Begrenzung stellt sicher, dass eine regelmäßige Überprüfung und Anpassung stattfindet – zum Beispiel auf geänderte Rahmenbedingungen oder neue Erkenntnisse.

Innerhalb der Sprint-Dauer soll das Entwicklerteam ein einsatzfähiges Teilprodukt erzeugen. Wie beschrieben kann das eine Funktion innerhalb einer Software, ein Prozess oder auch ein Design sein. Die User-Stories und die Definition of Done – (“wann gilt die Aufgabe als erfüllt”) – werden während der Laufzeit des Sprints nicht verändert.

Innerhalb des Sprints laufen auch die anderen Scrum-Events ab.

Das Sprint-Planning

Im Sprint-Planning wird der nächste Sprint durch das Scrum-Team gemeinschaftlich geplant. Für einen Sprint mit der Dauer eines Monats gilt ein Zeitfenster von 8 Stunden für das Planning. Bei kürzeren Sprints verkürzt sich üblicherweise auch das Planning.

Im Planning sollen Antworten auf die beiden zentralen Fragen gefunden werden:

  • Was kann im nächsten Sprint bearbeitet und fertiggestellt werden?
    Der Product-Owner erklärt dem Entwicklerteam, welches Teilprodukt im neuen Sprint erstellt werden soll und welche User-Stories im Backlog dazu abgearbeitet werden sollen. Somit definiert er ein Sprint-Ziel, das dem Entwicklerteam zu besserem Veerständnis verhilft. Das gesamte Scrum-Team (inkl. Product-Owner) entwickelt nun ein gemeinsames Verständnis zu den Inhalten. Das Entwicklerteam entscheidet anschließend, welche Elemente aus dem Backlog es im kommenden Sprint bearbeiten kann. Grundlage für diese Schätzung sind die Erfahrungen aus den zurückliegenden Sprints, die verfügbaren Kapazitäten und der aktuelle Zwischenstand des Produktes.
  • Wie wird die Arbeit erledigt?
    Die Elemente des Backlog, die das Entwicklerteam zur Bearbeitung ausgewählt hat, werden in kleinere Einheiten und Teilaufgaben zerlegt. Idealerweise haben die einzelnen Elemente einen Arbeitsaufwand von einem Tag oder weniger und sind durch einzelne Personen oder kleine Gruppen zu erledigen. Dieses “Schneiden der Tasks” ist besonders für die ersten Tage des neuen Sprints relevant, die somit gut geplant sind. Ist der Anfang ersteinmal gefunden, ergeben sich oft weitere Tasks, die in der Folge zu bearbeiten sind. Die Anwesenheit des Product-Owners ist hierbei sehr hilfreich – denn häufig tauchen bei diesem Arbeitsschritt Verständnisfragen und Bedarf nach Richtungsentscheidungen auf. Der Product-Owner kann im Planning durchaus Kompromisse eingehen, wenn berechtigte Gründe hierfür durch das Entwicklerteam aufgebracht werden.

Das Daily-Scrum

Das Daily-Scrum ist eine tägliche Routine von 15 Minuten, in der das Entwicklerteam sich zum aktuellen Stand der Arbeit austauscht. In der Regel sollte es morgens stattfinden. Das Daily-Scrum sorgt für Synchronität zwischen den einzelnen Teammitgliedern. Häufig arbeiten mehrere Personen des Entwicklerteams an den gleichen Teilaufgaben – sie werden sinnvollerweise nach dem Daily Scrum ihre gemeinsame Arbeit aufnehmen oder spezifische Fragestellungen diskutieren, bevor sie an ihrer Umsetzung weiterarbeiten.

Das Daily macht vielfach Termine zwischen einzelnen Teammitgliedern überflüssig und bringt alle Teammitglieder auf aktuellen Stand. Der Scrum-Master achtet daher streng darauf, dass ein Daily-Scrum stattfindet und dass die Teammitglieder in der Lage sind, die Timebox von 15 Minuten einzuhalten.

Jedes Teammitglied gibt Antworten auf die folgenden Fragen:

  • Welchen Beitrag habe ich gestern geleistet, um das Sprint-Ziel zu erreichen?
  • Was werde ich heute tun, um das Sprint-Ziel zu erreichen?
  • Welche Hindernisse (Impediments) sehe ich, die das Sprint-Ziel gefährden könnten?

Das Sprint-Review

Am Ende des Sprints wird dem Product-Owner und ggf. relevanten Stakeholdern Einblick in die Arbeitsergebnisse gegeben, um das Produkt zu überprüfen. Dazu werden die Ergebnisse präsentiert und die erreichte Funktionalität demonstriert. Das Team berichtet außerdem von Hindernissen, und wie diese überwunden wurden. Auf Basis der Erkenntnisse aus dem Review wird das Backlog angepasst, wenn nötig. Der Product-Owner erklärt sodann dem Scrum-Team, welche der Backlog-Einträge nun “done” sind, also als erledigt betrachtet werden können. Darauf basierend werden die nächsten Schritte diskutiert. Die Frage muss dabei immer sein, welche Arbeitsschritte und Funktionalitäten die höchste Wertschöpfung versprechen.

Ein guter Product-Owner wird im Review aktiv Feedback aus dem Entwicklerteam einholen und die Erkenntnisse gewinnbringend in die weitere Vorgehensweise einfließen lassen.

Die Sprint-Retrospektive (Retro)

Nach dem Sprint-Review und vor dem Sprint-Planning des kommenden Sprints findet die Sprint-Retrospektive statt. Sie ist für das Scrum-Team die Gelegenheit, den Blick zurück zu werfen, aus den gemachten Erfahrungen zu lernen und sich als Team weiterzuentwickeln.

In der Retro hängt viel von der Qualität des Scrum-Masters und seines Fähigkeiten als Coach ab. Neben der Frage, welche guten und schlechten Erfahrungen gemacht wurden, geht es vornehmlich um die Zusammenarbeit, die Beziehungen zwischen den Teammitgliedern und Hindernisse in der Zusammenarbeit. Der Scrum-Master ist hier gefordert, indem er geeignete Methoden anwendet, um das Scrum-Team aus der Reserve zu locken.

Je nach Reifegrad des Teams können Konflikte offen adressiert werden, die sonst eher verdeckt ausgetragen werden. Der Produktivität des Teams hilft der offene Umgang mit kritischen Themen ungemein weiter. Das Ziel der Retro ist es, konkrete Verbesserungsmöglichkeiten zu identifizieren und für diese Verbesserungen verantwortliche Personen zu identifizieren.

Anmerkungen aus der Praxis

Aus meiner Sicht ist Scrum eine wertvolle Methode, um klassisches Projektmanagement zu überwinden. Wenn Scrum gut gemacht wird, legt die Methode einen Großteil der Verantwortung in die Hände des Entwicklerteams, was auf die beteiligten Personen ungemein motivierend wirkt. Die Anwendung ist auch für Bereiche fernab der IT-Entwicklung und Programmierung bestens geeignet um diesen Effekt zu erzielen.

Besonderes Augenmerk muss jedoch auf die saubere Implementierung der Methode gelenkt werden. Personen, die neu im Scrum-Umfeld arbeiten, tendieren dazu, einzelne Scrum-Events (insbes. Daily und Retro) nicht für voll zu nehmen oder gar als überflüssig abzutun. Das liegt in der Regel daran, dass diese Termine durch mangelnde Fähigkeiten der Scrum-Master oder zu wenig Vorarbeit bei der Befähigung des Entwicklerteams nicht gewinnbringend ablaufen. Dabei liegt doch in diesen beiden Terminen der Schlüssel zur Teamentwicklung und bestmöglichen Zusammenarbeit. Als sehr sinnvoll hat es sich erwiesen, mehrere Personen in das Entwicklerteam zu integrieren, die bereits Erfahrungen mit der Scrum-Methode gesammelt haben.

Ebenfalls ein kritischer Faktor ist der Product-Owner. Häufig wird der Abteilungsleiter oder der ehemalige Projektleiter mit dieser Aufgabe betraut. Der gute Product-Owner hat aber wenig mit diesen beiden Rollen gemeinsam – er ist vielmehr gleichberechtigter Teil des Scrum-Teams. Natürlich – er entscheidet, ob Aufgaben erledigt wurden oder eben nicht. Dafür trägt er aber auch die alleinige Verantwortung für die Wertschöpfung seines Produktes. Die Frage ist immer, ob der Product-Owner wirklich der Eigentümer des Produktes ist. Es gibt Stimmen, die sagen, dass der Product-Owner befähigt sein muss, das Produkt auf eigene Verantwortung einzustellen oder maßgeblich zu verändern. Ansonsten ist er nicht der Owner sondern lediglich der verlängerte Arm eines Dritten. Dies ist keine günstige Voraussetzung für das Gelingen der Scrum-Methode, wo viel von der direkten Entscheidungsfähigkeit des Product-Owners abhängt. Das Entwicklerteam merkt schnell, ob der Product-Owner wirklich entscheidungsfähig ist oder sich ständig bei dritten Personen rückversichern muss.

Kritisch sind aus meiner Sicht außerdem externe Abhängigkeiten des Teams. Je komplexer das Arbeitsumfeld ist, desto schwieriger wird es, die Methode in ihrer ursprünglichen Form beizubehalten. Die Koordination mehrerer, parallel laufender Scrum-Teams mit wechselseitigen Abhängigkeiten stellt eine Organisation vor große Herausforderungen.

Noch mehr Infos zu Scrum sowie das offizielle Scrum-Guide findest Du hier bei den Kollegen von Scrumguides.org.