3. Scrum

3.1 Grundlagen und Geschichte

Dieses Kapitel führt in die laut Hammerstein (Hammerstein 2009, S. 29) am weitesten verbreitete agile Methodik Scrum ein und beantwortet die Frage nach dessen Herkunft.

Der Begriff Scrum ist weder eine Abkürzung, noch ist es ein Akronym, sondern stammt aus dem Sport Rugby und betitelt eine Standardsituation zur Wiederaufnahme des Spiels, in der sich eine bestimmte Anzahl an Mitspielern beider Mannschaften in einer Art Gedränge dicht gegenübersteht, um durch wegschieben der jeweils anderen Mannschaft in den Ballbesitz zu kommen. In dieser Situation kann sich eine Mannschaft nur dann den Ballbesitz erkämpfen, wenn sie erfolgreich zusammenarbeitet. (Mitchell et al. 2006, S. 190; Schwaber und Beedle 2002, S. 121–122)

Auch wenn zunächst Extreme Programming ein gewisse Verbreitung fand, sieht Seibert (2007, S. 41–42) Scrum als repräsentatives Beispiel für agile Methodiken. Gloger (2010, S. 195) geht noch einen Schritt weiter und bezeichnet Scrum als De-Facto-Standard der agilen Softwareentwicklung. Den Grund dafür sehen beide darin, dass, während Extreme Programming klare Vorgaben zur Entwicklung macht, Scrum eher auf das Management ausgerichtet ist. Bestätigt wird dies auch durch das Ergebnis einer Studie (Wolf und Roock 2008, S. 10), wonach zwar Extreme Programming unter den Befragten mit 93 Prozent eine höhere Bekanntheit genießt als Scrum mit 74 Prozent, was aber den erfolgreichen Einsatz betrifft mit 14 Prozent deutlich hinter Scrum liegt, das mit 21 Prozent die am häufigsten erfolgreich eingesetzte agile Methodik unter den Befragten ist.

Das erste Mal wurde Scrum 1993 unter Anleitung von Ken Schwaber eingesetzt, nachdem dieser den CEO der Easel Corporation von den Vorteilen dieser Methodik überzeugte. Das Resultat war nicht nur ein Produkt mit allen zum Schluss gewollten (und nicht ursprünglich gedachten) Funktionalitäten, sondern auch, dass ein von diesem CEO verantworteten Projekt termingerecht zum erfolgreichen Abschluss gebracht werden konnte. (Sutherland 2004, S. 1–3)

Bild 4 Grafische Darstellung der Scrum Prozesse

Quelle: In Anlehnung an Cohn (2010b, S. 167)

In Scrum werden die Anforderungen und Eigenschaften, die für das zu entwickelnde Produkt realisiert werden sollen, vom Product Owner im Product Backlog ( 3.3.1) gesammelt und verwaltet. Die wichtigsten daraus legt er im Sprint Planning Meeting ( 3.5.2) vor, von denen das Team diejenigen auswählt, die es in der nächsten Iteration realisieren kann. Aus diesen leitet sich das Team Aufgaben ab und hält sie im Sprint Backlog ( 3.3.2) fest. Während der Iteration, die in Scrum als Sprint ( 3.4) bezeichnet wird, arbeitet das Team den Sprint Backlog eigenverantwortlich ab und validiert dabei im 24-Stunden- Rhythmus seinen Fortschritt im Daily Scrum ( 3.5.3). Das Ziel jeder Iteration ist es, ein potentiell auslieferbares Produkt fertig zu stellen. Bild 4 veranschaulicht grob diese Vorgänge.

Durch das Sprint Planning Meeting, dem Daily Scrum sowie dem Sprint Review ( 3.5.5) und der Retrospektive ( 3.5.6) findet in Scrum eine empirische Prozesssteuerung statt, mit welcher die Produktivität und die Entwicklungsrichtung in Bezug auf das Ziel ständig überwacht und angepasst sowie die gemeinsame Arbeit reflektiert und entsprechend verbessert werden. (Hammerstein 2009, S. 30; Schwaber und Sutherland 2010, S. 4)

Scrum gibt, wie bei agilen Methodiken üblich, nicht viele Regeln vor. (Coldeway 2003, S. 52) Um aber die Einhaltung der vorhandenen Regeln und das Funktionieren von Scrum sicherzustellen, gibt es den Scrum Master ( 3.2.2), der neben dem Product Owner und dem Team die dritte Rolle in Scrum darstellt.

3.2 Rollen

In Scrum gibt es die drei Rollen Scrum Master, Product Owner und Team, die in den nächsten Abschnitten beschrieben und in ihrer Gesamtheit als Scrum-Team bezeichnet werden.

3.2.1 Scrum Master

Die erste hier vorgestellte Rolle ist der Scrum Master, deren Zweck es ist, das Funktionieren von Scrum sicherzustellen. Welche Aufgaben und Verantwortlichkeiten damit verbunden sind, folgt in diesem Abschnitt.

Zunächst sei angemerkt, dass es sich beim Scrum Master nicht um einen Projektleiter oder Teamleiter handelt. Sollte er eine solche Rolle einnehmen, wäre das keine korrekte Umsetzung von Scrum, da z. B. dem Product Owner ( 3.2.2) die Möglichkeit genommen würde, das Team direkt zu steuern. Um ein nachhaltiges Funktionieren von Scrum sicherzustellen, müssen die Inhaber der Rollen diese richtig verstanden haben und sie entsprechend leben. (Pichler 2009, S. 24)

Einen wesentlichen Punkt, der einen Scrum Master von einem Projektleiter oder Teamleiter unterscheidet, sehen Wieczorrek und Mertens (2010, S. 127) darin, dass sich der Scrum Master zurücknehmen muss und auf keinen Fall in die Arbeit des Teams eingreifen darf. Tim Lister (2007) veranschaulicht dies mit einem Bild von marschierenden Küken. Der Scrum Master, oder von Lister allgemeiner als agile leader bezeichnet, entspricht in diesem Bild nicht dem vordersten Küken, das den Weg vorgibt. Dieses bezeichnet er lediglich als Scout, während er das hinterste Küken, welches stets das Ziel und die Gruppe im Auge hat, als tatsächlichen Leader betrachtet. Von dieser Position aus, so Eickmann (2009a, S. 122–123), ist es dem Scrum Master möglich, sicherzustellen, dass sich das Team an die Scrum Regeln hält und keine Gefahren die Arbeit des Teams bedrohen.

Damit das Team sich an die Regeln hält und mit seiner Arbeit möglichst effizient das Ziel verfolgt, agiert er ähnlich wie ein Coach von Sportteams. Er bereitet das Team vor, erklärt die Regeln und beantwortet aufkommende Fragen. Während das Team dann auf dem Feld eigenverantwortlich agiert, steht er selbst nur am Spielfeldrand, ohne aktiv am Spiel teilzunehmen und beobachtet stattdessen die Spielweise (Arbeitsweise) des Teams, deckt Schwachstellen oder Potentiale auf und gibt dem Team Hinweise, wie es sich verbessern kann.

Daneben wacht er über mögliche Gefahren, die auf sehr unterschiedliche Weise in Erscheinung treten können. Beispielsweise können dem Team notwendige Ressourcen fehlen, weil z. B. Testhardware fehlt oder die IT-Abteilung keinen Bugtracker bereit stellt. Dem Team oder einzelnen Teammitgliedern können zusätzliche Aufgaben zugeteilt werden oder Teammitglieder werden ganz abgezogen. Es können durch die Organisation bedingte Probleme auftreten, wie z. B. ungeeignete Arbeitsräume, Besprechungsräume oder fehlende Medien. Ein falsches Rollenverständnis, Interessenskonflikte und Differenzen zwischen den Beteiligten stellen ebenso Gefahren dar wie private und fachliche Probleme der einzelnen Teammitglieder. Nicht alle dieser oder anderer auftretenden Probleme oder Hindernisse können vom Scrum Master selbst beseitigt werden. In solchen Fällen ist er trotzdem für deren Beseitigung verantwortlich, was Eickmann zufolge oft mit einem hohen Aufwand an Zeit und einem guten Durchsetzungsvermögen verbunden ist.

Auch wenn der Scrum Master keine Weisungsbefugnisse hat, identifizieren Wirdemann sowie Schwaber und Beedle als weitere Aufgabe des Scrum Master das schnelle Treffen von Entscheidungen, sollte es erforderlich werden. Dies ist dann der Fall, wenn das Team die Entscheidung nicht treffen kann und das Fehlen der Entscheidung die Arbeit des Teams behindert und damit zur Gefahr wird. Der Scrum Master trifft diese Entscheidung möglichst schnell und auch dann, wenn ihm nicht ausreichend Informationen dafür vorliegen, da es besser ist, mit schlechten Entscheidungen weiter zu arbeiten als ohne Entscheidung zu stagnieren. (Schwaber und Beedle 2002, S. 32; Wirdemann 2009, S. 40)

Als organisatorisches Hilfsmittel zur Beseitigung von Gefahren für die Arbeit des Teams, die auch als Impediments bezeichnet werden, kann der Scrum Master eine Liste, auch Impediment Backlog genannt, führen, in die er erkannte Gefahren notiert, um sie dann abzuarbeiten. Auf diese Weise wird Transparenz bezüglich vorhandener Probleme und der Bemühung des Scrum Master, diese zu beseitigen, geschaffen. Zusätzlich kann die Entwicklung dieser Liste auch als Indikator für den Erfolg des Scrum Master dienen. Ein ständiges Verschwinden von Einträgen bedingt durch das erfolgreiche Beseitigen von Problemen schafft Vertrauen beim Team, da für dieses die Unterstützung durch den Scrum Master sichtbar wird. Kommen aber immer neue Einträge hinzu, ohne dass bereits bestehende beseitigt werden, indiziert dies entweder eine mangelhafte Unterstützung des Projekts durch die Organisation oder eine schlechte Arbeit des Scrum Master. Langfristig kann dies zu einem Vertrauensverlust des Teams in den Scrum Master führen und den Erfolg Projekts gefährden. (Wirdemann 2009, S. 39–40)

Die Sicherstellung, dass die direkte Kommunikation und Zusammenarbeit zwischen dem Team und dem Product Owner funktioniert, ist eine weitere Aufgabe des Scrum Master. Sollte beispielsweise der Product...