Bei YMC setzen wir nun schon seit über einem Jahr fortwährend Distributed Scrum als Framework für unseren Entwicklungsprozess bei einem Kundenprojekt ein. Unser Scrum-Setup zeichnet sich in diesem Fall durch eine geringe Distanz zwischen den Standorten aus, da sich sowohl der Kunde wie auch wir als Beratungs- und Entwicklungsdienstleister mit jeweils einem Standort in der Metropolregion Zürich befinden. Die geringe Distanz ermöglicht uns ohne viel Aufwand zumindest zeitweise die Colocation aller Teammitglieder an einem einzigen der beiden Standorte.

Colocation, in welchem Ausmass auch immer (ständig oder nur zeitweise), ist auch grundsätzlich eine gute Sache. Schliesslich ist in der agilen Softwareentwicklung so viel Colocation wie nur möglich erwünscht. Allerdings konnten wir im Projektalltag mittlerweile auch eine Gefahr ausmachen, die eine zeitweise, d.h. partielle, Colocation in Distributed Scrum mit sich bringt: Dass Distributed Scrum bei seiner Implementierung nicht als solches, sondern als “Remote Scrum” wahrgenommen wird…

Distributed Scrum ganz klassisch

Die meisten Best Practices zu Distributed Scrum gehen von einer grossen Distanz zwischen den Standorten aus – und damit oftmals auch von bestimmten Beweggründen warum Distributed Scrum Anwendung findet. So werden in einschlägiger Scrum-Literatur, wie z.B. A Practical Guide to Distributed Scrum und The Distributed Scrum Primer, meistens zwei typische Motivationen für eine im Extremfall über mehrere Kontinente verteile Entwicklung angeführt:

  • Offshoring bzw. Outsourcing
  • die Möglichkeit bis zu 24 Stunden pro Tag ohne Unterbrechung entwickeln zu lassen

Zweifelsohne sind in diesem Zusammenhang die verschiedenen Zeitzonen, Sprachen und kulturellen Gewohnheiten schwerer wiegende Aspekte als die Frage, ob sich Colocation nun überhaupt nicht oder partiell ereignet. Und so kann man sich eigentlich glücklich schätzen, wenn Herausforderungen wie ungleiche Arbeitszeiten oder sprachliche bzw. interkulturelle Verständnisschwierigkeiten gar nicht erst von Belang sind. Andererseits steht man aber ohne erprobte Best Practices da, die speziell für ein Distributed Scrum mit partieller Colocation gelten. Lediglich dass sich Colocation bei einer geringen Distanz zwischen den Standorten ganz allgemein “aufdrängt” ist klar, mehr aber auch nicht.

Distributed Scrum vs. Scrum

Als wir als Dienstleister gemeinsam mit dem Kunden, der bereits Scrum einsetzte, die Entscheidung trafen, auf Distributed Scrum zu “wechseln”, taten wir das in vollem Bewusstsein darüber, dass bislang weder wir noch der Kunde damit praktische Erfahrung hatten. Ob zeitweise – und wenn ja, wie oft – Colocation stattfinden sollte, war zu Beginn noch offen. Lediglich die Entwicklungsstandorte (beim Kunden und bei YMC) und die Anzahl der Scrum Teams (zwei) standen fest. Ferner verblieben Product Owner und Scrum Master fix beim Kunden.

Gezwungenermassen verorteten wir also das abgeänderte Scrum-Setup als Sonderfall irgendwo graduell zwischen klassischem Distributed Scrum ohne jegliche Colocation und klassischem Scrum mit ständiger Colocation. Unter der Devise “Inspect & Adapt” und dem Konzept selbstorganisierender Teams überliessen wir es zunächst den durch das Management vorgegebenen Rahmenbedingungen im jeweiligen Sprint und den persönlichen Präferenzen der einzelnen Teammitglieder, von welchem der beiden Standorte aus sie entwickelten.

Distributed Scrum vs. “Remote Scrum”

Schnell kristallisierte sich eine erste Best Practice heraus: Colocation soll an Tagen stattfinden, an denen auch das Sprint Planning, das Sprint Review oder die Retrospektive stattfindet, während es dagegen für das Daily Scrum und Grooming-Meetings ausreicht, beide Standorte virtuell per Videokonferenz-Tools zusammenzuführen. Nach und nach stellten wir aber fest, dass wir damit ein grundlegendes Problem bezüglich der (Selbst-)Wahrnehmung der Scrum Teams geschaffen haben: Diese variierte sowohl unter den Teammitgliedern wie auch unter aussenstehenden Stakeholdern beträchtlich. Im wesentlichen waren hierbei zwei Ansichten vertreten:

  1. Ansicht Distributed Scrum: Bei den Scrum Teams handelt es sich jeweils um ein Distributed Team mit zeitweiser Colocation.
  2. Ansicht Remote Scrum: Bei den Scrum Teams handelt es sich jeweils um ein Colocated Team, bei welchen einzelne Teammitglieder zeitweise “remote” arbeiten.

