Agile Vorgehensmodelle im Überblick Teil 2: Die Scrum Methode

Scrum ist ein Vorgehensmodell, das wenige Regeln trifft, denn hier organisieren sich Teams weitgehend selbst und wählen auch selbst die eingesetzten Methoden. Die Grundidee ist, dass ein Projekt nicht von Anfang bis Ende geplant wird, sondern iterativ mit kurzen Feedback-Schleifen, den sogenannten Sprints, entwickelt wird. Ursächlich aus der Softwareentwicklung kommend etablierte sich Scrum auch in anderen Branchen, z. B. in der Grundlagenentwicklung oder bei hoher Volatilität in den Projektanforderungen und im Projektumfeld.

Scrum – Die Regeln

Scrum knüpft an viele Grundannahmen einer schlanken Produktion (lean production) an und überträgt Erfahrungen aus der Automobilbranche auf diese neue Methode der agilen Entwicklung. 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 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 selbst gewählten Aufgabenpakete. Dabei werden traditionelle Werkzeuge (z. B. zur Kommunikation oder Projektsteuerung oder vom „Management von oben“, festgelegte Prozesse für die Teamstrukturierung, die die Zusammenarbeit im Team kontrollieren und regulieren) abgelehnt.

Scrum basiert als agile Methode auf “agilen Werten“, die 2001 im Agilen Manifest formuliert wurden.

Scrum – der Prozess

Scrum ist eine inkrementelle, iterative Entwicklungsmethode. Die Entwicklung wird von einem selbstorganisierten, selbstgeführten Team Schritt für Schritt in fixen Zyklen, den sog. Sprints, organisiert. Eine gleichmäßige Sprintlänge (ca. 2–4 Wochen) gibt dem Team dabei einen Rhythmus. Ziel ist es, am Ende eines jeden Sprints ein potenziell auslieferbares Produktinkrement zu haben, also ein vollständig fertiges (Teil-)Ergebnis, dass potenziell produktiv genützt werden kann. Idee dahinter ist, dass so rascher Ergebnisse geliefert werden und auch (in späten Projektphasen) noch flexibel auf (neue) Kundenwünsche oder Veränderungen eingegangen werden kann.

Die Idee von Scrum ist es,
dass rascher Ergebnisse geliefert werden und auch in späteren Projektphasen flexibel auf Veränderungen eingegangen werden kann.

Zentrales Element von Scrum ist der Sprint: Am Anfang eines jeden Sprints steht das sogenannte Product Backlog, eine Liste mit priorisierten Anforderungen. Aus dieser entnimmt das Entwicklungsteam entsprechend ihrer Priorität so viele Aufgaben (Anforderungen), wie es erfahrungsgemäß in einem Sprint umsetzen kann. Diese Anforderungen werden während des laufenden Sprints nicht durch Zusatzanforderungen modifiziert, um ihre Fertigstellung nicht zu gefährden.

Während des Sprints arbeitet das Team also konzentriert und ohne Störungen von außen daran, die definierten Tasks in ein potenziell auslieferbares Produktinkrement umzusetzen. Am Ende des Sprints wird dieses dem Kunden (und potenziellen Stakeholdern) präsentiert und im Idealfall von diesem abgenommen. Potenzielles Kundenfeedback fließt – wie auch die Erfahrungen des Teams – in die nächste Sprintplanung ein, und der Prozess beginnt von Neuem.

Scrum definiert wenige Eckpfeiler für die Vorgehensweise, deshalb wird es häufig als Rahmenwerk bezeichnet. Im Kern stehen drei Rollen, drei Artefakte (Ergebnistypen) und vier Ereignisse.

Scrum-Rollen

Bei Scrum gibt es drei klar getrennte Rollen, die von jenen Mitarbeitern besetzt werden, die an der gleichen Entwicklung zusammenarbeiten und damit auch das gleiche Ziel haben.

Bei Scrum wird von der Annahme ausgegangen, dass das Team sich intuitiv selbst organisiert und zu jeder Aufgabe dynamisch eine bestangepasste innere Organisationsstruktur bildet, die sich relativ schnell an die sich wandelnden komplexen Aufgaben anpasst.

Produkt Owner

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

Scrum Master

Der Scrum Master hat die Aufgabe, die Prozesse der Entwicklung und Planung zu koordinieren und die Aufteilung der Rollen und Rechte zu überwachen. Er hält die Transparenz während der gesamten Entwicklung aufrecht und fördert das Zutagetreten der bestehenden Verbesserungspotenziale. 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.

Das Entwickler-Team

Bei der Rollenaufteilung wird berücksichtigt, dass sich das Entwickler-Team selbst organisiert. Bei Scrum wird von der Annahme ausgegangen, dass sich das Team intuitiv selbst ordnet und zu jeder Aufgabe dynamisch eine bestmögliche innere Organisationsstruktur bildet, die sich relativ schnell an die sich wandelnden komplexen Aufgaben anpasst.

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öchst priorisierten 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, wie viele Elemente des Backlogs nach dem nächsten Sprint erreicht werden müssen. Man spricht dabei von „Commitments“.

