Verteilte Entwicklung mit Scrum in der Praxis

Seit mehr als einem Jahr führe ich nun ein verteiltes Entwicklungsteam. Die Entwickler sind dabei auf drei Standorten verteilt:

  • Graz: 3 Entwickler
  • Cluj (Rumänien): 2 Entwickler
  • Brasov (Rumänien): 1 Entwickler

Keine optimale Situation für ein Scrum Team, aber dafür umso herausfordernder! In diesem Blogpost möchte ich den Lernprozess, den ich und das Team die letzten Monate durchlaufen haben kurz skizzieren.

Initiales Teambuilding und Ramp-up

Da das Team rasch an Performance zulegen musste wurde für das initiale Ramp-up ein 2-monatiger Aufenthalt des gesamten Teams in Graz vorgesehen. In dieser Phase wurden die externen Kollegen aus Rumänien mit unserer Arbeitsweise, dem Projekt und der Business Domäne vertraut gemacht. Berührungsängste konnten so rasch abgebaut werden. Ein erstes Kennenlernen konnte stattfinden und das Teamgefühl wurde initial geprägt.

Verteilung auf drei Standorte

Nachdem das erste Ramp-up gut verlaufen war verteilten sich die Teammitglieder auf die drei Standorte. Es wurde vereinbart alle 6 Monate für einen Sprint (2 Wochen) wieder an einem der Standorte zusammenzukommen um das Teamgefühl wieder zu stärken. Was zu Beginn bereits kritisch beurteilt wurde, war die Tatsache, dass ein Entwickler alleine in Brasov stationiert war und dadurch nicht nur die Komplexität des Teams stieg sondern auch das Teamgefühl für ihn verloren ging. Diese Kritik sollte sich später noch bestätigen.

Technische Hilfsmittel

Um die Zusammenarbeit über drei Standorte zu ermöglichen sind technische Hilfmittel unverzichtbar und maßgeblich für den Erfolg oder Misserfolg verantwortlich. Es war klar dass wir ohne Audiocalls und Screensharing nicht arbeiten konnten. Später stellte sich heraus, dass Videocalls einen erheblichen Mehrwert für die ohnehin eingeschränkten Kommunikationsmöglichkeiten lieferten. Digitale Whiteboards, Jira + Greenhopper Plugin und Confluence waren weitere Werzeuge, die analoge Tools ersetzten. Das Problem ist, dass digitale Tools wesentlichen unflexibler und umständlicher sind und viel mehr Disziplin bei der Benutzung erforderlich ist als das bei analogen Tools der Fall ist. Weiters gehören Headsets, Polycoms und Webcams in verteilten Teams für jedes Teammitglied zur Basisausstattung.

Kommunikation

In der modernen Softwareentwicklung steht und fällt ALLES mit der Kommunikation. Neben der eingeschränkt spürbaren Teamdynamik liegt in der Kommunikation die Haupt-Einschränkung von verteilten Teams. Technische Hilfmittel sind letztlich zwar die “Enabler” für Kommunikation, können aber die fehlende physische Präsenz nicht vollständig kompensieren. Es geht also darum das Optimum aus der weniger optimalen Lage herauszuholen. Probleme von verteilten Teams in Bezug auf Kommunikation sind:

  • Es wird viel zu wenig kommuniziert!
  • Selbst das Aufsetzen eines Headsets, das Einschalten einer Kamera, das Drücken eines “Anrufen” Buttons, etc können bereits ein ausreichendes Hindernis zur Kommunikation darstellen
  • Entwickler an verteilten Standorten fühlen sich tendenziell weniger  stark verantwortlich, als jene, die mit dem Team vor Ort sind
  • Die Kommunikation ist zu hundert Prozent von der Technik abhängig
  • Viele Menschen fühlen sich nicht wohl wenn sie gefilmt werden (Videocalls) oder über Mikrofon sprechen müssen und unterlassen es deshalb einfach
  • Ein Großteil der Kommunikation, der über Mimik und Gestik stattfindet geht verloren (trotz Audio & Videocalls)
  • Digitale Tools (Whiteboard, Korbboard, Texteditor,…) sind umständlicher zu bedienen als Analoge und werden daher weniger oft zur Unterstützung verwendet

Die Zusammenkünfte

Wie eingangs erwähnt wurde vereinbart, dass sich das Team in Abständen von etwa 6 Monaten an einem Standort treffen sollte um einen Sprint gemeinsam zu arbeiten. Retrospektiv waren die zwei Zusammenkünfte die mit Abstand produktivsten Sprints, die ich mit dem Team erleben durfte. Die Zusammenfkunft hatte aber nicht nur auf die Velocity (die sich jeweis fast verdoppelte) eine positive Wirkung. Es wurden auch Social Events durchgeführt, was das Team stärker zusammenwachsen ließ. Es zeigte auch die Leistungsfähigkeit des Teams unter verbesserten Bedingungen für alle Teammitgleider auf. Letzlich gaben die Zusammenkünfte dem Team einen immensen Energieschub, der sich jedoch langsam bis zur nächsten Zusammenkunft wieder abschwächte und wieder eine Auffrischung brauchte.

Lessons Learned

  • Initiales Teambuilding und Ramp-up sind gemeinsam an einem Standort effizient durchführbar
  • Zusammenkünfte in regelmässigen Abständen liefern einen nachhaltig andauernden Energieschub für das Team und sind für länger existierende verteilte Teams unverzichtbar
  • Videocalls stärken das Teamgefühl und erhöhen die Qualität der Kommunikation
  • Kommunikations-Tools müssen vorab getestet und das richtige Set an Werkzeugen (abhängig von OS, Anforderungen,…) für das Team ausgewählt werden
  • An einem Standort sollte immer ein Sub-Team von mindestens zwei Entwicklern existieren
  • Verteilung über mehr als zwei Standorte sollten vermieden werden
  • Der Scrum Master muss sicherstellen, dass sich jeder im Team mit allen Stakeholdern  kommunizieren kann (Direkt Kontakte austauschen)
  • Verteilte Teams braucht pro-aktive Kommunikatoren mehr als jedes andere Team – introvertierte Personen sind für verteilte Teams nicht geeignet.

Next Steps

  • Ein ständig offener Kommunikationskanal (Audio + Video 24h eingeschaltet) zwischen den verteilten Sub-Teams soll die Teams noch stärker zur Kommunikation anregen und Kommunikationsbarrieren weiter minimieren.
  • Dauerhaftes Pair-Programming (8h pro Tag), wobei ein Paar aus einem Entwickler aus Graz und einem aus Rumänien besteht, um Wissen und Arbeitsweisen stärker auszutauschen und die Kollaboration über die geografische Grenze hinweg zu forcieren.
Advertisements

Published by

Stefan Wunder

My name is Stefan Wunder and I am a passionate Lean & Agile Coach from Graz, Austria. I have been applying Lean & Agile methodologies in various industries and contexts since 2006. Since 2014 I am working as Agile Coach at AVL List GmbH, the world’s largest independent company for development, simulation and testing technology of powertrains (hybrid, combustion engines, transmission, electric drive, batteries and software) for passenger cars, trucks and large engines. I have a Master of Science in software development and business economics. I am Certified Systemic Coach, Certified Scrum Professional (CSP), Certified Scrum Master (CSM), Certified SAFe Program Consultant (SPC) and Certified LeSS Practitioner. I am speaker at conferences, and moderator of the Scrum User Group Graz.

