Verteilte Teams – warum Technik nicht alles ist
"Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteams zu übermitteln, ist im Gespräch von Angesicht zu Angesicht." – kaum jemand wird dieses Prinzip hinter dem agilen Manifest bestreiten [1]. Sicherlich gibt es auch einige Mitglieder oder Manager verteilter Teams, die sich diesen Grundsatz mit einem lauten Seufzer eingestehen, da sie aufgrund der vielen Tücken des verteilten Arbeitens eher desillusioniert sind. Auch wir bei der Saxonia Systems AG, die wir seit 2011 Erfahrung mit verteilten Teams sammeln, zweifeln dieses Credo nicht an. Doch warum beschäftigen wir uns dann überhaupt mit dem Thema Verteilte Teams?
Für uns war es essenziell, die Mitarbeiter mit den richtigen Fähigkeiten am richtigen Ort zu haben. Als Softwareconsultingunternehmen mit einem meist hohen Grad an Reisetätigkeit hatten wir mit einer gewissen Fluktuation zu kämpfen, denn z. B. für junge Mütter und Väter kommt eine 5-Tage-Woche vor Ort beim Kunden nicht mehr in Frage. Doch für uns ist es wichtig, unsere Mitarbeiter langfristig zu binden.
Während diese ihr Zuhause in den unterschiedlichsten deutschen Städten und deren Umland haben, sind unsere Kunden vor allem im Süden und Südwesten des Landes angesiedelt. Nicht nur auf Konferenzen oder bei diversen Community-Treffen – sogar durch Anfragen von Großkonzernen stoßen wir mittlerweile auf jene Problemstellungen, vor denen wir selbst vor einigen Jahren standen. Und immer wieder kommt die gleiche Frage auf: Welche Werkzeuge kann ich einsetzen, damit die verteilte Arbeit gelingt? Wie können Mitarbeiter über Standorte hinweg effizient miteinander kommunizieren? Welche Bandbreite brauche ich dafür? Der Detailgrad der technischen Fragen kennt gefühlt keine Grenzen. Wir kennen diese Herangehensweise, denn auch für uns war das bestmögliche Techniksetting das erste, womit wir uns beschäftigten. Dies ist der logische, weil offensichtliche Ansatz, denn technische Lösungen sind für alle Beteiligten greifbar und leicht nachzuvollziehen. Doch wir mussten schon bald einsehen, dass es noch viel mehr Aspekte zu betrachten gilt, damit einzelne Mitarbeiter verteilt über Standorte und Unternehmensgrenzen hinweg effektiv und effizient als ein Team zusammenarbeiten. Mittlerweile haben wir dank unserer mehrjährigen Erfahrung das umfassende Konzept "ETEO" ("Ein Team, Ein Office") detailliert ausgearbeitet [2], setzen es in unseren Projekten erfolgreich ein und geben Good Practices gerne in Workshops weiter. In diesem Artikel wollen wir einige Fälle aus der Praxis zeigen, in denen wir es bereits erfolgreich eingesetzt haben.
Verteilte Teams bei der Saxonia Systems AG
Sprechen wir von verteilten Teams, ist nicht gemeint, dass ein Mitarbeiter ausnahmsweise 1-2 Tage im Home-Office arbeitet. Auch meinen wir nicht, dass sich alle Teammitglieder verstreut über einzelne Standorte verteilen. Bei uns stellt sich die Situation meist so dar:
Die Teams sind in der Regel über 2-3 Standorte verteilt. In Abb. 1 dargestellt ist der vereinfachte Fall für 2 Standorte. Standort 1 repräsentiert den Kundenstandort, Standort 2 einen weiteren (Entwicklungs-)Standort. Beide Teilteams arbeiten nach Scrum wie ein Präsenzteam gemeinsam über die Standorte zusammen. Wir haben auch Projekte, in denen sich nur der Product Owner an einem anderen Standort befindet. Aus Komplexitätsgründen betrachten wir im Folgenden aber die für das verteilte Arbeiten interessantere Konstellation, in der auch das Entwicklungsteam verteilt arbeiten muss.
Transparenz durch klare Prozesse und Rollen
Als Dienstleister sehen wir einen großen Mehrwert darin, wenn der Product Owner vom Kunden (idealerweise vom Fachbereich) gestellt wird, da er sich in der Domäne naturgemäß am besten auskennt. Ein weiterer wichtiger Faktor ist, dass die Anforderungen direkt vom Kunden priorisiert werden und er die Arbeitsergebnisse im Rahmen des Sprint Reviews direkt bewerten und im vertraglichen Sinne abnehmen kann. Da unsere Kunden in der Regel noch wenig erfahren im Scrum-Framework sind und oft nicht über die nötige Zeit verfügen, die Rolle des Product Owners mit all ihren Aufgaben auszufüllen, stellen wir ihm häufig einen Business-Analysten zur Seite. Das Coaching des Product Owners für kontinuierlich eigenständigere Arbeiten übernimmt der Business-Analyst oder der Scrum Master.
Die Entwickler stammen in vielen Projekten ausnahmslos von uns. In einigen Fällen arbeiten wir aber – idealerweise zahlenmäßig gleichverteilt – mit Entwicklern des Kundenunternehmens zusammen. Dies ist einerseits besonders interessant für den gegenseitigen Erfahrungsaustausch, andererseits aber auch sehr herausfordernd, wenn Mitarbeiter zweier unterschiedlicher Firmen mit möglicherweise gegensätzlichen Unternehmenskulturen in einem Team zusammenarbeiten. Man denke nur an eine vergleichsweise offensichtliche und ggf. einfach zu lösende Diskrepanz wie feste Arbeitszeiten in dem einen Unternehmen und frei gestaltbare Vertrauensarbeitszeit in dem anderen. Weitere kulturelle Unterschiede bestehen vielleicht nur implizit und werden erst über die Dauer des Projekts sichtbar.
Die Rolle des Scrum Masters wird meist von einem unserer Mitarbeiter ausgefüllt. Ab und an kommen wir aber in die schöne Situation, mit dem "neuen" Vorgehen zum Vorbild für weitere Projektteams beim Kunden zu werden. Dann übernehmen wir ggf. das Coaching für angehende Scrum Master beim Kunden.
Für das verteilte Arbeiten ist vor allem relevant, wo sich die einzelnen Rollen befinden und ob sie ihrer Rolle für beide Teile des Teams gleichermaßen gerecht werden können. Damit ergeben sich für die einzelnen Scrum-Rollen verschiedene Implikationen, zum Beispiel:
- Der Product Owner wird, wie bereits erwähnt, durch den Business-Analysten unterstützt, der sich idealerweise an einem anderen Standort befindet. So kann das Entwicklungsteam an beiden Standorten direkt auf einen fachlichen Ansprechpartner zugreifen. Je nach Arbeitsmodus des Gespanns Product Owner/ Business-Analyst setzt diese Rolle eine hohe Reisebereitschaft voraus.
- Das gesamte Scrum-Team und das Projektumfeld zieht einen großen Mehrwert daraus, wenn es auf beiden Seiten einen Scrum Master, bzw. eine Scrum Master-Unterstützungsrolle am zweiten Standort gibt. Neben den "Augen und Ohren" am anderen Standort kann sich dieser Unterstützer besser um standortspezifische Belange und Behinderungen kümmern. Da eine dedizierte Person für diese Rolle gerade im Auftraggeber-Dienstleister-Verhältnis oft schwer zu rechtfertigen ist, können die Aufgaben dieses "Wächters" auch von einem Mitglied des Entwicklungsteams übernommen werden.
- Spezialwissen sowie – soweit vorhanden – unterschiedliche Reifegrade (Junior oder Senior) im Entwicklungsteam sollten idealerweise ebenfalls gleich über die Standorte verteilt sein, um eine Zusammenarbeit über die Standorte zu begünstigen. Und so tauscht sich der Tester vom Standort A mit dem Entwickler von Standort B aus, um die Testautomatisierung voranzutreiben. Ein Entwickler vom Standort A steuert Domänenwissen bei, während der Entwickler von Standort B ihm im Gegenzug bei der Einarbeitung in moderne Webtechnologien hilft. Dieser standortübergreifende Wissensaustausch fördert die Zusammenarbeit und hilft, Wissensinseln abzubauen.
Damit sich alle Teammitglieder gut kennenlernen, grundlegendes Wissen und nicht zuletzt Vertrauen zueinander aufbauen können, haben wir gute Erfahrungen damit gemacht, zunächst in einer Pilotphase die Zusammenarbeit zu verproben. Über 2-3 Sprints arbeitet das Scrum-Team dabei an einem Ort zusammen. Idealerweise wechseln sie dabei für jeden Sprint den Standort, um die Reiseaufwände fair zu verteilen. Anschließend beginnt die eigentliche verteilte Arbeit.
Zusammengehörigkeitsgefühl durch einen gemeinsamen Raum
In all unseren verteilten Projekten streben wir an, die Standorte über eine permanente Videokonferenzschaltung miteinander zu verbinden, sodass der Eindruck entsteht, alle Teammitglieder würden in einem Raum sitzen. Die Teammitglieder sehen den anderen Standort gefühlt durch ein Fenster, wie das folgende Foto aus einem unserer Projekträume verdeutlicht.
So sitzen die anderen Entwickler – egal in welcher realen Entfernung – immer nur einen Knopfdruck aufs Mikrofon entfernt. Dies scheint zunächst eine sehr kostenintensive und aufwändige Installation zu sein. Doch hat man einmal in einem solchen Büro gearbeitet, liegen die Vorteile klar auf der Hand: Durch den virtuellen Teamraum sehen sich die Kollegen die ganze Zeit, in der sie sich im Projektraum befinden, wie in einem normalen Büro. Dadurch wissen sie nicht nur, wann sich wer am Platz befindet und fürs Projekt ansprechbar ist, sie können auch zu einem gewissen Grad beurteilen, wie sich der oder die andere gerade fühlt. Meist sprechen sich unsere Entwickler im nächsten Gespräch dann auch direkt darauf an. Solche scheinbar beiläufigen Konversationen sind sehr wichtig für das Herausbilden einer Empathie, die wiederum – wie schon allein der Raumeindruck selbst – das Zusammengehörigkeitsgefühl und das Vertrauen im Team stärkt. Damit ein solcher virtueller Teamraum funktioniert, bedarf es der Beachtung einiger Regeln und Good Practices, auf die wir in den nächsten Abschnitten etwas näher eingehen. Sonst kann der Raum schnell zum "Albt-Raum" werden (auch wir mussten einiges auf dem Weg zum optimalen virtuellen Teamraum lernen). Leider findet man das angestrebte Idealsetting in der Realität nicht immer vor. Daher erleben wir immer wieder manche Kuriositäten.
Hier einige Beispiele aus verschiedenen realen Projekten und mögliche Lösungsansätze:
Szenario 1: Unser Standort in Dresden ist eine aufwändig sanierte Villa mit teils denkmalgeschützten Parkettböden. Wenn sich die Dresdner Kollegen in Meetings durch den Raum bewegten, beschwerten sich die Teammitglieder am anderen Standort schnell über den knarzenden Parkettboden. Dies scheint auf den ersten Blick kleinlich. Doch wer ab und an in Meetings mit einer Videokonferenzanlage teilnimmt, weiß, dass die meisten Mikrofone mit automatischer Lautstärkeregelung nicht zwischen relevanten Informationen (z. B. gesprochenes Wort) oder irrelevanten Nebengeräuschen (Parkettknarzen, Schlüsselklappern, Papierrascheln etc.) unterscheiden können. Alle Geräusche werden auf ein ähnliches Lautstärkeniveau angeglichen. So kommt es, dass Knarzen oder Rascheln und gesprochene Inhalte gleich laut übertragen werden und so für die Kollegen am anderen Standort nicht mehr auseinanderzuhalten sind. Das ist nicht nur in längeren Meetings sehr anstrengend, sondern sorgt oft dafür, dass die Information komplett verloren geht.
Hier schlagen wir vor, für Projektszenarien mit permanenter Videokonferenzverbindung oder längere Meetings zwingend Räume mit Teppichboden und/ oder schallschluckenden Elemente zu nutzen.
Szenario 2: Zur Adventszeit lief an einem Standort häufig weihnachtliche Musik. Die Kollegen dachten, dass es eine schöne Idee wäre, das Daily mit leiser weihnachtlicher Hintergrundmusik zu unterlegen. Das vorige Beispiel lässt den Leser vermutlich ahnen, was passierte: Auch hier hatten die Entwickler die Rechnung ohne die automatische Lautstärkeregelung des Mikrofons gemacht. Nach wenigen Augenblicken wurde klar, dass die Teammitglieder am anderen Standort keine leise Musik, sondern vielmehr einen ohrenbetäubenden Lärm wahrnahmen, den sie nur mit Mühe von den wichtigen Informationen trennen konnten.
Wir haben gute Erfahrungen damit gemacht, das Team bzw. die Meetingteilnehmer immer wieder dafür zu sensibilisieren, jegliche Art von Nebengeräuschen wie Rascheln, Schlüsselklappern, Wasser eingießen sowie Parkett- oder Stuhlknarzen in Mikrofonnähe (um nur einige "Klassiker" zu nennen), zu vermeiden – besonders, während jemand spricht. Idealerweise stehen möglichst leise Tastaturen zur Verfügung, da auch das Tastaturklappern über die Videokonferenz verstärkt wird. Um den Gesprächsfluss nicht zu stören, nutzen wir häufig Schilder, um Aufmerksamkeit zu erregen.
Szenario 3: An einem Standort lehnten sich die Entwickler im Daily an einen hinter ihnen stehenden Tisch an. Durch den gleichen Abstand aller Entwickler zur Kamera nahm der andere Standort die Aufstellung der Entwickler als bedrohliche Front war und fühlte sich angegriffen.
Unser Lerneffekt: Alle Teammitglieder sollten immer darauf achten, wie sie auf ihre Gegenüber wirken. Besonders an der "magischen" Standortgrenze können schnell Missverständnisse entstehen, vor allem wenn man sich selten sieht und Gespräche über die Videokonferenz oder am Telefon auf den fachlichen Austausch beschränkt sind. Deshalb bietet sich z. B. fürs Daily wie auch im Präsenzteam eine Kreisaufstellung vor dem Aufgabenboard an, welche sich über die Standorte fortführt. Darüber hinaus ist es wichtig, auch regelmäßig soziale Konversationen über die Videokonferenzanlage zu führen, damit die Entwickler positive Assoziationen entwickeln, die nicht allein auf Arbeitsanweisungen oder gar Kritik beruhen. Neben verteilten Teambuilding-Aktionen wie Powerpoint-Karaoke haben wir in manchen Teams gute Erfahrungen mit einer regelmäßig stattfindenden verteilten Kaffeepause oder einem Feierabendbier gemacht.
Szenario 4: Das Teilteam am Standort A saß in einem Großraumbüro mit anderen Kollegen, welche nicht am Projekt beteiligt waren. Auch dieses Team hatte sich für ein Videokonferenzsetting entschieden. Doch die Situation war für beide Parteien an dem betreffenden Standort alles andere als einfach: Einerseits fühlten sich vor allem die Entwickler am Standort B massiv von den Hintergrundgesprächen oder dem lauten Klappern der Tastaturen der projektfremden Kollegen gestört. Andererseits war die Dauerbeschallung der projektfremden Kollegen am Standort A mit für sie irrelevanten Informationen besonders in längeren Meetings unerträglich, da das menschliche Gehirn die lauten Gespräche über die Videokonferenz deutlich schlechter herausfiltert als Gespräche im Raum.
Unsere Empfehlung: Jedes Teilteam benötigt an seinem Standort ein separates Projektbüro, damit die Projektkollegen sowie die projektfremden Mitarbeiter jeweils ungestört voneinander arbeiten können. Ist das nicht realisierbar, kann das Team für Meetings über die Videokonferenzanlage in einen Meetingraum ausweichen. Dies erfordert aber ein dupliziertes Techniksetting und führt unserer Erfahrung nach zu einem Ressourcenkampf um den Meetingraum, besonders wenn mehrere Projektteams verteilt arbeiten und der Konferenzraum auch in Besprechungen ohne Videokonferenzanlage genutzt wird. Es scheint ein weit verbreitetes Phänomen zu sein, im Unternehmen zu wenig Meetingräume zu haben.
Ursachen statt Symptome bekämpfen: Werte für verteilte Teams
Einige Leser fragen sich wahrscheinlich bereits jetzt: Adressieren wir hier tatsächlich die Ursachen der Probleme oder betreiben wir nur Symptombekämpfung?
Gerade das dritte Szenario, in denen das Anlehnen an einen Tisch als "Frontbildung" oder "Bedrohung" wahrgenommen wird, erweckt den Eindruck, dass hier ein ernstzunehmender Konflikt zugrunde liegen könnte. In diesem Projekt bestand unter anderem starker Handlungsbedarf bezüglich des Vertrauens der Teammitglieder untereinander. Ohne Vertrauen im Team fehlt jeglicher weiteren Zusammenarbeit die Basis, wie in Patrick Lencionis "The Five Dysfunctions of a Team" [3] deutlich wird. Nur wenn Vertrauen herrscht, ist das Team in der Lage, an anderen Herausforderungen wie einer gesunden Konfliktkultur, der individuellen und gemeinsamen Verpflichtung im Team, dem Verantwortungsgefühl oder Zielorientierung zu arbeiten. Neben den genannten Five Dysfunctions, dem Scrum-Guide und anderen Referenzen haben wir uns zahlreiche Situationen aus unseren eigenen Projekten angeschaut und analysiert, welche unterschiedlichen Wertvorstellungen sich dahinter verbergen. Diese Untersuchung ergab zehn Werte, die es sich in unseren Augen für verteilte und agile Teams zu betrachten lohnt: Zunächst hat sich die Bedeutung der bereits im Scrum-Framework genannten Werte Fokus, Respekt, Verpflichtung, Mut und Offenheit in unseren eigenen Untersuchungen bestätigt. Zusätzlich haben wir die Werte Einfachheit und Vertrauen identifiziert, die – obwohl nicht explizit in Scrum genannt – in der agilen Community oft "beiläufig" hinzugefügt werden. Darüber hinaus sehen wir drei Werte, die speziell in verteilten Projekten von besonderer Bedeutung sind: Zusammenarbeit, Empathie und Identität.
Manche Coaches, die bisher nur mit Präsenzteams gearbeitet haben, wundern sich eventuell darüber, dass wir den Wert Identität als verteilungsspezifisch wichtig ansehen. Vielleicht nehmen sie die Entwicklung einer Teamidentität und des damit verbundenen gemeinsamen Wertesystems als einen Selbstläufer wahr. Tatsächlich ist dies durch den engen sozialen Kontakt eines Präsenzteams – sei es im Raum selbst, in der Kaffeeküche, der Mittagspause oder gar bei abendlichen gemeinsamen Unternehmungen – oftmals gegeben. Stellt man sich im Gegensatz dazu ein verteiltes Team vor, muss man erkennen, dass keine der im Präsenzteam völlig beiläufigen sozialen Zusammenkünfte von vorn herein bestehen. Dadurch begründet sich das besondere Augenmerk auf diese Werte und dedizierten Maßnahmen, an ihnen zu arbeiten.
In den oben genannten Beispielen drängen sich wahrscheinlich auch ohne weiteres Wissen über die näheren Umstände Bezüge zu einzelnen Werten auf.
Im ersten Szenario hatten wir die Situation der extremen Nebengeräusche an einem Standort. Teammitglieder an dem anderen Standort benötigen den Mut, die Störung offen anzusprechen. Natürlich setzt dies voraus, dass ein gewisses Grundvertrauen im Team herrscht. Von der anderen Seite betrachtet benötigt das Störgeräusche verursachende Teilteam die nötige Empathie, beispielsweise Rascheln oder Knarzen als störend "vorauszuahnen". Gerade bei längeren Meetings ist es sehr anstrengend, auf die Vermeidung solcher Geräusche zu achten, besonders wenn das Raumsetting deren Entstehen geradezu bedingt. Fehlt hier der nötige Respekt vor den Kollegen, besteht die Gefahr, dass am Standort mit den Störgeräuschen irgendwann die Grundhaltung entsteht, dass der andere Standort überempfindlich sei und es so schlimm doch gar nicht sein könnte. So kann aus einem eigentlich kleinen Problem wie dem knarzenden Parkettboden ein schwerwiegender Bruch im Team entstehen, durch den aus dem "wir" ein "wir und (oder gar gegen) die anderen" wird. In kritischen Fällen hilft ein Perspektivwechsel: Ein Botschafter vom Standort mit den Störgeräuschen reist zum anderen Standort und erlebt den Geräuschpegel aus erster Hand. Diese Eigenerfahrung wirkt augen- oder in diesem Fall "ohren"-öffnend und ist damit deutlich einprägsamer und nachhaltiger als alle Ermahnungen des Scrum Masters.
Das dritte Szenario ("Frontenbildung") lässt sich aus unserer Sicht nur dadurch erklären, dass das Vertrauen in diesem Team grundlegend erschüttert war. Dennoch hätte sich mit etwas mehr Empathie die Wahrnehmung der anderen Standorte auch hier vorausahnen lassen. Hörte man von einem anderen Standort aus den täglichen Gesprächen über die Videokonferenz zu, bemerkte man durchaus den rein aufs Wesentliche beschränkten Umgangston des Standortes mit der Tischfront.
Der Scrum Master muss sich in solchen Situationen stets die Frage nach der Beziehung zwischen Ursache und Effekt stellen. In Szenario 1 könnte es sein, dass der suboptimale Raum durch die ständige Anstrengung der Teammitglieder, keine Störgeräusche zu verursachen, über längere Sicht zu Wertekonflikten führen würde. In diesem Fall wäre das vermeintlich kleine Raumproblem der Auslöser für schwindende Empathie oder schlussendlich gar Vertrauen im Team.
Im Szenario 3 ("Frontenbildung") könnte man davon ausgehen, dass das mangelnde Vertrauen ursächlich für die Wahrnehmung der Fronten war und nicht die tatsächliche Aufstellung der Teammitglieder im Raum. Diese Kausalitätskette gilt es sauber und möglichst unvoreingenommen zu analysieren. Daher ist es unerlässlich, dass der Scrum Master in engem Kontakt zu allen Teilteams steht und regelmäßig zu allen Standorten reist. Ist ein Team gezwungen, einige Sprintwechsel verteilt durchzuführen, bietet es sich an, diesen als Scrum Master abwechselnd mal von dem einen, mal von dem anderen Standort aus zu moderieren. So lässt sich eine aus seiner Perspektive wortwörtlich einseitige Wahrnehmung des Teams vermeiden.
Eventuell weicht Ihre Interpretation der vorgestellten Situationen von unserer ab und Sie sehen an mancher Stelle einen anderen Wert vordergründig. So hat auch jedes Teammitglied eigene Vorstellungen über die Bedeutung der einzelnen Werte. Wenn wir die Teams mit den Werten vertraut machen, verzichten wir daher bewusst auf eine explizite Definition. Stattdessen führen wir sie im Team in folgenden Schritten ein:
- In der Anfangsphase der Zusammenarbeit eines neuen Teams stellen wir die Werte im Rahmen eines Workshops namentlich vor.
- Jedes Teammitglied ist dazu angehalten, für sich Beispiele für einzelne Werte mit Fragen wie: "Was ist für mich Einfachheit?" oder "In welchen Situationen habe ich das Gefühl, Einfachheit zu erleben?" zu finden. Manchen fällt es auch leichter, die gegenteilige Frage zu beantworten: "Woran mache ich fest, dass Prozesse, Werkzeuge etc. nicht einfach sind?"
- Nun sammelt das Team die Beispiele und findet für jeden Wert eine für das Team gültige Definition.
- Anschließend priorisiert das Team die Werte für sich und seine Situation.
- In regelmäßigen Abständen rekapituliert das Team die Werte und deren Priorisierung. Im Scrum bietet es sich an, in regelmäßigen Abständen oder bei Bedarf die Retrospektive dafür zu nutzen. Dies kann durch die Abfrage aller Werte recht offen oder durch Fokussierung auf einen Wert konkret auf ein aktuelles Problem bezogen stattfinden.
Die offene Herangehensweise sieht in etwa so aus: Jedes Teammitglied schätzt die Ausprägung eines jeden Wertes auf einer Skala von 1 (sehr gering) bis 10 (bestmöglich ausgeprägt) ein. Das in Abbildung 4 dargestellte Template lässt sich sehr leicht in einem digitalen Tool der Wahl umsetzen. Die einzelnen Teammitglieder tragen – beispielsweise über ein großes Touch-Display – ihre Punkte ein.
Alternativ können die Bewertungen auch im Vorfeld anonym über einen Fragebogen gesammelt werden. In diesem Fall präsentiert der Scrum Master beispielsweise in einer Retrospektive die Ergebnisse und das Scrum-Team sucht und priorisiert gemeinsam Ansatzpunkte zur Verbesserung.
Allgemein kann der Scrum Master die Retrospektive mit folgenden Fragen fortführen:
- Welcher Wert hat insgesamt die niedrigsten Bewertungen? Warum?
- Gibt es starke Diskrepanzen zwischen den einzelnen Einschätzungen? Warum?
- Mit welcher Ausprägung des Wertes x wären wir als Team zufrieden? Was können wir als Team tun, damit der Wert x z. B. von einer 6 auf die angestrebte Ausprägung steigt? Was müssen wir tun, damit wir uns um einen Grad verbessern?
In Abb. 4 fallen folgende Dinge besonders auf, welche es lohnt, in der Retrospektive weiter auszuführen:
- Von allen Teammitgliedern wird der Wert Einfachheit als relativ schwach ausgeprägt eingeschätzt.
- Es gibt eine sehr starke Diskrepanz der Meinungen, was den Wert Offenheit angeht.
- Es gibt weitere starke Diskrepanzen.
Das beschriebene Vorgehen und allgemein die Arbeit mit den Werten mag aufwändig und theoretisch erscheinen. Unsere Erfahrung zeigt jedoch, dass nur ein Team mit einem klaren gemeinsamen Werteverständnis und dem Willen, kontinuierlich an sich zu arbeiten, in der Lage ist, sein volles Potential zu entfalten.
Für Teams, die auf die explizite Wertearbeit nicht ansprechen oder zur Abwechslung der Methodik stellt die bekannte Fragetechnik 5 Whys [4] eine mögliche Alternative dar. Anhand eines ganz konkreten Problems, das im aktuellen Sprint aufgetreten ist, arbeitet sich das Team durch das mehrfache Hinterfragen des Sachverhalts mit "Warum?" oder "Na und? Warum ist das ein Problem?" zur Ursache vor. Wenig überraschend erleben wir dabei häufig, dass die Wurzel eines solchen Problems in einem Wert bzw. einem unterschiedlichen Verständnis bzgl. dieses Werts liegt.
Technik ist nicht alles, aber ohne Technik geht nichts
Obwohl wir der Ansicht sind, dass die "weichen" Aspekte des verteilten Teams den Großteil zum Erfolg (oder Misserfolg) eines Projektes beitragen, können wir auf die Betrachtung der Technik dennoch nicht verzichten. Denn letztlich ist ein funktionierendes technisches Setting einer der Grundpfeiler für eine enge Zusammenarbeit verschiedener Teilteams über mehrere Standorte. Wir unterscheiden hierbei zwischen Raumtechnik, zu der z. B. die Videokonferenzanlage gehört, und Werkzeugen für die Kommunikation zwischen einzelnen Teammitgliedern oder für die verteilte Entwicklung. Auch hier können wir aus unseren Projekten auf einige kuriose Anekdoten zurückblicken:
Szenario 5: Zu Beginn meines aktuellen Projekts gab es ein wahres Gewirr an Kommunikationskanälen. Aufgrund der technischen Begebenheiten beim Kunden waren die Entwickler gezwungen, über Skype for Business zu chatten (auf Kundenseite über einen Thin Client) und über Festnetz zu telefonieren (ohne Headset). Wollten sie darüber hinaus für Pair Programming oder Code Reviews noch den Bildschirm teilen, mussten die Entwickler auf Kundenseite wiederum auf ihre Microsoft Surfaces wechseln, denn der Thin Client ließ Screensharing nicht zu.
Hier können wir nur empfehlen, ein möglichst einfaches Techniksetting anzustreben, um die ohnehin hohe Komplexität der Verteilungssituation nicht weiter zu verschärfen. Nur klare und einfach zu bedienende Kommunikationstools fördern die Zusammenarbeit über Standorte. Ideal bildet ein Werkzeug viele Kommunikationskanäle ab. So ist es zum Beispiel sehr leicht möglich, mit einem hochqualitativen Headset und einem mächtigen Kommunikationstool allein (bspw. Skype for Business oder WebEx) Videotelefonie, Chat, Screensharing und sogar das Hinzufügen von Gesprächspartnern per Festnetztelefonie zu realisieren. Tatsächlich ist dies in unserem Projekt ein sehr häufiger Anwendungsfall: Die permanente Videokonferenz läuft über Skype for Business, während einzelne Kollegen beim Pair Programming eine separate Skype-Konferenz nutzen, ihren Bildschirm teilen und freigeben und bei Problemen auch gern einen projektfremden Ansprechpartner per Festnetz direkt in das Gespräch einladen.
Szenario 6: Bei einem externen Coaching berichtete uns der Scrum Master folgende Situation: Hier waren in einem Kundenprojekt zwei verschiedene Dienstleister involviert, die aufgrund unterschiedlicher Vertragslagen mit dem Kunden unterschiedliche Hardware nutzten. Während der "gestandene Dienstleister" seine eigene Hardware nutzen musste (Mac Books), hatte der neue Dienstleister die Auflage, die durch den Auftraggeber bereitgestellten Windows-Geräte zu verwenden. Dieses eigentlich im Prozess begründete Problem verursachte enorme Komplikationen im Projekt, da die Anpassung auf die jeweils andere Umgebung ein zusätzlicher Komplexitätsfaktor war, der immer wieder Zeit kostete. Die Zeichen für eine gute Zusammenarbeit zwischen den Standorten standen so verständlicherweise eher schlecht. Auch in diesem Projekt kam Skype for Business zum Einsatz, jedoch je nach Dienstleister einmal in der On-Premise-, einmal in der Cloud-Version. Aufgrund der Versionsunterschiede kam es zu Inkompatibilitäten, sodass der Verbindungsaufbau bereits eine Stunde vor Sprint Review nötig war, um überhaupt eine funktionierende Konferenzschaltung zu etablieren.
Auch bei diesem Szenario wäre eine Pilotphase von Vorteil gewesen. Hier kann das Team nicht nur die Zusammenarbeit, sondern auch die Auswahl und den bestmöglichen Einsatz der Kommunikations- und Kollaborationswerkzeuge verproben.
Weniger kritisch ist dagegen die Wahl nur temporär eingesetzter Werkzeuge wie bspw. Whiteboard-Tools oder Werkzeuge für verteilte Retrospektiven. Hier lässt sich auch im Projekt selbst noch viel experimentieren, um das Toolset zu finden, mit denen das Team am besten arbeiten kann. Generell ist neben dem nativen Whiteboard-Tool in Skype for Business (Stichwort Einfachheit: ein Tool für alles) beispielsweise OneNote, Trello für Brainstorming und Retrospektiven [5], das Realtimeboard als Allrounder mit Whiteboard- und Retrospektivenfunktionalitäten [6] und ein für verteiltes Arbeiten geeignetes Code Review-Tool mit Kommentarfunktion zu empfehlen. Diese Beispiele sollen nur einen kleinen Einblick in die vielfältigen Möglichkeiten geben, die ein Team zur Auswahl hat. Die Entscheidung für konkrete Werkzeuge hängt jedoch von vielen Faktoren ab und angesichts der Schnelllebigkeit der Tool-Landschaft sollten diese Entscheidungen in regelmäßigen Abständen hinterfragt werden. Dabei fließen neben der reinen Funktionalität u. a. auch Betrachtungen über die bisher eingesetzten Entwicklungsumgebungen, die Tool-Landschaft beim Kunden oder unternehmensseitige Restriktionen ein. So ist in manchen Konzernen beispielsweise der Einsatz von Cloud-Werkzeugen komplett untersagt.
Der Weg zum High Performance-Team: Kein Selbstläufer
Neben der bereits dargelegten expliziten Arbeit am Wertesystem eines Teams gibt es weitere Faktoren, welche die Zusammenarbeit allgemein und den Prozess der kontinuierlichen Verbesserung im Besonderen zusätzlich begünstigen. Umgekehrt führt eine Nichtbeachtung einiger Erkenntnisse zu neuen Problemen.
Szenario 7: In einem Projekt mit drei Standorten sah die Verteilung der Teammitglieder wie folgt aus: Product Owner, Scrum Master und vier Entwickler an Standort A standen jeweils zwei Entwicklern an den beiden anderen Standorten gegenüber. Während die Entwickler des näher gelegenen Standortes B zumindest zu den Sprintwechseln zu Standort A reisten, nahmen die Entwickler es Standortes C die Reisezeit von mindestens 7 Stunden nur sehr selten in Kauf. Reisen von Standort A zu den anderen Standorten gab es gar nicht. Schon bald gewannen die Entwickler von Standort A den Eindruck von zu wenig Eigeninitiative der anderen Standorte. Sie hatten oft das Gefühl, motivierter zu sein und alles allein zu machen. Außerdem fragten Entwickler von anderen Standorten häufig, was zu tun sei, statt sich selbständig Aufgaben vom Board zu nehmen.
Solche Situationen entstehen schnell, wenn eine zahlenmäßige oder kompetenzmäßige Ungleichheit zwischen den Standorten herrscht. Kommt dann noch ein Auftraggeber/Dienstleister-Verhältnis ins Spiel, ergibt sich häufig die für ein Scrum-Team absolut kontraproduktive Wahrnehmung der "verlängerten Werkbank". Hier ist es wichtig, auf Gleichheit der Standorte in jedem Belang zu achten: Möglichst gleiche Anzahl von Teammitgliedern, gleiches Techniksetting und natürlich gleiches Mitspracherecht. Darüber hinaus sollten Reiseaufwände fair im Team verteilt werden.
Greifen wir für weitere Einblicke Szenario 3 ("Frontenbildung") noch einmal auf. Zunächst sollte sich das Team idealerweise zu jedem Sprintwechsel, spätestens jedoch alle 6 bis 8 Wochen, treffen, um sich gegenseitig besser kennenzulernen und ein Vertrauensverhältnis aufzubauen. Zusätzlich bietet sich hier eine dedizierte Arbeit am Wert Vertrauen an. Dafür und für jeden anderen Wert des oben beschriebenen Wertefundaments können sich unsere Scrum Master einer Coaching-Toolbox mit Methoden zur konkreten Verbesserung eines Wertes bedienen. Viele der Übungen sind verteilt durchführbar. Doch gerade beim Wert Vertrauen sollten ausführlichere Teambuilding-Maßnahmen ausschließlich an einem Standort durchgeführt werden.
Die Quintessenz zum Mitnehmen
- Prinzipien hinter dem Agilen Manifest
- Vincent Tietz; Juliane Kluge, 2017: Agil & Verteilt – Ein praktischer Leitfaden für verteiltes Scrum mit ETEO®
Informatik Aktuell – Vincent Tietz: Verteilte und agile Softwareentwicklung – was wir gelernt haben - Patrick Lencioni: The Five Dysfunctions of a team, 2002
Wikipedia: The Five Dysfunctions of a Team - Simon Sinek: Start With Why: How Great Leaders Inspire Everyone To Take Action, 2011
- Trello
- Realtimeboard
