23.07.2020
in Methods
Scrum remote – so nah und doch so fern
Inhaltsverzeichnis
Zu dem Thema Videokonferenzen und Remotemeetings ist in der letzten Zeit aus naheliegenden Gründen schon sehr viel publiziert worden. Naheliegendes, Überraschendes, Hilfreiches und – nun ja. Auch das Thema Herausforderungen des Home-Office and beyond scheint schon ausführlich aus allen Perspektiven betrachtet. In diesem Blogpost soll es also nicht in erster Linie um diese eher allgemeinen Themen gehen, sondern um Scrum im Remotebetrieb am Beispiel unseres Unternehmens – also ganz konkret und hands-on: Wie geht Cloudogu die Thematik bei agilem Arbeiten an?
Auch wir befinden uns seit Mitte März komplett im Home-Office mit gleichbleibendem oder sogar zunehmendem Workload inklusive des Onboardings neuer Kollegen. Zusammenfassend kann man sagen, dass uns der Übergang eher leicht gefallen ist, da wir schon zuvor viele der Möglichkeiten von Googles G Suite genutzt haben, so dass Handling, Funktionen und Prozesse der Tools schon bekannt und erlernt waren, die Einstiegshürde in Bezug auf das Tool war also relativ niedrig. Zudem hatten wir auch schon vor der Corona-Zeit eine Reihe von Remote Mitarbeitern, die bestens integriert waren, dadurch konnten wir auch hier schon auf Erfahrungswerte zurückgreifen. Ein gut eingeführtes und selbsterklärendes Tool ist natürlich hilfreich, aber aus den zahlreichen Angeboten (Mural, Miro, Conceptboard, Zoom etc.) kann sich jeder das passende für das eigene Unternehmen heraussuchen – hier ist auch ein wenig Experimentierfreude und „Inspect and Adapt” gefragt. Und vor allem: Nachsicht, wenn mal etwas nicht auf Anhieb reibungslos funktioniert.
Aber nun zurück zum Thema: Scrum remote. Und wie ist das überhaupt: lebt die agile Organisation nicht vor allem vom Thema Kommunikation und Interaktion und damit zwangsläufig von persönlicher Nähe? Kann das in der Übertragung ins Home-Office funktionieren?
Scrum Artefakte
Die meisten professionell mit Scrum arbeitenden Unternehmen werden sicher einen Issue Tracker wie Jira oder Redmine benutzen, so dass es in Bezug auf Product und Sprint Backlog keinerlei Unterschiede zum Arbeiten vor Ort gibt. Auch das Burndown-Chart stellt der Issue Tracker zur Verfügung, um den täglichen Fortschritt im Sprint zu verdeutlichen und Impediments aufzudecken.
Einige Scrum Events im Detail – meine subjektive Sicht als Scrum Master
Bei den Scrumereignissen sind wir mit der eigentlichen Herausforderung konfrontiert, die auch einen deutlichen Unterschied zur Arbeit vor Ort darstellen. In allen Meetings haben wir eine Google Meet-Videokonferenz hinterlegt, das Tool kommt mit der Anzahl der Teilnehmer gut zurecht, wird ständig optimiert (z. B. die Kachelansicht der Teilnehmer ohne Add On) und ist leicht zu bedienen. Schön finde ich beispielsweise die automatische Stummschaltung neuer Teilnehmer bei der Überschreitung einer bestimmten Personenzahl, so gelingt es von Anfang an, die Geräuschkulisse niedrig zu halten.
(Details über die Kachelansicht in Google Meet)
Eine Quelle von Ablenkung ist hingegen der integrierte Chat, außer hilfreichen Anmerkungen existieren hier zuweilen Paralleldiskussionen, die unter Umständen vom eigentlichen Thema wegführen – hier ist der Moderator gefordert. Vor Ort unterstützen wir das Zeitmanagement zumeist mit einem TimeTimer als kleinem Nudging-Tool, bei Notwendigkeit nutze ich ein Online-Tool auch remote, bei wechselnden geteilten Screens ist das zum Teil aber problematisch und nicht immer einfach.
Kleiner Tipp an Rande: Durch Eingabe einer Zahl nach Slash in der URL kann man die eingestellte Zeit bestimmen – ohne Mauseinsatz (also z.B. http://visualtimerapp.com/20).
Nun zu ausgewählten Events im Einzelnen:
Daily
Beim Daily teile ich als Scrum Master in den meisten Fällen meinen Screen und zeige das Taskboard des aktuellen Sprints, welches auch beim Daily vor Ort an einem großen Plasmabildschirm dargestellt wird. Wenn einzelne User Stories benannt werden, klappe ich diese auf, um die einzelnen Tasks und den jeweiligen Status zu teilen. Beim Daily hat sich zudem etabliert, die Kollegen in einer bestimmten Reihenfolge zu Wort kommen zu lassen, so dass niemand überrascht ist, dass er/sie plötzlich an der Reihe ist. Somit kann man hier die Rüstzeiten auf ein Minimalmaß reduzieren. Manche Teams ziehen statt der Abfrage der drei bekannten Fragen (siehe Kasten) der einzelnen Kollegen ein „Walk the Board” vor, um vor allem den Ticketfortschritt im Blick zu behalten. In diesem Fall gehe ich das Board von oben nach unten durch, wir besprechen kurz jedes Ticket und am Ende des Daily wird die anstehende Arbeit aufgeteilt, so dass jeder versorgt ist.
Recap: 3 Fragen im Daily
Ausführlich im Scrum Guide beschrieben als:
„Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen? Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen? Sehe ich irgendwelche Hindernisse [Impediments], die mich oder das Entwicklungsteam vom Erreichen des Ziels abhalten?”
Ausführlich im Scrum Guide beschrieben als:
„Was habe ich gestern erreicht, das dem Entwicklungsteam hilft, das Sprint-Ziel zu erreichen? Was werde ich heute erledigen, um dem Entwicklungsteam bei der Erreichung des Sprint-Ziels zu helfen? Sehe ich irgendwelche Hindernisse [Impediments], die mich oder das Entwicklungsteam vom Erreichen des Ziels abhalten?”
Da wir das Sprintziel nicht mehr physisch in den Entwicklungsräumen aushängen können, habe ich mir angewöhnt, es zweimal im Laufe eines zweiwöchigen Sprints am Ende des Daily kurz gemeinsam mit den Retromaßnahmen zu zeigen, so dass wir auch hier eine Fokussierung beibehalten können.
Am Ende der Daily zeige ich den jeweiligen Burndown-Chart und frage die Product Owner, ob es noch Ergänzungen oder neue aktuelle Entwicklungen und Anmerkungen gibt. Es zeigt sich, dass sich die verbindliche Zeitvorgabe von 15 min auch remote gut halten lässt.
Oft kommt es im Daily zu gemeinsamer Verabredung von Abstimmungen, Meetings oder Pair Programming, so dass die Kommunikation auch während des Tages gewährleistet ist. Experimentiert haben wir auch schon mit einem permanent geöffneten Meetingraum, um ein wenig Büroatmosphäre in das Home-Office zu tragen. Es hat sich aber schnell gezeigt, dass der Raum bisher nicht genutzt wurde, da es sinnvoller erscheint nach einer kurzen Absprache im Chat direkt ins Pair Programming zu gehen oder ähnliche Formate zu nutzen.
Sprint Planning
Im Sprint Planning I („Was soll im kommenden Sprint umgesetzt werden?”) teilt der Product Owner den Screen und fragt zunächst die verfügbare Kapazität der einzelnen Teammitglieder ab. Danach wechseln wir in den Issue Tracker (in unserem Falle Redmine) und gehen alle für den Sprint vorgeschlagenen Tickets durch. Die meisten Tickets entsprechen durch das Backlog Refinement schon der teamspezifischen „Definition of Ready”, einige wenige Tickets müssen im Planning noch verfeinert werden. Im Backlog Refinement werden die User Stories zumeist nur nach T-Shirt-Size geschätzt, im Sprint Planning nehmen wir eine Schätzung in Story Points in Relation zu allen im Sprint eingeplanten User Stories vor.
Planning Poker mit der Chat-Funktion – kann man machen!
An diesem Zeitpunkt des Sprint Planning I hatten wir vor Ort aus Gründen der Effizienz auf Magic Estimation gesetzt (z. B. https://scrum.wertikalwerk.com/toolbox/magic-estimation/). Bei einem Remote Planning wäre ein analoges Vorgehen mit einem Wechsel des Mediums und starken Redundanzen sowie mit vergrößerten Rüstzeiten verbunden (z.B. Übertragung der einzelnen User Stories auf Notizen in einem Google Jamboard), daher verwenden wir hier ein klassisches Planning Poker (z. B. https://www.projektmagazin.de/glossarterm/planning-poker). Zu diesem Zweck wird die Chatfunktion des Meetingtools eingesetzt: wenn alle Teilnehmer der Meinung sind, dass die Story hinreichend klar ist, wird zeitgleich eine Storypoint-Schätzung im Chat gepostet. Die Kollegen mit den niedrigsten und höchsten Schätzungen tauschen sich aus bis ein Konsens gefunden ist. Die Storypoints werden nun direkt im Issue Tracker eingetragen. Sind alle Stories geschätzt, zieht sich jeder die Stories, die er gerne im nächsten Sprint bearbeiten möchte, in dem er sich direkt als Bearbeiter im Issue Tracker einträgt. Ein zu viel oder zu wenig an Workload wird auf diese Weise transparent. Unter Beachtung der durchschnittlichen Velocity der letzten Sprints wird nun eine realistische Einschätzung vorgenommen, ob der Scope geschafft werden kann und in Diskussion mit dem PO auf ein gutes Maß reduziert, mit dem sich Jeder wohlfühlen kann und das dennoch ambitioniert ist.
Im Anschluss daran wird das Sprintziel festgelegt. Im Sprint Planning II („Wie sollen die eingeplanten Stories umgesetzt werden?”) finden sich einzelne Gruppen von Entwicklern in eigenen Meetingräumen zusammen und führen den Taskbreakdown durch. Diese Tasks werden im Laufe des Sprints noch verfeinert bzw. ergänzt. Product Owner und Scrum Master sind bei uns beim Planning II meist nicht mehr zugegen.
Sprint Review
Das Sprint Review mit knapp 30 Teilnehmern fühlt sich fast wie „vor Ort” an. Auch vor den Corona-Maßnahmen haben die Kollegen bei Vorstellung Ihrer Features den Bildschirm geteilt und die neue Funktionalität vorgeführt. Zudem hatten wir gerade bei diesem Event schon immer relativ viele Remote Teilnehmer, so dass das Event sich nicht ungewohnt „anfühlt”. Im Gegenteil, mein Eindruck ist, dass es sogar etwas stringenter und geregelter abläuft als zuvor und einen höheren Erkenntnisgewinn zeigt. Rückfragen können ebenfalls gut platziert werden: hier wird häufig die – von mir oben kritisierte – Chatfunktion verwendet, um die Präsentation nicht zu stören. In diesem Falle stellt diese eine gute Alternative zur Zwischenfrage bzw. Kommentar dar.
Sprint Retrospektive
Dies ist aus meiner Sicht das Format mit den größten Stolpersteinen in seiner Remoteausprägung. Da hier durchaus auch einmal emotionale Themen besprochen werden, ist der Verzicht bzw. die Reduktion der Möglichkeiten auf körpersprachliche Signale einzugehen ein echtes Manko. Bei stärkeren Emotionen ist es zudem nicht immer einfach, die Kollegen zu bewegen, einander ausreden zu lassen bzw. nicht zeitgleich vorzupreschen. Allerdings habe ich wahrgenommen, dass mit der Routine sich auch hier ein sensibles Miteinander herauskristallisiert. Beim Tooling haben wir zunächst ein wenig experimentiert, sind am Ende aber in der Nutzung von Google Presentation als Whiteboard und Google Meet angekommen. Die Google Presentation-Charts können gemeinsam und in Echtzeit bearbeitet werden und bieten einige Möglichkeiten, die über ein reines Jamboard oder Google Draw hinausgehen und dennoch keine hohe Einstiegshürde haben. Das Tool soll sich natürlich anfühlen und nach Möglichkeit selbsterklärend sein. Wir versuchen, den Ablauf einer schon eingeführten Retro vor Ort nachzuempfinden, steigen bei „Set the Stage” mit dem „Wetterbericht” ein, jeder Teilnehmer verschiebt seinen Token in Google Presentations und berichtet, wie er die letzte Iteration empfunden hat. Vor Ort gleichen wir das meistens zusätzlich mit dem „Happiness Radar” ab, auf den wir bei den meisten Teams in der Home-Office-Variante verzichten, da er digital seine Leichtigkeit und Beiläufigkeit verliert.
Nach Betrachtung der Wirksamkeit der Maßnahmen aus der letzten Retrospektive steigen wir ein in die Detailbetrachtung: Liked, Lacked, Learned. Die Teilnehmer der Retro bereiten in einem definierten Time-Slot die Karten auf einem eigenen Chart vor und kopieren sie dann erst in das Sammel-Whiteboard. Dies ist ein Learning aus den ersten Remote-Retros: wenn alle Teilnehmer sehen, was die Kollegen gerade schreiben, ist die Ablenkung und Beeinflussung immens. Obendrein ist es sinnvoll, die Anzahl der Karten zu begrenzen – wenn alle damit einverstanden sind. So ist jeder zu einer Fokussierung und Priorisierung gezwungen und das spätere Clustern der Cards einfacher. Zudem ist es leichter und schneller, in einem SW-Tool Karten zu schreiben als Vor-Ort auf Haftnotizen oder Metaplankarten – rasch ist man bei 10 Karten pro Teilnehmer, was Raum und Zeit sprengt. Wir pendeln uns gerade auf ca. 4 Karten pro Kollegen ein, ohne das übermäßig restriktiv zu sehen. Wenn Bedarf nach Platzierung weiterer Themen besteht, ist das auch in Ordnung. Wenn alle Karten platziert sind, versuchen wir gemeinsam Cluster zu finden und hängen die Karten entsprechend um.
Nach anschließendem Dot-Voting gehen wir in die Diskussion der hoch priorisierten Themen und leiten daraus Maßnahmen ab. In einem meiner Teams überträgt ein zeichnerisch begabter Kollege die Maßnahmen auf ein Flipchart und stellt eine Fotografie davon im Chat zur Verfügung, durch die kleinen Illustrationen und Visualisierungen bleiben so die Maßnahmen prägnanter im Gedächtnis. Zudem haben wir hier auch eine größere Analogie zum Format vor Ort, wo am Ende die Maßnahmen ebenfalls auf einem Flipchart gesammelt werden, das anschließend im gemeinsamen Büro aufgehangen wird.
„Hey, das ist meine Karte!” – der Homo ludens bei der Arbeit
Als wichtiges Learning für mich bei der Nutzung eines solchen Formates mit einem gemeinsam benutzten Tool leite ich ab: Unbedingt Spieltrieb der Kollegen bremsen! „Du hast meinen Punkt geklaut!” und „War das eben nicht noch blau?” sind typische Redebeiträge, auch „Umbauten” des ganzen Charts werden gerne vorgenommen. Funny, aber manchmal nicht zielführend… Schade ist remote zudem der Verzicht auf die gemeinsamen Süßigkeiten, die ansonsten in jeder Retro bereitstehen! ;-)
Ausblick
Interessant wird es werden, wenn wir zukünftig ins Büro zurückkehren: die Wahrscheinlichkeit ist groß, dass der Anteil an Home-Office-Nutzern steigt, dann sind wir mit den noch ganz anderen Herausforderungen eines Hybridformates konfrontiert: Challenge accepted!
Jetzt Newsletter abonnieren
Verpassen Sie nicht die neusten Informationen zur Digitalen Transformation, Ankündigungen von Produktneuheiten und Sonderaktionen.
