A2 – alles Agile: das kleine Agile-Einmaleins.

Scrum und seine Meetings
Kommentare

Die Arbeit in Scrum- und Kanban-Teams wird durch geregelte Kommunikation entscheidend unterstützt – und zu Teilen auch erst ermöglicht. Genau dafür gibt es Meetings!

Um Iterationen effektiv planen zu können, bedienen sich Scrum und Kanban am Sprint-Planungsmeeting (Scrum) bzw. am Queue Replenishment Meeting (Kanban). Dieses forcieren der Kommunikation wird durch weitere Meetings innerhalb eines Iterationszyklus und auch im Anschluss weiter ausgebaut. Sämtliche Meetings verfolgen ein bestimmtes Ziel und dienen nicht dem Selbstzweck. Ein konsequentes Hinterfragen im gelebten Prozess ist sinnvoll, um festzustellen, ob die folgenden aufgezeigten Meetings dieses Ziel auch erfüllen.

Meetings

Im klassischen Projektumfeld und/oder auch im Unternehmensumfeld kommt es oft vor, dass Regelmeetings, die zum Statusaustausch dienen sollen, in zu großen Gruppen und in einem zu großen Zeitrahmen abgehalten werden. Auch kann oft beobachtet werden, das diese Regelmeetings wöchentlich stattfinden, in dem Glauben, einmal pro Woche wäre ausreichend; darüber hinaus scheint für mehr schlicht keine Zeit zu sein.

Was allerdings übersehen wird, ist die Tatsache, dass binnen einer Woche im Projektumfeld viel passiert und diese Informationen so auch nur einmal pro Woche an alle transportiert werden. Noch dazu in einer Gewichtung, die nicht zwingend richtig sein muss.

A2 – alles Agile ist eine Serie im zweimonatlich erscheinenden PHP Magazin.

So können zum Beispiel die Geschehnisse von gestern eher in den Vordergrund drängen als jene von vor vier Tagen, da sieschlicht bei den Teilnehmern nicht mehr so präsent im Gedächtnis sind. Auch kann so ein Meeting unter der Annahme von sechs Teilnehmern, in dem jeder Teilnehmer pro Wochentag drei Minuten spricht, 90 Minuten dauern. Die durchschnittliche Aufmerksamkeitsspanne von Menschen beträgt allerdings nur 10 bis 18 Minuten, danach schweifen die meisten gedanklich ab und können sich nicht mehr konzentrieren.

In Scrum wie auch in Kanban hat sich daher ein Daily-Regelmeeting etabliert; Scrum benennt es „Daily Scrum“, Kanban „Daily Stand-up“. In dieser Folge von A2 – alles Agile wollen wir uns mit den Meetings in Scrum beschäftigen.

Scrum vs. Kanban

  1. Scrum und seine Meetings
  2. Kanban-Meetings … und die Rollen in Scrum

Daily Scrum

Das Daily-Scrum-Meeting sollte jeden Arbeitstag um die gleiche Uhrzeit stattfinden, es sollte eine Zeit gewählt werden, zu der in jedem Fall alle Teilnehmer immer verfügbar sein können. Oft eignet sich hierzu der Zeitraum bis zu einer Stunde nach Arbeitsbeginn. Zum Daily Scrum findet sich das Entwicklungsteam zusammen mit dem Scrum Master und dem Product Owner an einem Ort ein, an dem es keine Ablenkungen wie Laptops oder dergleichen gibt. Das Meeting hat dann den meisten Effekt, wenn jeder Teilnehmer zu 100 Prozent aufmerksam ist und nicht etwa durch reinkommende E-Mails abgelenkt wird.

Die Teilnahme des Scrum Master und Product Owner an dem 15-minütigen Daily Scrum ist optional und nur dann erforderlich, wenn Backlogelemente besprochen werden, welche von diesen bearbeitet werden. Nicht optional ist die Dauer von 15 Minuten. Diese Timebox gilt es strikt einzuhalten, um die Effizienz des Meetings zu gewährleisten.

Jedes Meeting-Mitglied erhält im Scrum-Daily-Meeting die Gelegenheit, seine Tätigkeiten seit dem letzten Daily Scrum anzusprechen und zu erörtern. Neben dieser täglichen Rückschau wird auch ein Ausblick auf die geplante Tätigkeit bis zum nächsten Meeting gegeben. Legt ein Mitglied dar, dass es mit von ihm zu erledigenden Aufgaben nicht weiterkommt, weil es zum Beispiel durch andere Aufgaben blockiert ist oder die zu erledigende Aufgabe zu groß ist, wird dies vom Scrum Master und/oder vom Team aufgenommen und im Anschluss des Meetings gelöst.

Das Scrum-Meeting selbst dient lediglich dem Informationsaustausch; Probleme oder dergleichen können schon aufgrund der knappen Zeit nicht gelöst werden. Stellt der Scrum Master im Verlauf des Meetings fest, dass „sein“ Scrum-Entwicklungsteam den Sprint nicht ungestört bearbeiten kann, ist es die Aufgabe des Scrum Masters, diese Blockaden zu lösen und dem Team eine ungestörte Arbeit zu ermöglichen.

Sprint Review

Am Anfang des Sprints hat sich das Entwicklungsteam zusammen mit dem Product Owner auf User Stories und ein daraus resultierendes neues Produkt-Inkrement geeinigt, welches das Entwicklungsteam im Laufe des Sprint erarbeiten und am Ende des Sprints abliefern wird.

Diese Lieferung des Produkt-Inkrements mit den enthaltenen User Stories wird am Ende des Sprint im Sprint-Review-Meeting begutachtet, um feststellen zu können, ob das zu Sprint-Beginn gesteckte Ziel erreicht wurde. Hierzu hat unter anderem der Product Owner zu Beginn für jede User Story eine DoD (Definition of Done) hinterlegt, mit der eindeutig festgestellt werden kann, ob eine User Story den Anforderungen entsprechend umgesetzt wurde.

Wir berichten regelmäßig aus diesem Umfeld in unserer Agile-Kategorie!

Das Team präsentiert dem Product Owner und allen Stakeholdern in diesem Meeting sein geliefertes Inkrement. Hier ist auch ein Unterschied zur klassisch geführten Softwareentwicklung ersichtlich: durch das regelmäßige einbeziehen aller Stakeholder, zum Beispiel der Kunden und Endanwender, wird die Funktionalität regelmäßig überprüft und hinterfragt. Diese wichtige Feedbackrunde in regelmäßigen kurzen – kurz im Vergleich zur klassischen Entwicklung, in welcher der Endanwender erst am Ende das fertige Produkt erhält – Abständen liefert wichtigen Input für die weitere Produktgestaltung.

Es kann auch der Fall auftreten, dass zwar aus Sicht des Product Owners die Definiton of Done erfüllt ist, die implementierte User Story dennoch für den Endanwender unbrauchbar ist. Dieses Feedback nimmt der Product Owner auf und lässt es für zukünftige Inkremente in das Product Backlog, die folgenden User Stories, einfließen.

Während des Meetins ist eine weitere Aufgabe des Product Owners die umgesetzten User Stories zu begutachten und anhand der Definiton of Done zu entscheiden, ob sie abgenommen werden können oder nicht. Es kann hierbei nur ein ja oder nein als Ergebnis herausgearbeitet werden; ein „fast fertig“, ein „fertig und nicht getestet“ oder vergleichbare Zustände einer User Story führen zu einer Nichtabnahme. Diese nicht abgenommenen User Stories wandern zurück ins Product Backlog und werden vom Product Owner für den nächsten Sprint neu bewertet und priorisiert. Hauptaugenmerk in diesem Meeting sollte dennoch nicht die Abnahme der User Stories sein, sondern der Dialog mit den Stakeholdern und die Aufnahme deren Feedbacks.

Stellen Sie Ihre Fragen zu diesen oder anderen Themen unseren entwickler.de-Lesern oder beantworten Sie Fragen der anderen Leser.

Sprint-Retrospektive

Kein Sprint ist wie der vorangegangene – Anforderungen, Umfeld und Rahmenbedingungen können sich ändern. Ebenso kann es vorkommen, dass im Laufe eines Sprints festgestellt wird, dass User Stories unklar sind, das vorher geplante Techniken nicht funktionieren oder ähnliches.

In der Sprint-Retrospektive reflektiert das Scrum-Entwicklungsteam seine bisherige Arbeitsweise im Sprint und legt offen dar, was im Sprint gut war; und natürlich auch das, was nicht gut war. In diesem Meeting wird das Team ausschließlich vom Scrum Master unterstützt. In diesem vertraulichen Kreis können Kritik und unangenehme Wahrheiten besser offen geäußert, um einen Verbesserungsprozess für folgende Sprints anstoßen zu können. Das bedeutet natürlich auch, dass sie hier offen geäußert werden müssen. Verbesserungsvorschläge sind entsprechend zu dokumentieren und in den nächsten Meetings ist zu reflektieren, ob der gewünschte Effekt eingetreten ist. Der Scrum-Iterationsprozess ist eine gute Schablone für den Verbesserungsprozess im Team.

Es empfiehlt sich, pro Retrospektive besser wenige Verbesserungen herauszuarbeiten und umzusetzen, als zu viele. Diese wenigen Verbesserungen können dadurch in folgenden Meetings klarer auf ihre Auswirkung geprüft und hinterfragt werden.

Entwickler Magazin Spezial: Agilität

Seit vor vierzehn Jahren das Agile Manifesto ein neues Zeitalter einläutete, ist Agilität eines der zentralen Themen der Softwarebranche. Das Entwickler Magazin Spezial: Agilität beschäftigt sich mit den Vorteilen und Chancen, aber auch mit den Problemen und Herausforderungen, die agile Entwicklung mit sich bringt.

In diesem Teil von A2 – alles Agile haben wir uns mit den Meetings im Scrum-Umfeld beschäftig. Dabei haben wir neben dem Entwicklungsteam zwei weitere Rollen kennengelernt: Den Product Owner und den Scrum Master. Mit den Aufgaben der einzelnen Rollen werden wir uns im nächsten Teil intensiver beschäftigen. Außerdem werden wir uns ansehen, welche Meetings den hier vorgestellten im Kanban entsprechen.

 

Aufmacherbild: Rugby players fighting for ball via Shutterstock / Urheberrecht: melis

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -