Wie für verteilte Teams Scrum-Meetings angepasst werden können

Auf den diesjährigen agilen Meetups, die ich besucht habe, bin ich regelmäßig über die Worthülse „Remote-Teams“ gestolpert. Remote-Teams sind Entwickler-Teams, die nicht gemeinsam im selben Büro arbeiten, sondern verteilt – nicht selten weltweit. Oft wurde gefragt, wer damit schon Erfahrungen gemacht hat. Im Gespräch hat sich ebenso oft herausgestellt, dass die Erfahrungen, die da draußen in der weiten agilen Welt gemacht werden, nicht immer positiv sind. Speziell, wenn ein Remote-Team auf Scrum trifft, scheint das hin und wieder für Unmut zu sorgen. Denn Scrum an sich ist nicht für verteilte Teams ausgelegt.

Auch wir bei Mayflower werden in unseren Projekten immer wieder vor die Herausforderung gestellt, mit externen Entwicklern auf Kundenseite und unseren eigenen Entwicklern ein großes, verteiltes Scrum-Team zu bilden. In unserem Team haben wir bei solchen Team-Zusammensetzungen in verschiedenen Projekten festgestellt, dass die Scrum-Meetings für eine gut funktionierende Remote-Arbeit unbedingt angepasst werden sollten.

Daily Scrum

Beim täglich stattfindenden Meeting Daily Scrum geht es in erster Linie um einen gemeinsamen Informationsaustausch: Wo stehen wir aktuell im Sprint, was machen wir gerade, was werden wir als nächstes tun und was behindert uns in unserer aktuellen Arbeit? Hierzu trifft sich das Team idealerweise morgens und klärt diese Fragen innerhalb von 10-15 Minuten, während man gemeinsam das Scrum Board im Blick hat. Auch ein verteiltes Team sollte auf Daily Scrum nicht verzichten. Gerade das verteilte Arbeiten macht eine Abstimmung untereinander unverzichtbar. Besonders gute Erfahrungen haben wir zum Beispiel bereits mit dem Daily Scrum über Videotelefonie gemacht. Das Team war über zwei Standorte verteilt und kommunizierte über zwei große Fernseher miteinander.

Als Ersatz für das analoge Scrum Board haben wir ein Online-Tool genutzt. In der täglichen Praxis hat sich herausgestellt, dass das Scrum Board bei entsprechender Vorbereitung der Teilnehmer für das Daily Scrum nicht zwingend nötig ist. Vorbereitung heißt, dass jeder Teilnehmer in der Lage ist, kurz und nachvollziehbar die Fragen des Daily Scrum zu beantworten. Damit immer klar ist, wer gerade reden darf, wurde zwischen den Teilnehmern ein PHP-Elefant hin und her geworfen – derjenige, der das Kuscheltier in den Händen hält, darf reden, während alle anderen Sendepause haben. Der PHP-Elefant wurde auch standortübergreifend in Richtung Kamera geworfen, sodass ein Teilnehmer auf der anderen Seite der Videotelefonie das (zweite) Kuscheltier fangen konnte und damit Redeerlaubnis erhielt. Das mag erstmal sehr spielerisch wirken, hat aber die Aufmerksamkeit der Teilnehmer erhöht und dafür gesorgt, dass die Reihenfolge der Redner immer zufällig war.

In einem anderen Projekt mussten wir leider wegen technischer Einschränkungen auf die Videotelefonie verzichten. Der kleinste gemeinsame Nenner war eine Telefonspinne. Für diese Art des Daily Scrum haben wir auf einen Moderator zurückgegriffen, da durch das Fehlen des visuellen Feedbacks ein Gesprächsleiter nötig wurde. Auch hier hat sich gezeigt, dass durch Vorbereitung der Teilnehmer sowie der Führung durch den Moderator ein Daily Scrum problemlos möglich ist. Unsere Erkenntnis ist allerdings, dass die Videotelefonie unser Mittel der Wahl für ein Daily Scrum mit einem verteilten Team ist.

Product Backlog Refinement (Grooming)

Wie der Name schon verrät, wird bei diesem Meeting der Product Backlog verfeinert. Im Backlog befinden sich alle User Stories, die vom Entwickler-Team in den kommenden Sprints umgesetzt werden sollen. Während des Refinements stellt der Product Owner den Entwicklern die User Stories vor. Die Entwickler schätzen die User Stories, formulieren sie gegebenenfalls mit dem Product Owner aus oder teilen große User Stories in meherere kleine auf. Das Meeting findet in der Regel alle 1-2 Wochen statt.

Während unserer Zeit als verteiltes Team haben wir festgestellt, dass speziell das Schätzen der User Stories schwierig ist. In der Videotelefonie sind selbst auf großen Fernsehern weder Planning-Poker-Karten noch Handzeichen gut sichtbar. Das Schätzen hatte sich dadurch nie gut angefühlt und der Mehrwert, den Schätzungen von User Stories bringen, ging verloren. Also haben wir das Schätzen von User Stories aus dem Refinement-Meeting verbannt und stattdessen das sogenannte Grüning (abgeleitet von Grooming) mit Schildchen eingeführt.

Wie bei einem normalen Refinement auch, stellte uns der Product Owner die User Stories vor. Nach der Vorstellung der User Story hielten die Teilnehmer entweder die grüne oder die rote Seite des Schildchens in die Kamera. Grün heißt, dass alles verstanden wurde und klar ist, was getan werden soll. Rot bedeutet selbstredend das Gegenteil. Sobald ein Entwickler die rote Seite des Schildchens zeigte, wurden offene Fragen geklärt und die User Story entsprechend ergänzt.

Eine verschärfte Variante des Backlog Refinements hatten wir während unserer Projektzeit, als eine Telefonspinne das Kommunikationsmittel der Wahl war. Die Frage nach Schätzungen stellte sich erst gar nicht. Dennoch mussten die User Stories regelmäßig besprochen werden. Da Telefonkonferenzen ohne Moderator gerne schnell chaotisch werden können, nutzten wir als Hilfsmittel einen Qietsche-Stern aus der Abteilung für Hundespielzeug auf beiden Seiten der Telefonkonferenz.

Der Product Owner stellte seine User Stories vor und fragte anschließend, ob es Fragen gibt. Sobald ein Entwickler eine Frage hatte, durfte er auf den Stern drücken und die Frage stellen. Um Diskussionen nicht ausufern zu lassen gab es die gemeinsame Abmachung, dass die Klärung von Fragen nach spätestens 2-3 Minuten abgebrochen, die User Story außerhalb des Refinements zwischen Fragesteller und Product Owner geschärft und erst wieder beim nächsten Refinement der großen Runde vorgestellt wird. Drückte keiner der Entwickler auf den Stern, herrschte die berühmte Stille im Walde – das Zeichen für den Product Owner, die nächste User Story vorzustellen. Das Refinement über die Telefonspinne war trotzdem anstrengend. Wurden viele User Stories vorgestellt, lies die Konzentration sehr schnell nach. Um das zu vermeiden, hatten wir beschlossen, das Refinement täglich für ca. 10-15 Minuten nach dem Daily Scrum zu machen und auf 2-3 User Stories zu beschränken. Eine gute Entscheidung, da wir dadurch in kurzer Zeit viele User Stories schärfen konnten und alle Entwickler einen relativ guten Überblick über den gesamten Backlog hatten.

Sprint Meeting

Ein verteiltes Team sollte sich regelmäßig persönlich treffen. Hierzu bietet sich das Sprint Meeting an. Es findet immer zu Beginn bzw. zum Ende eine Sprints statt. Je nach Länge der Sprints vereinnahmt das Sprint Meeting etwa einen kompletten Tag. Genug Zeit also, um das gesamte Team an einem Ort zu versammeln. Das Sprint Meeting besteht eigentlich aus mehreren einzelnen Meetings: Review, Retrospektive und Planning. Im Review werden den Stakeholdern sowie dem Product Owner die Ergebnisse des Sprints präsentiert. Die Retrospektive wird vom Scrum Team genutzt, um den vergangenen Sprint gemeinsam zu reflektieren und Verbesserungen für den nächsten Sprint zu beschließen. Das Planning dient der Planung des nächsten Sprints.

Der aufmerksame Leser wird sich sicherlich fragen, ob wir unsere User Stories noch geschätzt haben. Ja. Allerdings haben wir die Schätzung aus dem Refinement in das Planning verschoben. Das Schätzen sowie die daraus entstehenden Diskussionen und Ergebnisse fühlten sich für uns in der persönlichen Runde besser an als z.B. während der Videotelefonie. Da durch die regelmäßigen Refinements die zu schätzenden Tickets dem Team bekannt waren, wurden die Tickets nur kurz vom Product Owner vorgestellt und dann gemeinsam geschätzt. Nach der Schätzrunde wurde der Sprint wie gewohnt geplant und gestartet.

Ein Nachteil hat diese Methode allerdings: Der Product Owner muss die Sprints mit ungeschätzten User Stories planen. Dadurch kann es passieren, das zeitlich kritische User Stories schlimmstenfalls nicht wie geplant im nächsten, sondern erst im übernächsten Sprint umgesetzt werden. Dieser Nachteil kann aufgefangen werden, indem der Product Owner solche User Stories von einem einzelnen Entwickler vorschätzen lässt. Aber auch hier muss man sich im Klaren sein, dass ein Einzelner nicht alle Abhängigkeiten überblicken kann.

Fazit

Auch wenn Scrum nicht für verteilte Teams ausgelegt ist und sich sogar die Prinzipien des agilen Manifests gegen verteilte Arbeit stellen – mit ein paar Kniffen funktioniert Scrum auch mit einem verteilten Team.