Im Nachhinein betrachtet sprach für die Distributed-Scrum-Ansicht die deutlich geringere Anzahl von “Colocated-Tagen” gegenüber “Distributed-Tagen”, für die Remote-Scrum-Ansicht hingegen die Regelmässigkeit der Colocated-Tage – nämlich jeweils zum Sprintanfang und -ende. Jedenfalls dominierte zunächst die Remote-Scrum-Ansicht, was die Implementierung unseres Distributed Scrum zu folgendem (Zwischen-)Stand führte:

Das Scrum Team war sich zwar bewusst, dass es neben einem On-Site-Standort noch einen Off-Site-Standort gibt. Es war sich damit aber nicht zwangsweise auch bewusst, dass es aufgrund der (regelmässigen) Remote-Arbeit durchgehend bestimmte On-Site-Entwickler und bestimmte Off-Site-Entwickler unter den Teammitgliedern gibt. Letztere bildeten praktisch unvermeidbar ein Sub-Team, das vom “gelebten Scrum” – sprich Remote Scrum – nicht als solches erfasst wurde und selbst dann noch fortbestehen blieb, wenn die Off-Site-Entwickler mal wieder on-site arbeiteten. Aus diesem Grund sind auch erst einige Sprints verstrichen, bis wir wiederkehrende Impediments identifiziert haben, die ansonsten auch schon nach ihrem erstmaligen Auftreten in der Retrospektive identifiziert werden hätten können. Zu diesen Impediments zählten:

  • Mit der Begründung dass die Remote-Arbeit nicht ständig stattfindet, “existierte” der Off-Site-Standort nur in den Phasen, in denen tatsächlich auch Remote-Arbeit stattfand: Er wurde wiederholt ad-hoc eingerichtet und Prozessoptimierung wurde dort nur während den Remote-Phasen praktiziert.
  • Mit der Begründung dass es weniger Off-Site- als On-Site-Entwickler gibt, wurde dem Off-Site-Standort selbst während der Remote-Phasen weniger Beachtung geschenkt: Es wurde ignoriert, dass die Entwickler dort ebenso auf eine gleichwertige Ausstattung mit Arbeitsmitteln und Büroraum angewiesen sind. Ein Off-Site-Entwickler war somit nicht gleichermassen wie ein On-Site-Entwickler facilitated.
  • Es kam vor, dass statt zwischen den beiden Standorten zu kommunizieren, direkt zwischen einem einzelnen On-Site- und einem einzelnen Off-Site-Entwickler kommuniziert wurde, so dass alle anderen Teammitglieder diese Kommunikation nicht mitbekommen haben (bzw. nur die eine Hälfte des Gesprächs). Dadurch gingen die Vorteile eines informellen Informationsflusses verloren, welcher üblicherweise in einem Colocated Team (das sich im selben Büroraum befindet) auftritt.

Distributed Scrum vs. Remote Scrum

Lessons Learned

Das zeigt, wie wichtig es ist, dass man von Anfang an ein team- und organisationsweites Bewusstsein dafür schafft, dass Distributed Scrum als Prozessansatz verfolgt wird. Es sollte erst gar niemand auf die Idee kommen, (unbewusst) Remote Scrum einzusetzen, d.h. klassisches Scrum je nach Bedarf sukzessive um einzelne Practices für Remote-Arbeiten zu erweitern. Insbesondere am fehlenden informellen Informationsfluss als Impediment sieht man, dass das schnell einen negativen Effekt haben kann: Die Practice ein Videokonferenz-Tool für die Kommunikation zwischen zwei Entwicklern einzusetzen mag ausreichend sein um Face-to-Face-Kommunikation zwischen zwei Entwicklern an unterschiedlichen Standorten zu ermöglichen, aber sie vernachlässigt die “ungeplante” Kommunikation innerhalb des gesamten Teams komplett. Für Distributed Scrum ist es die eigentlich richtige Practice, (zusätzlich) ein Videokonferenz-Tool für die Kommunikation von Standort zu Standort einzusetzen – beispielsweise durch eine Hardware-Lösung für Videokonferenzen, dessen Kamera, Mikrofon und Lautsprecher den ganzen Büroraum abdecken. (Und tatsächlich beschlossen wir letztendlich, an beiden Standorten in solch eine Hardware-Lösung zu investieren.)

Die partielle Colocation ist nun gerade deshalb so gefährlich, weil sie das “Abrutschen” in Remote Scrum besonders verlockend macht. Einfach aus dem Grund, da sie die Abgrenzung von Scrum zu Distributed Scrum nicht deutlich genug macht. Auch wenn sie die Kollaboration im Team erleichtern mag, so erschwert Colocation zunächst, das Bewusstsein für Distributed Scrum zu schaffen. Will man sich von Scrum zu Distributed Scrum bewegen, so sollte man daher in Betracht ziehen, sich mit Colocation vorerst zurückzuhalten. Lässt man das Team ein oder mehrere Sprints lang ein klassisches Distributed Scrum Team ohne jegliche Colocation sein, so ist sichergestellt, dass für jeden im Team der Wechsel wahrnehmbar ist.

Und auch wenn es trivial erscheinen mag: Es ist sicherlich hilfreich, wo auch immer möglich ausdrücklich von “Distributed Scrum” (statt nur “Scrum”) zu sprechen, so dass jedem Teammitglied immer wieder erneut in Erinnerung gerufen wird, dass es Teil eines Distributed Team ist.

0 Kommentare

Einen Kommentar abschicken

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *