Agiles Projektmanagement / SCRUM

Scrum ist ein einfaches Framework (und keine Methodik) für die effektive, agile Zusammenarbeit von Teams an komplexen Produkten. Scrum besteht aus Rollen, Ereignissen, Artefakten und den Regeln, die sie miteinander verbinden. Das Framework nutzt die wissenschaftliche Methode der Empirie und ersetzt einen “programmierten algorithmischen Ansatz” durch einen “heuristischen, mit Respekt für Menschen und Selbstorganisation, um mit Unvorhersehbarkeit und der Lösung komplexer Probleme umzugehen.” Scrum setzt auf iterative, inkrementelle Zyklen, um Teams dabei zu unterstützen, aus der Empirie zu lernen.

Scrum Values

The Roles of the Scrum Team

Das Scrum-Team besteht aus einem Product Owner, den Entwicklern und einem Scrum Master. Alle drei Rollen tragen Verantwortung für das Gelingen eines Projektes. Empfohlen sind 10 oder weniger Personen in einem Scrum-Team. Durch die verschiedenen Rollen werden verschiedene Aspekte in der Entwicklung eines neuen Produktes abgedeckt:

Der Product Owner prorisiert die Features (auch: User Stories) nach Kundennutzen und Umsetzungsaufwand in Zusammenarbeit mit den Entwicklern vor der Umsetzung durch dieses. Der Product Owner ist für das Product Backlog verantwortlich, einschließlich seines Inhalts, seiner Verfügbarkeit und seiner Anordnung. So werden die Entwickler nicht mit Arbeit überfordert und die Kunden erhalten die Features zuerst, welches sie sich am meisten wünschen. Kommunikation ist einer der wichtigsten Fähigkeiten für einen Product Owner.

Das Scrum Team ist ein kleines, cross-funktionales, selbst-managendes Team. Selbst-managend meint in diesem Zusammenhang, dass dasd Team intern entscheidet wer was wann und wie macht. Funktionsübergreifende Teams verfügen über alle erforderlichen Kompetenzen, um die Arbeit zu erledigen, ohne von anderen, die nicht zum Team gehören, abhängig zu sein. Der Fokus des Scrum Teams ist, die vom Product Owner priorisierten Features bestmöglich umzusetzen.

Der Scrum Master hat den Fokus auf einer reibungslosen Durchführung, die Versorgung des Teams mit den notwendigen Ressourcen sowie der schnellen Umsetzung der Features, sodass Kunden schnellstmöglich Zugang zu den neuen Features erhalten und das Team durch einen kontinuierlichen Austausch mit den Kunden lernen kann. U.a. organisiert der Scrum Master das Scrum Planning und den Daily Scrum, den Scrum Review und die Scrum Retrospective.

The Scrum Events

Vorgeschriebene Ereignisse werden in Scrum verwendet, um Regelmäßigkeit zu schaffen und die Notwendigkeit von nicht in Scrum definierten Meetings zu minimieren. Alle Ereignisse sind mit einem Zeitlimit versehen. Sobald ein Sprint beginnt, ist seine Dauer festgelegt und kann nicht verkürzt oder verlängert werden. Die verbleibenden Events können immer dann enden, wenn der Zweck des Events erreicht ist, wodurch sichergestellt wird, dass eine angemessene Zeitspanne aufgewendet wird, ohne Verschwendung im Prozess zuzulassen. Die Scrum-Events sind:

 

Sprint

Jeder Sprint kann als ein Projekt mit einem Zeithorizont von maximal einem Monat betrachtet werden. Wie Projekte werden Sprints dazu verwendet, etwas zu erreichen. Jeder Sprint hat ein Ziel, was gebaut werden soll, einen Entwurf und einen flexiblen Plan, der den Bau, die Arbeit und das resultierende Produktinkrement leitet.

Ein Sprint ist ein Zeitfenster von einem Monat oder weniger, in dem ein “fertiges”, brauchbares und nach Scrum freigegebenes Produktinkrement (siehe Abschnitt “The Scrum Artifacts” → “Increment”) erstellt wird. Sprints haben eine konsistente Dauer über die gesamte Entwicklungsarbeit hinweg und beginnen unmittelbar nach dem Abschluss des vorherigen Sprints.

Während des Sprints werden (1) keine Änderungen vorgenommen, die das Sprint-Ziel gefährden würden; (2) die Qualitätsziele werden nicht verringert; und (3) der Umfang des Sprint kann zwischen dem Product Owner und den Entwicklern geklärt und neu verhandelt werden, wenn neue Erkenntnisse vorliegen.

 

Sprint Planning

Die im Sprint durchzuführende Arbeit wird beim Sprint Planning geplant. Dieser Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum-Teams erstellt.

Das Sprint Planning ist auf maximal acht Stunden für einen einmonatigen Sprint festgelegt. Bei kürzeren Sprints ist die Veranstaltung in der Regel kürzer. Der Scrum Master stellt sicher, dass die Veranstaltung stattfindet und dass die Teilnehmer ihren Zweck verstehen. Der Scrum Master weist das Scrum Team an, es innerhalb der Timebox zu halten.

Die Sprint-Planung beantwortet die folgenden Fragen:

  • Was kann in dem aus dem kommenden Sprint resultierenden Inkrement geliefert werden? (Sprint Goal)
  • Warum wollen wir dieses Ziel erreichen?
  • Wie wird die Arbeit, die für die Lieferung des Inkrements erforderlich ist, erreicht werden? (Kapazitäten, etc.)

Das Sprint Goal ist ein für den Sprint festgelegtes Ziel, das durch die Umsetzung des Product Backlogs erreicht werden kann. Es gibt den Entwicklern eine Anleitung, warum es das Inkrement erstellt. Es wird während der Sprint-Planungssitzung erstellt. Das Sprint Goal gibt den Entwicklern eine gewisse Flexibilität hinsichtlich der im Sprint implementierten Funktionalität. Während die Entwicklern arbeitet, haben sie das Sprint Goal immer im Hinterkopf.

 

Daily Scrum

Der Daily Scrum ist ein tägliches, 15-minütiges Treffen der Entwickler, um sich abzustimmen und einen Plan für die nächsten 24h zu erarbeiten. Außerdem wir die Arbeit der letzen 24h betrachtet.

Daily Scrums verbessern die Kommunikation, machen andere Meetings überflüssig, identifizieren Entwicklungshindernisse, die beseitigt werden müssen, zeigen und fördern schnelle Entscheidungen und verbessern den Wissensstand des Entwickler. Dies ist ein wichtiges Inspektions- und Anpassungsmeeting.

Die Struktur des Meetings wird von den Entwicklern festgelegt und kann auf unterschiedliche Weise durchgeführt werden, wenn es sich auf den Fortschritt in Richtung des Sprint-Ziels konzentriert. Einige Entwickler werden Fragen verwenden, andere werden eher diskussionsbasiert sein.

Der Scrum Master stellt sicher, dass die Entwickler das Meeting haben, aber die Entwickler sind für die Durchführung des Daily Scrum verantwortlich. Der Scrum Master weist die Entwickler an, das Daily Scrum innerhalb des 15-Minuten-Zeitrahmens zu halten. Das Daily Scrum ist eine interne Besprechung für die Entwickler. Wenn andere anwesend sind, sorgt der Scrum Master dafür, dass sie das Meeting nicht stören.

 

Sprint Review

Am Ende des Sprints wird ein Sprint Review abgehalten, um das Inkrement zu inspizieren und das Product Backlog bei Bedarf anzupassen.

Während des Sprint-Reviews arbeiten das Scrum-Team und die Stakeholder zusammen, um zu sehen, was im Sprint gemacht wurde. Basierend darauf arbeiten die Teilnehmer heraus, welche Dingen als nächstes getan werden könnten, um den Wert zu optimieren. Dies ist ein informelles Treffen, kein Status-Meeting, und die Präsentation des Inkrements ist dazu gedacht, Feedback zu erhalten und die Zusammenarbeit zu fördern.

