Scrum Meeting

Agile Softwareentwicklung

Scrum wird vor allem in der Softwareentwicklung eingesetzt, findet aber mittlerweile in vielen Bereichen Anwendung, da es kein branchenspezifischer Prozess, sondern mehr ein Rahmenwerk für das Projektmanagement ist. Gerade in Zeiten der Digitalisierung ist eine schnelle Reaktion auf Marktveränderungen oder neu auftretende Anforderungen an das Produkt von Seiten der Kunden essentiell. Daher setzen viele Softwareagenturen und IT-Dienstleister auf die agile Softwareentwicklung mit Scrum. Alle Regeln für dieses Rahmenwerk sind im sogenannten Scrum Guide von Ken Schwaber und Jeff Sutherland festgehalten.

Neben einer festen Rollenverteilung des Teams in Product Owner, Scrum Master und Entwicklungsteam sind vor allem Scrum Meetings für die Organisation von Prozessen von großer Bedeutung. Scrum Meeting ist jedoch nicht gleich Scrum Meeting. Im Folgenden sollen die verschiedenen Arten vorgestellt werden.

Daily Scrum Meeting

Das Daily Scrum Meeting ist meistens gemeint, wenn vom Scrum Meeting die Rede ist und wird von vielen Unternehmen und Projektteams ganz unabhängig vom eigentlichen Produkt eingesetzt, auch wenn die übrigen Scrum Regeln und Parameter nicht einbezogen werden. Hierbei handelt es sich nicht um eine klassische Sitzung – im Gegenteil: Es soll sogar im Stehen abgehalten werden, um zu gewährleisten, dass alle Teammitglieder konzentriert und fokussiert bei der Sache sind und sich kurz halten. Deshalb wird es auch Daily Stand-Up Meeting genannt. Weitere Regeln beziehen sich auf die Zeit und eine festgelegte Agenda.

Scrum Daily Meeting Questions

Die Agenda bzw. der Scrum Meeting Ablauf ergibt sich aus zentralen Fragen, den 3 Scrum Meeting Questions, die alle Mitglieder des Scrum Teams der Reihe nach beantworten:

1. Was habe ich seit dem letzten Meeting geschafft?
2. Woran werde ich bis zum nächsten Meeting arbeiten?
3. Welche Probleme und Hürden stellen sich mir in den Weg, um meine derzeitigen Aufgaben zu bewältigen?

Vor allem anhand von Frage 3 ist es möglich, kleine Probleme zeitnah zu identifizieren, sodass sie nicht zu größeren Problemen werden. Außerdem haben diese spezifischen Fragen zum Ziel, das Scrum Meeting zu komprimieren und die wichtigsten Informationen auszutauschen, ohne wertvolle Arbeitszeit der einzelnen Mitglieder des Teams zu verschwenden. Um dies zusätzlich sicherzustellen, gibt es auch eine festgelegte Zeit und weitere Regeln.

Daily Scrum Meeting Rules

• Routinen etablieren
  Das Daily Scrum Meeting sollte immer zur gleichen Zeit abgehalten werden, mit den anfallenden Aufgaben vereinbar und fest im Zeitplan aller Teammitglieder verankert sein. Es sollten möglichst keine Ausnahmen gemacht und auf Verspätungen keine Rücksicht genommen werden, um keine Wartezeiten entstehen zu lassen.
• Time Boxing
  Ein Daily Scrum Meeting sollte nicht länger als 15 Minuten in Anspruch nehmen. Alle tragen dafür die eigene Verantwortung, sich möglichst an die Fragen zu halten und nicht abzuschweifen. Im Notfall kann der Scrum Master moderierend eingreifen.
• Hierarchien durchbrechen
  Der Grundgedanke von Scrum ist die Arbeit auf Augenhöhe. Dementsprechend sind auch die Meetings abzuhalten: Gerade das Daily Scrum Meeting wird von und für das Entwicklungsteam abgehalten. Tendenzen, dem Product Owner oder Scrum Master zu „berichten“, sollten erkannt und schnell unterbunden werden, um möglicherweise *Command-and-Control-*Muster zu durchbrechen.
• Relevanz für alle
  In diesem Meeting kommen bewusst nicht nur Mitarbeitende einer bestimmten Abteilung zusammen, sondern das gesamte Scrum Team. Daher sollten Informationen, die vorgetragen werden, auch für alle relevant sein und vor allem ein Hin und Her zwischen Scrum Master und der vortragenden Person vermieden werden. Sollten bestimmte Aspekte nur einzelne Personen betreffen, so sollten diese gezielt außerhalb des Daily Scrum Meetings besprochen werden. Auch durch Frage 3 identifizierte Probleme sollten hier nicht gelöst, sondern nur das weitere Vorgehen zur Lösung besprochen werden.
• Keine neuen Ideen
  Das Daily Scrum Meeting ist keine Planungssitzung. Dafür wird die Sprint Planung eingesetzt. Alles, was über die o. g. drei Fragen hinausgeht, sollte an anderer Stelle besprochen werden. Dies gilt auch für neue Aufgaben, Ideen oder Aspekte der Teamkommunikation.
• Stehen bleiben
  Auch wenn es ungewohnt erscheint, sollten sich alle daran halten, während des Meetings stehen zu bleiben, da die Kurzpräsentationen der einzelnen Teammitglieder so eine Dynamik erhalten, die der Produktivität zuträglich ist. Um gar nicht erst in Versuchung zu kommen, könnte auch ein Raum ohne Stühle helfen.

Sprint Planung

Die Sprint Planung, oft auch wie im Scrum Guide in der englischen Schreibweise „Sprint Planning“ beibehalten oder Scrum Planning Meeting genannt, ist das erste von vier Meetings eines Sprints. Dieses wird, anders als das Daily Meeting, vom Scrum Master organisiert. Sie oder er legt nicht nur die Agenda fest, sondern sorgt auch dafür, dass alle benötigten Arbeitsmittel vorhanden sind und alle Beteiligten über die Sprint Planung informiert und eingeladen werden. In Vorbereitung aktualisiert die oder der Product Owner den Product Backlog. Der Product Backlog enthält alle Anforderungen an das Product, formuliert in Aufgaben, die sich das Team der Entwickler selbst zieht. Zum Product Backlog sollten nicht nur das Team und der Product Owner einen Zugang haben, sondern alle Beteiligten, auch Kunden und andere Stake Holder. Die Anforderungen für die nächsten beiden Sprints werden vom Product Owner genauer ausgearbeitet und mit einer Priorität versehen.

Das Sprint Planning unterliegt ebenfalls einer festen Time Box, die sich allerdings anhand der Sprint-Länge berechnet. Da Sprints zwischen 2 und 4 Wochen lang sein können, kann auch die Länge des Planungsmeetings stark variieren. Ist ein Sprint für vier Wochen angesetzt, so darf das Sprint Planning max. acht Stunden beanspruchen, was der Scrum Master stets sicherstellt. Ziel einer Sprint Planung ist ein Sprint Backlog als Teil des Product Backlog.

Sprint Planning Agenda

1. Kurzer Abschluss des vorherigen Sprints: Was wurde geschafft? Welche Backlog Items sind noch offen?
2. Team-Anwesenheit während der gesamten Zeit des Sprints klären: Wer hat wann Urlaub? Fallen Feiertage in den Sprint?
3. Durchgehen der einzelnen Backlog Items: Sind alle Voraussetzungen erfüllt, dass sie bearbeitet werden können?
4. Festlegen eines gemeinsamen Sprint-Ziels (Inkrement) unter Einbezug der „Definition of Done“ (wann gilt etwas als „erledigt“?)
5. Sprint starten

Sprint Review

Ein Sprint Review Meeting findet am Ende eines Sprints statt und hat zum Ziel, den erreichten Fortschritt gemeinsam zu prüfen und die Grundlagen für die darauf folgende Sprint Planung zu bilden. Im Scrum Guide wird diese Art des Meetings als informell charakterisiert, es geht also weniger um eine Berichterstattung, sondern mehr darum, Feedback zu erhalten und kollaborative Arbeit zu bestärken.

Der Product Owner lädt das gesamte Scrum Team und eventuelle Stake Holder zum Sprint Review ein. Zu Beginn des Meetings werden alle erledigten und unerledigten Backlog Items vom Product Owner vorgestellt. Daraufhin stellt das Entwicklungsteam vor, was während des Sprints gut gelaufen ist, welche Probleme aufgetreten sind und wie diese gelöst werden konnten. Die Entwickler präsentieren außerdem das Inkrement (das lieferfähigen Zwischenprodukt, welches zum Ende des Sprints entstanden ist) und stehen für Fragen bereit. Daraufhin bespricht das Team kollaborativ, welche nächsten Schritte sinnvoll erscheinen, was die Grundlage für die Sprint Planung bildet. Außerdem werden die nächsten Schritte, sofern relevant, mit dem Markt und dem möglichen Einsatz für das Produkt abgeglichen und dementsprechend bewertet. Abschließend folgt eine Überprüfung des Zeitplans und je nach Projekt auch des Budgets, der potentiellen Eigenschaften und der Markterwartung.

Am Ende eines Sprint Reviews sollte ein aktualisierter oder umfassend umgearbeiteter Backlog vorliegen, mit dem der kommende Sprint geplant werden kann.

Sprint Retrospective

Während beim Sprint Review laut Scrum Guide auch Stakeholder anwesend sein können, ist die Sprint Retrospektive als eine Art Reflexion für das interne Team zu sehen. Zeitlich liegt sie zwischen Sprint Review und der nächsten Sprint Planung. Hierbei wird überprüft, wie der letzte Sprint für die daran beteiligten Personen, die Zusammenarbeit und Tools gelaufen ist. Positive und verbesserungswürdige Aspekte werden identifiziert, priorisiert und ein Plan zur Umsetzung von Verbesserungen erstellt. Prinzipiell können Verbesserungen jederzeit angebracht werden, die Sprint Retrospektive bietet jedoch eine formelle Möglichkeit dazu.

Scrum bei TenMedia in Berlin

Auch wir bei TenMedia folgen der Scrum Methode für die Umsetzung unserer Softwarelösungen. Gerade für die individuelle Softwareentwicklung im Kundenauftrag bietet sich die Scrum Entwicklung an, da wir so flexibel auf neue Anforderungen an das Endprodukt, die sich erst im Laufe der Umsetzung ergeben, sowie auf mögliche auftretende Probleme reagieren können. Unsere Kunden erhalten zudem einen Zugang zum Backlog und unserer Testumgebung, sodass der Fortschritt in Echtzeit mitverfolgt werden kann. Wir freuen uns über jede spannende Projektanfrage und sind jederzeit telefonisch, per Mail oder vor Ort in Berlin Mitte zu erreichen.