10 thoughts on “Verteilte Entwicklung mit Scrum in der Praxis”

  1. Prima Zusammenfassung. Ich bin schon lange an Erfahrungsberichten zu diesem Thema interessiert.

    Bei euch kam erschwerend hinzu, dass eure Muttersprachen unterschiedlich waren. Die Sprachbarriere verhindert ja leider auch allzu oft die Kommunikation zwischen den Teammitgliedern. Hier wäre jetzt ein Vergleich interessant zu einem rein deutschsprachigen Team.

    Was mich noch interessiert:

    * Ist es (oft) vorgekommen, dass ein Entwickler vor irgendeinem unbekannten technischen Problem stand, bei dem man ihm aus der Entfernung nur schlecht helfen konnte?

    * Habt ihr mit bestimmten Maßnahmen sicherstellen müssen, dass bei solchen Meetings wie Sprint-Planung und Estimation nicht alle durcheinanderquatschen? Im Team Collect war das ja schon nichtverteilt ein Problem. Und dieses Problem wird umso größer, je extrovertierter die Teammitglieder sind. Und das hattest du aber ja an anderer Stelle als Vorteil herausgestellt.

    1. Vielen Dank, Thomas!

      Zu deinen Punkten:

      Bei euch kam erschwerend hinzu, dass eure Muttersprachen unterschiedlich waren.

      Danke, dass du die Sprachbarriere ansprichst. Ich hatte bei uns allerdings nicht das Gefühl, dass weniger Kommuniziert wurde weil Englisch gesprochen wurde. Vermutlich liegt es daran, dass fast alle Teammitglieder bereits in internationalen Teams gearbeitet haben und es dadurch weniger Hemmungen gab. Das könnte bei unerfahrenen Teammitgliedern ein größeres Problem sein. Kleinere Probleme in diesem Bezug gab es jedoch mit deutschen Fachbegriffen in User Stories, die von den Rumänen nicht verstanden wurden. Da musste dann jemand aus Graz aushelfen und ihnen die Begriffe und Zusammenhänge erklären, was Zusatzaufwand ist.

      Ist es (oft) vorgekommen, dass ein Entwickler vor irgendeinem unbekannten technischen Problem stand, bei dem man ihm aus der Entfernung nur schlecht helfen konnte?

      Das eigentlich Problem in diesem Zusammenhang lag meist darin, dass remote Entwickler zu lange selbst erfolglos nach Lösungen suchten bevor sie um Hilfe angefragt haben. Bei der eigentlichen Problemlösung war zwischen remote und lokalen Entwicklern kaum ein Unterschied zu bemerken. Hier leisten die Tools gute Arbeit. Pair Programming ist für uns die effizienteste Lösung um vorhin genannte “Stehzeiten” zu vermeiden. Für komplexe User Stories hat sich Pair Programming allgemein als die bessere Variante herausgestellt.

      Habt ihr mit bestimmten Maßnahmen sicherstellen müssen, dass bei solchen Meetings wie Sprint-Planung und Estimation nicht alle durcheinanderquatschen?

      Ja, mit Moderation und Disziplin 🙂 Wenn ein neues Team gebildet wird gibt es zu Beginn immer mehr Diskussionspotential, v.a. wenn alle Teammitglieder mit einer gewissen Erfahrung ausgestattet sind, so wie ihr es ward 😉 Aber wenn du dich zurück erinnerst wurden die Diskussionen mit der Zeit auch weniger und konstruktiver. Im verteilten Team halte ich die Meetings von vorne herein straffer durch stärkere Moderation.

  2. “Seit mehr als einem Jahr führe ich nun ein verteiltes Scrum Team.”
    Da habe ich aufgehört zu lesen.
    Das ist ein Widerspruch in sich. Niemand führt ein Scrum Team, es organisiert sich selbst.
    Welche Rolle hast Du eigentlich? PO? Scrum Master?
    Du machst wahrscheinlich irgendwas Inkrementelles mit einigen Scrum Zeremonien.
    Scrum ist es jedenfalls nicht.
    Ich empfehle Dir, erst nochmal die Grundlagen von Scrum zu lernen.

    1. Es sollte agiles Entwicklungsteam heißen und nicht Scrum Team (ein Scrum Team besteht aus PO, SM und Entwicklungsteam) – danke für den Hinweis! Führen eines Scrum Teams würde keinen Sinn ergeben. Ich bin aber trotzdem nicht ganz sicher ob du das so gemeint hast, daher möchte ich sicher gehen, dass wir vom selben reden: Ein agiles Entwicklungsteam arbeitet selbstorganisiert und wird von einem Scrum Master geführt (es wird auch der PO hinsichtlich Prozess & agilem Mindset vom Scrum Master geführt). Das Führungskonzept das in Scrum zur Anwendung kommt nennt sich Servant Leadership. Führung und Selbstorganisation eines Teams ist also kein Widerspruch. Ich hoffe, dass wir uns hier einig sind. Antworten zu deinen weiteren Fragen/Kommentaren findest du auf meiner About Seite im Blog und den darauf befindlichen Links.

  3. Die Begriffe sind mir klar. Also bist Du Scrum Master?
    Wenn sich bei uns ein SM vorstellen würde mit “Ich führe das Team…” wäre er die längste Zeit SM gewesen. Meeep, falsches Mindset, zurück ins Training. So haben sich früher Projektleiter oder Teamleiter vorgestellt.
    Wenn Du Scrum Master bist, dann schreib das doch hin und alle (Fach-)Leser wissen Bescheid.
    Wenn Du Deine Führungsrolle betonen willst, passt der Satz, aber dann solltest Du nicht schreiben, dass Ihr Scrum macht. Scrum betont keine Führungsrolle, ganz im Gegenteil!
    Also bist Du jetzt Scrum Master oder Projektleiter? Das ist mir immer noch nicht klar.

  4. Ich war damals Scrum Master und ich habe das Entwicklungsteam und den PO hinsichtlich Prozess und agilem Mindset geführt und gecoacht, ja. Und hoffentlich machen das deine Scrum Master auch denn ansonsten machen sie ihren Job nicht! Dass Scrum Master nicht wie klassische Teamleiter/Projektleiter führen ist richtig, aber das heißt nicht, dass sie NICHT führen – Scrum Master führen nach dem Konzept des Servant Leaderships.

    Der Scrum Guide beschreibt die Führungsrolle des SM eindeutig: “The Scrum Master is a servant-leader for the Scrum Team.”

    Auch in der weiteren Scrum Literatur wird der Scrum Master als Servant Leader klar beschrieben. Buch-Tipps findest du unter dem Menüpunkt “Recommended Books” in meinem Blog.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s