Bei einmonatigen Sprints ist dies ein höchstens vierstündiges Treffen. Bei kürzeren Sprints ist die Veranstaltung normalerweise kürzer. Der Scrum Master stellt sicher, dass die Veranstaltung stattfindet und dass die Teilnehmer ihren Zweck verstehen. Der Scrum Master weist alle Beteiligten darauf hin, dass es innerhalb des Zeitrahmens bleibt.

Das Sprint Review umfasst die folgenden Elemente:

  • Zu den Teilnehmern gehören das Scrum-Team und wichtige Stakeholder, die vom Product Owner eingeladen werden;
  • Der Product Owner erklärt, welche Product-Backlog-Elemente “erledigt” wurden und was noch nicht “erledigt” ist;
  • Die Entwickler besprechen, was während des Sprints gut gelaufen ist, auf welche Probleme es gestoßen ist und wie diese Probleme gelöst wurden;
  • Die Entwickler demonstrieren die Arbeit, die es “Erledigt” hat, und beantwortet Fragen zum Inkrement;
  • Der Product Owner legt den aktuellen Stand des Product Backlog dar, und projiziert wahrscheinliche Ziel- und Liefertermine basierend auf dem bisherigen Fortschritt (falls nötig);
  • Die gesamte Gruppe arbeitet gemeinsam daran, was als Nächstes zu tun ist, so dass der Sprint Review wertvollen Input für die nachfolgende Sprintplanung liefert;
  • Überprüfung, wie sich der Markt oder der potenzielle Einsatz des Produkts verändert haben könnte, was als nächstes zu tun ist; und,
  • Überprüfung des Zeitplans, des Budgets, der potenziellen Fähigkeiten und des Marktes für die nächsten voraussichtlichen Releases von Funktionalität und Fähigkeiten des Produkts.

Das Ergebnis des Sprint-Reviews ist ein überarbeitetes Product Backlog, das die wahrscheinlichen Product Backlog-Elemente für den nächsten Sprint definiert. Das Product Backlog kann auch insgesamt angepasst werden, um neuen Möglichkeiten gerecht zu werden.

 

Sprint Retrospective

Die Sprint Retrospektive ist eine Gelegenheit für das Scrum Team, sich selbst zu überprüfen und einen Plan für Verbesserungen zu erstellen, die im nächsten Sprint umgesetzt werden sollen.

Die Sprint-Retrospektive findet nach dem Sprint-Review und vor der nächsten Sprint-Planung statt. Bei einmonatigen Sprints ist dies ein höchstens dreistündiges Meeting. Bei kürzeren Sprints ist die Veranstaltung in der Regel kürzer. Der Scrum Master stellt sicher, dass die Veranstaltung stattfindet und dass die Teilnehmer ihren Zweck verstehen. Dies ist die Gelegenheit für das Scrum-Team, sich zu verbessern, und alle Mitglieder sollten anwesend sein.

Während der Sprint-Retrospektive bespricht das Team:

  • Was ist im Sprint gut gelaufen
  • Was könnte verbessert werden
  • Was werden wir uns im nächsten Sprint vornehmen zu verbessern

Der Scrum Master ermutigt das Scrum Team, seinen Entwicklungsprozess und seine Praktiken zu verbessern, um ihn für den nächsten Sprint effektiver und angenehmer zu gestalten. Während jeder Sprint Retrospektive plant das Scrum Team Möglichkeiten, die Produktqualität zu erhöhen, indem es die Arbeitsprozesse verbessert oder die Definition von “Fertig” anpasst, wenn dies angemessen ist und nicht im Konflikt mit Produkt- oder Organisationsstandards steht.

Am Ende der Sprint Retrospektive sollte das Scrum Team Verbesserungen identifiziert haben, die es im nächsten Sprint umsetzen wird.

