SCRUM

Scrum (engl. das Gedränge) ist ein Vorgehensmodell mit Meetings, Artefakten, Rollen, Werten und Grundüberzeugungen, das beim Entwickeln von Produkten im Rahmen agiler Softwareentwicklung hilfreich ist. Teammitglieder organisieren ihre Arbeit weitgehend selbst und wählen auch die eingesetzten Software-Entwicklungswerkzeuge und -Methoden. Ken Schwaber, Jeff Sutherland und Mike Beedle haben Scrum erfunden und etabliert. Als Software-Entwicklungsmethode wird Scrum das erste Mal in dem Buch “Wicked Problems, Righteous Solutions” beschrieben. Scrum in Produktionsumgebungen wird zum ersten Mal in dem Artikel “The New New Product Development Game” erläutert und später in “The Knowledge Creating Company” weiter ausgeführt von Ikujiro Nonaka und Hirotaka Takeuchi.

2003 legte Ken Schwaber ein Zertifizierungsprogramm für Scrum Master auf. Das Ziel, heute wie damals, ist es, die Software-Entwicklung durch das Nutzen von Scrum zu professionalisieren. Inzwischen wird das Training „Certified Scrum Master“ unter der Schirmherrschaft der Scrum Alliance durchgeführt.

Grundannahmen

Scrum wurde zuerst als Methode zur Produkt-Entwicklung von Nonaka und Takeuchi entwickelt (“The New New Product Development Game”). Die Grundlagen von Scrum liegen im Wissensmanagement und wurden später von Jeff Sutherland und Ken Schwaber durch die Hinzunahme streng wissenschaftlicher Vorgehensweisen weiter ausgebaut.

Scrum kann besser verstanden werden, wenn man sich mit der Schlanken Produktion (engl. lean production) auskennt. Scrum überträgt keine Erfahrungen aus der Automobilbranche auf die Softwareentwicklung, aber es lässt sich zeigen, dass diese Erfahrungen zum Verständnis der grundlegenden Probleme in der Software-Entwicklung beitragen. In der Automobilbranche gilt die Firma Toyota als ein Vorreiter der Schlanken Produktion. Das sich ständig in der Weiterentwicklung befindende Toyota Production System (TPS) umfasst dabei Methoden und Arbeitsmittel der Produktion und steht im selben Verhältnis zum Toyota Way, der Philosophie hinter dem TPS, wie die Scrum-Methodik zur agilen Softwareentwicklung. Im Mittelpunkt steht bei beiden Systemen die ständige Weiterentwicklung der Mitarbeiter, der Herstellungsprozesse, der Arbeitsmittel und Methoden, unter gleichzeitig konstantem Beibehalten der Grundannahmen, die dahinter stehen. Gemein ist den meisten agilen Vorgehensmodellen dabei die gleichzeitige Weiterentwicklung aller an dem Prozess Beteiligten, auch der Kunden und Partner. Ziel der Grundannahmen ist es, die Produktion ständig zu verbessern, um höchste Qualität bei niedrigstem Aufwand zu erreichen (Kaizen).

Bei Scrum wird grundsätzlich angenommen, dass Produktfertigungs- und Entwicklungsprozesse so komplex sind, dass sie sich im Voraus weder in große abgeschlossene Phasen noch in einzelne Arbeitsschritte mit der Granularität von Tagen oder Stunden pro Mitarbeiter vorher planen lassen. Somit ist es produktiver, wenn sich ein Team in einem festen äußeren Rahmen mit sehr grober Granularität selbst organisiert. Dieses selbstorganisierte Team übernimmt in diesem mit dem Product Owner abgestimmten Rahmen die gemeinsame Verantwortung für die Fertigstellung der selbstgewählten Aufgabenpakete. Dabei werden traditionelle Werkzeuge, z. B. zur Kommunikation oder Projektsteuerung sowie durch das Management „von oben“, für die Teamstrukturierung festgelegter Prozesse, die die Zusammenarbeit im Team kontrollieren und regulieren, abgelehnt.

Scrum erfüllt als agile Methode die Bedingungen der agilen Software-Entwicklung, die 2001 im Agilen Manifest u. a. von Ken Schwaber und Jeff Sutherland mitformuliert wurden:

1. Individuen und Interaktionen gelten mehr als Prozesse und Tools.
2. Funktionierende Programme gelten mehr als ausführliche Dokumentation.
3. Die stetige Zusammenarbeit mit dem Kunden steht über Verträgen.
4. Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans.

Im Folgenden werden Kernpunkte der Scrum-Arbeitsmittel wiedergegeben. Sie sind nicht zu verwechseln mit den hinter diesen Arbeitsmitteln stehenden oben genannten Grundannahmen und gelten lediglich als bewährte Möglichkeiten zur Umsetzung dieser Grundannahmen.

Rollen

Bei Scrum gibt es drei klar getrennte Rollen, die von Mitarbeitern ausgefüllt werden, die im selben Projekt zusammen arbeiten und damit auch dasselbe Ziel haben. Damit jeder für das, was er kann, zuständig und verantwortlich ist, werden die Zuständigkeiten wie folgt aufgeteilt:

Product Owner

Der Product Owner legt das gemeinsame Ziel fest, das das Team erreichen muss. Er stellt das Budget zur Verfügung. Er setzt regelmäßig die Prioritäten der einzelnen Product-Backlog-Elemente (siehe unten). Dadurch legt er fest, welches die wichtigsten Features sind, aus denen das Entwicklungsteam eine Auswahl für den nächsten Sprint trifft.

Team

Das Team schätzt die Aufwände der einzelnen Backlog-Elemente ab und beginnt mit der Implementierung der für den nächsten Sprint machbaren Elemente. Dazu wird vor dem Beginn des Sprints ein weiteres Planungstreffen durchgeführt, bei dem die höchstpriorisierten Elemente des Backlogs und konkrete Aufgaben aufgeteilt werden. Das Team arbeitet selbstorganisiert im Rahmen einer Time Box (dem Sprint) und hat das Recht (und die Pflicht), selbst zu entscheiden, wieviele Elemente des Backlogs nach dem nächsten Sprint erreicht werden müssen, man spricht dabei von commitments.

Scrum Master

Der Scrum Master hat die Aufgabe, die Prozesse der Entwicklung und Planung durchzuführen und die Aufteilung der Rollen und Rechte zu überwachen. Er hält die Transparenz während der gesamten Entwicklung aufrecht und unterstützt dabei, Verbesserungspotentiale zu erkennen und zu nutzen. Er ist keinesfalls für die Kommunikation zwischen Team und Product Owner verantwortlich, da diese direkt miteinander kommunizieren. Er steht dem Team zur Seite, ist aber weder Product Owner noch Teil des Teams. Der Scrum Master sorgt mit allen Mitteln dafür, dass das Team produktiv ist, also die Arbeitsbedingungen stimmen und die Teammitglieder zufrieden sind. Er tritt somit für die ordnungsgemäße Durchführung und Implementierung von Scrum im Rahmen des Projektes ein.

Zusammenspiel

Bei der Rollenaufteilung wurde berücksichtigt, dass das Team sich selbst organisiert. Der Product Owner gibt nicht vor, welches Teammitglied wann was macht und wer mit wem zusammenarbeitet. Bei Scrum wird von der Annahme ausgegangen, dass das Team sich intuitiv selbst organisiert, und zu jeder Aufgabe dynamisch eine optimale innere Organisationsstruktur bildet, die sich relativ schnell an die sich wandelnden komplexen Aufgaben anpasst. Der Scrum Master hat die Pflicht, darauf zu achten, dass der Product Owner nicht in diesen adaptiven Selbstorganisationsprozess eingreift und das Team stört oder Verantwortlichkeiten an sich nimmt, die ihm nicht zustehen.

Zertifizierung

Bezüglich der Rollen bietet die Scrum Alliance Zertifizierungsprogramme. So gibt es als Basiszertifizierung die Zertifizierung zum Scrum Master sowie zum Scrum Product Owner. Weitergehende Zertifizierungen die auf diesen beiden Zertifizierungen aufbauen, sind die Zertifizierungen zum Certified Scrum Practitioner und anschließend zum Certified Scrum Coach, und Certified Scrum Trainer.^[1].

Artefakte

Product Backlog

Das Product Backlog enthält die Features des zu entwickelnden Produkts. Es umfasst alle Funktionalitäten, die der Kunde wünscht, zuzüglich technischer Abhängigkeiten. Vor jedem Sprint werden die Elemente des Product Backlogs neu bewertet und priorisiert, dabei können bestehende Elemente entfernt sowie neue hinzugefügt werden. Hoch priorisierte Features werden von den Entwicklern im Aufwand geschätzt und in den Sprint Backlog übernommen. Ein wesentliches Merkmal des Backlogs ist die Tiefe der Beschreibung von einzelnen Features. Hoch priorisierte Features werden im Gegensatz zu niedrig priorisierten sehr detailliert beschrieben. Somit wird viel Zeit für die wesentlichen Elemente und wenig für unwesentliche verwendet.

Sprint Backlog

Das Sprint Backlog enthält alle Aufgaben, die notwendig sind, um das Ziel des Sprints zu erfüllen. Eine Aufgabe sollte dabei nicht länger als 16 Stunden dauern. Längere Aufgaben sollten in kurze Teilaufgaben zerlegt werden. Bei der Planung des Sprint werden nur so viele Aufgaben eingeplant, wie das Team an Kapazität aufweisen kann.

Die Kapazität berechnet sich gemäß folgender Formel: Kapazität (in Stunden) = Arbeitstage × Anzahl Personen × 7 h. (8h Tag inkl. 1h Puffer)

Burndown Chart

Das Burndown Chart ist eine graphische, pro Tag zu erfassende Darstellung des noch zu erbringenden Restaufwands pro Sprint. Im Idealfall fällt die Kurve kontinuierlich (daher burndown) und ist der Restaufwand am Ende des Sprints Null. Das Chart lässt anhand der Verlängerung der negativen Steigung bereits während des Sprints erkennen, ob der anfangs geschätzte Aufwand umgesetzt werden kann.

Impediment Backlog

In das Impediment Backlog werden alle Hindernisse des Projekts eingetragen. Der Scrum Master ist dafür zuständig, diese gemeinsam mit dem Team auszuräumen.

Zyklusmodell

The Scrum process

Sprint

Zentrales Element des Entwicklungszyklus von Scrum ist der Sprint. Ein Sprint bezeichnet die Umsetzung einer Iteration, Scrum schlägt ca. 30 Tage als Iterationslänge vor. Vor dem Sprint werden die Produkt-Anforderungen des Kunden in einem Product Backlog gesammelt. Auch technische und administrative Aufgaben werden dort aufgenommen. Das Product Backlog muss nicht vollständig sein; es wird laufend fortgeführt. Die Anforderungen für den ersten Sprint sind meistens rasch aufgestellt. Die Anforderungen werden informell skizziert. Für einen Sprint wird ein Sprint Backlog erstellt. In diesen werden Anforderungen übernommen, die während des Sprints umgesetzt werden sollen. Die Entscheidung, welche Anforderungen umgesetzt werden, wird vom Kunden nach von ihm festgelegten Prioritäten getroffen. Zum Sprint organisiert sich das Entwicklungsteam selbst, braucht also keine detaillierten methodischen Vorschriften.

Daily Scrum

An jedem Tag findet ein kurzes (maximal 15-minütiges) Daily Scrum statt.

Scrum definiert keine konkrete Uhrzeit für das Meeting, das Meeting sollte jedoch täglich zur gleichen Zeit stattfinden. Empfohlener Zeitpunkt für das Scrum-Meeting ist die Zeit nach dem Mittagessen, da morgendliche Scrum-Meetings oft mit flexiblen Gleitzeitregelungen kollidieren und der müde Punkt nach dem Mittagessen bei einem Scrum-Meeting, das durchaus im Stehen abgehalten werden kann, nicht so stark ins Gewicht fällt wie bei anderen Tätigkeiten. Die Meetings sind kürzer als am Morgen, weil allgemeine Dinge und Neuigkeiten schon vorher diskutiert wurden und die Mitarbeiter mit dem Kopf ganz bei der Arbeit sind.

Das Team stellt sich gegenseitig die folgenden Fragen:

• „Bist du gestern mit dem fertig geworden, was du dir vorgenommen hast?“
• „Welche Aufgaben wirst du bis zum nächsten Meeting bearbeiten?“
• „Gibt es ein Problem, das dich blockiert?“

Die Sitzung dient dem Informationsaustausch des Teams untereinander. Hier geht es darum, dass möglichst alle alles wissen. Falls neue Hindernisse erkannt wurden, müssen diese vom Scrum Master bearbeitet werden. Dazu werden sie in das Impediment Backlog eingetragen.

Größere Projekte werden durch das Einführen von Scrum-of-Scrum Meetings, Product Owner Daily Scrums und ScrumMaster Weekly gesteuert.

Review

Nach einem Sprint wird das Sprint-Ergebnis einem informellen Review durch Team und Kunden unterzogen. Dazu wird das Ergebnis des Sprints (die laufende Software) vorgeführt, eventuell werden technische Eigenschaften präsentiert. Der Kunde prüft, ob das Sprint-Ergebnis seinen Anforderungen entspricht, eventuelle Änderungen werden im Product Backlog dokumentiert.

Retrospektive

In der Retrospektive wird die zurückliegende Sprint-Phase betrachtet. Es handelt sich dabei nicht um Lessons Learned, sondern um einen zunächst wertfreien Rückblick auf die Ereignisse des Sprints. Alle Teilnehmer notieren dazu die für sie wichtigen Ereignisse auf Zetteln und ordnen sie dem Zeitstrahl des Sprints zu. Anschließend schreiben die Teilnehmer alle Punkte auf, welche ihnen zu den Fragen „Was war gut?“ (Best practice) bzw. „Was könnte verbessert werden?“ (Verbesserungspotential) einfallen. Jedes Verbesserungspotential wird priorisiert und einem Verantwortungsbereich (Team oder Organisation) zugeordnet. Alle der Organisation zugeordneten Themen werden vom Scrum Master aufgenommen und in das Impediment Backlog eingetragen. Alle teambezogenen Punkte werden in das Product Backlog aufgenommen.

Wird für die Retrospektiven und deren Vorbereitung nicht genug Zeit eingeräumt, bleiben die Erkenntnisse und Ergebnisse oberflächlich und die Resultate nach jedem Sprint ähneln sich. Dann läuft man Gefahr, dass die Retrospektiven an Stellenwert verlieren oder ganz gestrichen werden, weil die Ergebnisse der Retrospektiven vorhersehbar sind.

Kritische Betrachtung

Auch das Vorgehensmodell Scrum kann unausgewogen eingesetzt werden und dann scheitern. Ein besonderes Risiko sind dominante Teamplayer, die den Prozess der Selbstorganisation stören, ohne einen gleichwertigen eigenen Beitrag in diesen Organisationsprozess und ohne einen angemessenen eigenständigen Beitrag in die Problemlösung einzubringen. Zudem muss eine Entwicklungsabteilung generell bereits auf recht hohem Niveau mit einer modernen Programmiersprache arbeiten, um in kurzen Abständen lieferbare, qualitätsgeteste Software zu produzieren. Die häufigen Änderungen erfordern Refaktorierung. Refaktorierung und häufige Lieferungen zum Kunden benötigen eine ausreichende Testabdeckung durch Unit- und Regressionstest. Gerade in alten, gewachsenen Programmen ist eine ausreichende Testabdeckung mit vertretbarem Aufwand oft nicht zu erreichen. Manuelle Tests generieren nach jedem Sprint erneut Testaufwand.

Literatur

• Peter DeGrace, Leslie Hulet Stahl: Wicked Problems, Righteous Solutions: A Catalog of Modern Engineering Paradigms. Yourdon Press Computing Series, 1990 (erste Definition)
• The New New Product Development Game. Harvard Business Review 86116:137-146, 1986 (PDF-Version)(HTML-Version)
• Ikujiro Nonaka, Hirotaka Takeuchi: The Knowledge Creating Company. How Japanese Companies Create the Dynamics of Innovation. Oxford University Press, 1995, ISBN 0-195-09269-4
• Ken Schwaber (Autor), Thomas Irlbeck (Übersetzer): Agiles Projektmanagement mit Scrum. Microsoft Press Deutschland, 2007, ISBN 978-3866456310
• Ken Schwaber: Agile Project Management with Scrum. Microsoft Press, 2004, ISBN 0-735-61993-X (aktuelles Standardwerk über Scrum)
• Ken Schwaber, Mike Beedle: Agile Software Development with Scrum'.' Prentice Hall, 2001, ISBN 0-13-067634-9
• Mike Cohn: Agile Estimating and Planning. Prentice Hall, 2006, ISBN 0-13-147941-5
• Norman L. Kerth: Project Retrospectives: A Handbook for Team Reviews. Dorset House, 2001, ISBN 0932633447
• Roman Pichler: Scrum: Agiles Projektmanagement erfolgreich einsetzen. dPunkt, 2008, ISBN 978-3-89864-478-5
• Ken Schwaber: The Enterprise and Scrum. Microsoft Press 2007, ISBN 0-7356-2337-6
• Ken Schwaber: Scrum im Unternehmen. Microsoft Press Deutschland, 2008, ISBN 978-3866456433
• Boris Gloger: Scrum – Produkte zuverlässig und schnell entwickeln. Hanser Verlag, 2008, ISBN 3446414959

Einzelnachweise

1. ↑ http://www.scrumalliance.org/training/

Siehe auch

• Feature Driven Development
• Extreme programming (XP)
• Paarprogrammierung
• Testgetriebene Entwicklung
• ständige Refaktorisierungen
• Story-Cards
• schnelle Codereviews

Weblinks

• Die offizielle Website der Scrum Alliance (englisch)
• What is Scrum? (englisch)
• Scrum-Einführung (deutsch)
• Scrum-Glossar (deutsch)
• Scrum Cheat Sheet - Scrum auf einen Blick (englisch)
• Alle Scrum Zertifizierungen in Deutschland