Scrum-Artefakte

Product Backlog

Das Product Backlog enthält funktionale und nicht funktionale Anforderungen des zu entwickelnden Produkts. Es muss zu Entwicklungsbeginn nicht vollständig sein; es wird laufend fortgeführt.

Die funktionalen Anforderungen werden in sogenannten User Stories beschrieben und beinhalten alle Funktionalitäten, die der Kunde wünscht, zuzüglich technischer Abhängigkeiten. Sie beschreiben also das „WAS“ und nicht das „WIE“.

Vor jedem Sprint werden die Elemente des Product Backlogs neu bewertet und priorisiert. Dabei können bestehende Elemente entfernt sowie neue hinzugefügt werden. Vor den Entwicklungen wird der Umfang von hoch priorisierten Features geschätzt und in den Sprint Backlog übernommen. Vor jedem Sprint wird vom Product Owner das Ziel des kommenden Sprints als Ergebnisziel ausformuliert.

Sprint Backlog

Das Sprint Backlog enthält alle Aufgaben (Tasks), die notwendig sind, um das Ziel des Sprints zu erfüllen. Die Tasks beschreiben im Detail „WIE“ eine User Story in ein funktionierendes Produkt umgesetzt werden soll. Eine Aufgabe sollte dabei nicht länger als 2 Arbeitstage dauern. Längere Aufgaben sollten in kurze Teilaufgaben zerlegt werden. Bei der Planung des Sprints werden nur so viele Aufgaben eingeplant, wie das Team an Kapazität aufweisen kann. Die Kapazität berechnet sich gemäß folgender grober Formel: Kapazität (in Stunden) = Arbeitstage × Anzahl Personen × 8 h.

Produktinkrement

Das Produktinkrement ist das Teilprodukt, das am Ende eines Sprints erstellt wurde.

Scrum ist ein hervorragender Ansatz,
um gerade ein Entwicklungsumfeld mit fortlaufend wechselnden oder sich erst entwickelnden Anforderungen zu gestalten.

Scrum-Ereignisse

Sprint Planning

Im Sprint Planning werden für den jeweiligen Sprint jene Anforderungen bestimmt, die in ihm umgesetzt werden und für die eine detaillierte Planung durchgeführt wird.

Daily Scrum

An jedem Tag findet ein kurzes (maximal 15-minütiges) Scrum-Meeting, das sog. Daily Stand-up Meeting, statt. Es sollte täglich zur gleichen Zeit stattfinden, im Stehen abgehalten und vom Scrum Master moderiert werden. Im Scrum-Meeting werden von jedem Teammitglied folgende Fragen kurz beantwortet:

1. 1 „Bist Du gestern mit dem fertig geworden, was Du Dir vorgenommen hast?“
2. 2 „Welche Aufgaben wirst Du bis zum nächsten Meeting bearbeiten?“
3. 3 „Gibt es ein Problem, das Dich blockiert?“

Das Meeting dient dem Informationsaustausch im Team. Erledigte Aufgaben und Features werden anschließend im Burndown Chart aktualisiert. Falls neue Hindernisse erkannt wurden, müssen diese vom Scrum Master bearbeitet werden. Dazu werden sie in das Impediment Backlog eingetragen.

Sprint Review

Nach einem Sprint wird das Sprintergebnis – das sog. Inkrement – einem informellen Review durch das Team und den Kunden unterzogen. Dazu wird das Ergebnis des Sprints (funktionierende Teilprodukte) vorgeführt, eventuell werden technische Eigenschaften präsentiert. Der Product Owner bzw. der Kunde prüft, ob das Sprintergebnis seinen Anforderungen entspricht, eventuelle Änderungen werden im Product Backlog dokumentiert. Ziel ist es, zeitnah Feedback der Anwender einzuholen, um das Produkt besser zu machen.

Sprint-Retrospektive

In der Retrospective wird im Team die zurückliegende Sprintphase betrachtet. Es handelt sich dabei um einen zunächst wertfreien Rückblick auf die Ereignisse des Sprints. Verbesserungspotenziale werden 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 als „Lessons Learned“ für den kommenden Sprint aufgenommen.

Product Backlog Refinement

Das Product Backlog Refinement ist kein klassisches Scrum-Ereignis, aber als kontinuierliche Aktivität ein wertvoller Vorgang. Hierzu gehören das Hinzufügen von Details, Schätzungen und das Priorisieren von User Stories (Kundenanforderungen) im Product Backlog.

Scrum – Fazit

Scrum ist nicht umsonst der zurzeit wohl bekannteste und verbreitetste agile Ansatz. Scrum ist ein hervorragender Ansatz, um gerade ein Projektumfeld mit fortlaufend wechselnden oder sich erst entwickelnden Anforderungen zu gestalten, also z. B. Produkt- bzw. Prozess- oder Organisationsentwicklungen kundenorientiert und gestaltbar umzusetzen. Gleichzeitig ist es ein Vorzeigemodell für das Empowerment von Teams, für die starke Integration der Kundensicht sowie für die Wichtigkeit gut organisierter Kommunikation und klar definierter (und gelebter) Spielregeln.