The Scrum Artifacts

Die Artefakte von Scrum stellen Arbeit oder Wert dar, um Transparenz und Möglichkeiten zur Überprüfung und Anpassung zu bieten. Die von Scrum definierten Artefakte sind speziell darauf ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren, damit jeder das gleiche Verständnis des Artefakts hat. Die Scrum-Artefakte sind:

 

Product Backlog:

In Scrum werden Features aus der Sicht des Kunden formuliert, z.B. nach dem Schema Als [Position] brauche ich [Feature], sodass ich [Vorteil]. Diese so formulierten Features nennt man User Stories. Alle User Stories werden im Product Backlog gespeichert. Der Product Backlog ist also quasi die Wunschliste der Kunden.

Der Product Owner ist für das Product Backlog verantwortlich, einschließlich seines Inhalts, seiner Verfügbarkeit und seiner Anordnung. Ein Product Backlog ist nie vollständig. Bei seiner frühesten Entwicklung werden die anfänglich bekannten und am besten verstandenen Anforderungen festgehalten.

Der Product Backlog ist dynamisch; er ändert sich ständig, um zu ermitteln, was das Produkt braucht, um angemessen, wettbewerbsfähig und nützlich zu sein. Dies ist ein fortlaufender Prozess, bei dem der Product Owner und die Entwickler gemeinsam an den Details der Product Backlog-Elemente arbeiten.

 

Sprint Backlog

Der Sprint Backlog ist das Set von Product Backlog-Elementen, die für den Sprint ausgewählt wurden, sowie ein Plan für die Lieferung des Produktinkrements (siehe nächster Absatz) und die Realisierung des Sprint-Ziels. Das Sprint Backlog ist eine Vorhersage der Entwickler darüber, welche Funktionalität im nächsten Inkrement enthalten sein wird und welche Arbeit erforderlich ist, um diese Funktionalität in einem “Done”-Inkrement zu liefern.

Das Sprint Backlog macht alle Arbeiten sichtbar, die die Entwickler als notwendig identifizieren, um das Sprint Goal zu erreichen. Um eine kontinuierliche Verbesserung zu gewährleisten, enthält es mindestens eine Prozessverbesserung mit hoher Priorität, die im vorherigen Retrospektiv-Meeting (siehe Abschnitt “Scrum Events”) identifiziert wurde.

Das Sprint Backlog ist ein Plan, der so detailliert ist, dass Änderungen im Fortschritt im Daily Scrum nachvollzogen werden können. Die Entwickler modifizieren das Sprint Backlog während des Sprints. Nur die Entwickler können ihren Sprint Backlog während eines Sprints ändern.

 

Increment

Ein Inkrement ist die Summe aller Product-Backlog-Elemente, die während eines Sprints fertiggestellt werden, und der Wert der Inkremente aller vorherigen Sprints. Am Ende eines Sprints muss das neue Inkrement “fertig” sein, d. h. es muss sich in einem brauchbaren Zustand befinden und der Definition des Scrum-Teams von “fertig” entsprechen. Wenn ein Product Backlog-Element oder ein Inkrement als “Done” bezeichnet wird, muss jeder verstehen, was “Done” bedeutet, um Transparenz zu gewährleisten. Aus diesem Grund wird klar definiert, wann ein Item aus dem Sprint Backlog als fertig abgeschlossen gilt.

Der Zweck jedes Sprints ist es, Inkremente von potenziell freigebbarer Funktionalität zu liefern, die der aktuellen Definition des Scrum-Teams von “Fertig” entsprechen. Entwickler liefern in jedem Sprint ein Inkrement der Produktfunktionalität. Dieses Inkrement ist brauchbar, so dass ein Product Owner entscheiden kann, es sofort freizugeben. Wenn die Definition von “Fertig” für ein Inkrement Teil der Konventionen, Standards oder Richtlinien der Entwicklungsorganisation ist, müssen alle Entwickler sie mindestens befolgen.