Fallstricke agiler Remote-Entwicklung und Gegenmaßnahmen für eine effektive Zusammenarbeit in räumlich verteilten Teams.
Inhaltsverzeichnis
Remote Arbeit und Agile Remote Entwicklung waren eines der Heilmittel in der heutigen Zeit der Corona-Folgen. In den letzten Wochen stieß ich auf mehrere Artikel, Beiträge und Blogs über die Fallstricke von Remote Teams und Empfehlungen für Gegenmaßnahmen.
Persönlich halte ich den McKinsey-Artikel zu “Revisiting agile teams after an abrupt shift to remote” [1] für einen interessanten Beitrag, dessen Aussagen eine Überlegung wert ist. Ich werde auf einige andere Quellen verweisen, erhebe aber keinen Anspruch auf Vollständigkeit in Bezug auf das Thema. In allen Artikeln habe ich jedoch einige einfache, aber wirksame Mittel vermisst, um nicht nur eine kooperativere Denkweise zu fördern, sondern die Zusammenarbeit tatsächlich zu verwirklichen.
Ich erwähne insbesondere den McKinsey-Artikel, da er einige Zahlen aus einer Studie aus dem Jahr 2017 (Harvard Business Review (HBR) [1]) zur Aussage von Remote Arbeitern über ihre Kollegen, die am Arbeitsstandort präsent arbeiten, vorstellt. Die HBR-Studie befragte “1.153 Angestellte, von denen 52% sagten, dass sie zumindest zeitweise von ihrem Heimbüro aus arbeiten”. Laut dieser Studie (aus dem Jahr 2017!) antworteten 41% der Mitarbeiter, die Remote arbeiten, dass “Kollegen hinter meinem Rücken schlecht über mich reden”, verglichen mit 31% der Mitarbeiter vor Ort. Und 64% der Remote Arbeiter glauben, dass ihre “Kollegen Änderungen an Projekten vornehmen, ohne mich zu warnen”, im Vergleich zu 31% der Vor-Ort-Mitarbeiter. Darüber hinaus sagten 35 % der Fernbediensteten auch, dass “Kollegen zusammen mit anderen gegen mich lobbierten”, im Vergleich zu 26 % der Mitarbeiter vor Ort.
Diese Zahlen waren für mich erstaunlich! Brechen Sie es auf Ihre Situation herunter: es ist fast jeder dritte Ihrer Kollegen vor Ort. Und diese Zahl steigt auf 41% bei den Remote Arbeitern. Der Post über “7 Tipps, um IT-Unternehmen erfolgreicher zu machen” [3] erwähnt in der aktuellen Zeit auch die Fernarbeit als eine Möglichkeit für Software-Entwickler, konzentriert zu arbeiten, da Entwicklung eine enorme kognitive Aktivität darstellt. Sie erwähnt aber auch Büropolitik und Klatsch als eine der größten Herausforderungen, die es zu vermeiden gilt, z.B. durch die Einstellung von Leuten, die sich gegen diese Art von Aktivitäten sträuben.
Ich habe mich also gefragt, wie eine agile Remote Entwicklung überhaupt funktionieren könnte. Zumal es zu meinem persönlichen Unbehagen beiträgt, das durch Beiträge wie “Spotify verwendet nicht “das Spotify-Modell”, und das sollten Sie auch nicht” [4] verbreitet wird. Es enthält die Aussage, dass “Zusammenarbeit eine angenommene Kompetenz” sei. Und es deutet für mich an, dass Menschen nicht “out-of-the-box” zusammenarbeiten. Vielmehr scheint mir, dass Zusammenarbeit in einem agilen Team gelernt, erfahren und verstärkt werden muss. Darüber hinaus ist das Geben von Feedback eine weitere wichtige Fähigkeit zur Zusammenarbeit. Nachdem ich an einem Webinar über “Richtig Feedback geben” von Heinz Staber, einem agilen Coach [5], teilgenommen habe, ist mir gerade wieder klar geworden, dass es Zeit braucht, um zu lernen und Zeit, um einen gewissen Grad an persönlicher Reife zu erreichen, um es ohne Anstrengung richtig zu machen.
Eine der allgemeinen Empfehlungen des McKinsey-Artikels lautet, “Bindung und Moral zu kultivieren”. Ich zitiere hier das englische Original:
Agile teams working remotely may also require a more deliberative focus on empathy, openness, respect, and courage. For example, team members may need to remind themselves to create and receive communications with a collaborative mindset and always to assume the best possible motivation from their colleagues. This practice is important to agile teams in general but to remote agile teams in particular, given how easily electronic communications can be misunderstood. [1]
Eine präzisere Empfehlung des Artikels zur Förderung einer kollaborativen Denkweise lautet, “virtuelle Happy Hours einzurichten” und “agile Teamleiter … (die) näher dran sein müssen, ihre eigenen Teammitglieder zu führen – und proaktiver dabei sein müssen”.
Aber ich vermisse hier einen Punkt. Eine kollaborative Denkweise ist erst der Anfang. Was wir sehen wollen, ist, dass die Zusammenarbeit in einem remote arbeitenden Team angesichts der oben genannten großen mentalen Hindernisse wirklich stattfindet. Nur tatsächliche Zusammenarbeit und Kooperation führt zu Empathie und Vertrauen zueinander.
Wie ermutigen wir Menschen zur Zusammenarbeit? Wer wird damit beginnen? Wie können wir andere Teammitglieder sehen lassen, dass es wirklich geschieht? Wie bringe wir sie dazu, sich ermutigt zu fühlen, sich jemandem anzuschließen oder einen remote Mitarbeiter zu suchen, um selbst mit der Zusammenarbeit zu beginnen. Deshalb sollten wir
Interessanterweise fordern die Autoren des McKinsey-Artikels [2] Ähnliches, damit ein aus der Ferne arbeitendes Team Kunden und externe Interessenvertreter einbeziehen kann:
Welche Art von ähnlichen Techniken sind nun gut geeignet, um Entwickler zu echter Zusammenarbeit und Kooperation zu bewegen?
Die kleinstmögliche Mannschaft in einem Team ist ein “Zweierteam”. Warum passen “zwei” gut zusammen? Mehrere Studien wie die in einem anderen Artikel der Harvard Business Review erwähnte “Wenn kleine Teams besser sind als große” [6] weisen darauf hin, dass kleine Teams, und insbesondere Zweierteams, die beste Teamgröße sind, wenn es um Innovation und Disruption geht. Und warum verwenden wir heutzutage hauptsächlich agile Ansätze? Weil es bei der Software-Entwicklung in erster Linie um innovative Produkte und Dienstleistungen geht und wir in hohem Maße mit Ungewissheit umgehen müssen, entweder darüber, wie das Endprodukt oder die Dienstleistung aussehen wird, oder aufgrund einer Vielzahl von sich ändernden Technologien zur Entwicklung von Software.
Die Kommunikation in einem Team von zwei Personen ist ideal, von Natur aus direkt und ohne Overhead. Jedes Teammitglied des Zweierteams darf an seinem eigenen Code arbeiten, solange ein mittelgroßer Anteil an gemeinsam bearbeitetem Code vorhanden ist. Dies läuft nicht notwendigerweise auf Pair-Programmierung hinaus, sondern erfordert nur die gemeinsame Arbeit an einem Satz von Code-Modulen. Jede Person lernt die Programmiergewohnheiten der anderen Person kennen, ihre Denkweise, ihren Codestil. Sie beginnen darüber zu sprechen, um offene Fragen zu klären und sich auf einige gemeinsame Regeln zu einigen. Es gibt genügend Freiraum für eine getrennte Kodierung für jede der beiden Personen. Der Wissensaustausch und die Zusammenarbeit werden so einfach wie möglich gemacht, was wahrscheinlich eher zu Bindung, persönlichem Vertrauen, Empathie und Respekt führt. Diese Art der Zusammenarbeit ist “effektive Zusammenarbeit” durch “1-1 Anrufe zwischen Entwicklern”.
Zusammenarbeit, sobald sie entsteht, muss für andere als Vorbild sichtbar gemacht werden. Dies ist der Teil zum Punkt “Transparenz schaffen”. “Live-Portale” könnten implementiert werden, indem das Code-Repository als Datenquelle genutzt wird. Entweder man schreibt selber paar Skripte oder man benutzt Open-Source-Werkzeuge wie Gource [7]. Alternativ kann man anspruchsvollere Ansätze wie unsere DETANGLE Knowledge Analyse anwenden, die sich mit verschiedenen Arten von Risiken zur Wissensverteilung und visuellen Mustern wie Knowledge Islands oder Knowledge Balances befasst.
Aber vielleicht sind Sie immer noch geneigt, folgendes zu antworten “Zweierteams klingen vernünftig. Und es könnte sich auf natürliche Weise ergeben, da Bindung und Zusammenarbeit immer mit zwei Personen beginnt. Was aber, wenn es nicht geschieht? Wie können wir es initiieren, von außen auslösen oder beschleunigen?”. Nun, auch agile Team Leader wurden oben bereits erwähnt. Sie sind die richtigen Personen, die sich verantwortlich fühlen, die die Zusammenarbeit transparent gestalten und auf gute Beispiele für die Zusammenarbeit in Zweierteams verweisen könnten. Es gibt auch den Bedarf an technisch agilen Leadern, die den koordinierenden Teil der Entwicklung übernehmen.
Lassen Sie mich diese Personen als technische Koordinatoren bezeichnen. Sie organisieren große Entwicklungsarbeiten, indem sie mit mehreren anderen Personen in kleinem bis mittlerem Umfang zusammenarbeiten. Sie bilden “kleine” Zweierteams. Sie bereiten Code vor, stellen Code-Vorlagen oder Beispiele zur Verfügung, überprüfen und passen Code an und schlagen Verbesserungen vor. Nach unserer Erfahrung und Analyse ergeben sich bei jedem Software-Projekt normalerweise ein oder mehrere Koordinatoren von selbst. Die Personen und die Anzahl oder der Umfang der gemeinsamen Arbeit mit mehreren anderen Entwicklern können im Laufe der Zeit variieren. Aber jedem Projekt, das diese Koordinatoren nicht hat, fehlt ein grundlegendes Erfolgsprinzip, nämlich die Notwendigkeit einer agileren Führungspersönlichkeit als Vorbild in einem Projekt. Genau diese Leiter sind diejenigen, die sich dafür verantwortlich fühlen, Zweierteams vorzuschlagen, die die Arbeit übernehmen sollen, die sie koordiniert haben und einen Zustand erreicht hat, der von der Person, mit der sie zusammengearbeitet haben, und einem weiteren, sich anschließenden Mitarbeiter weitergeführt werden kann.
Beispiel: Zweierteams und Koordinatoren der Django Developer Community
Das obige Bild veranschaulicht die Zusammenarbeit innerhalb der Django Web Application Framework-Entwicklergemeinschaft. Kleine Kreise repräsentieren Entwickler und Rechtecke sind Quelldateien. Die Entwickler sind mit den Quelldateien verbunden, an denen sie gearbeitet haben. Diese Art von Live-Portal macht die Zusammenarbeit transparent. Alle größeren roten Kreise zeigen auf die Quelldateien, die von Zweierteams geändert wurden. Außerdem gibt es zwei Koordinatoren, die in Zweierteams mit mehreren anderen Entwicklern zusammenarbeiten. Und schließlich weist das rote Rechteck darauf hin, dass zwei Entwickler ein neues Zweierteam bilden könnten, nachdem sie von zwei Koordinatoren geleitet wurden.
Sowohl Koordinatoren als auch Zweierteams sind auch Mittel zur Vermeidung eines Problems, das eher von größeren Teams bekannt ist. Man nennt es “Soziales Faulenzen” wie in “Warum weniger in Teams mehr ist” [8] beschrieben. Ich kann mir vorstellen, dass es auch für Remote Teams ein Risiko darstellt. Die Menschen schätzen nicht nur Vertrauen, Respekt und Empathie durch andere Menschen, sondern haben auch einen starken Sinn für Fairness. Es ist leichter, den Eindruck zu gewinnen, dass Kollegen “soziales Faulenzen” aufgrund der Remote Arbeitsplätze praktizieren, sei es gerechtfertigt oder nicht. Zweierteams sind die erste Art der Gegenmaßnahme gegen solche Vorkommnisse. Die aktive Arbeit der Koordinatoren zur Integration und Einbeziehung der Menschen die zweite Maßnahme. Live-Portale sind auch eine wesentliche visuelle Ergänzung. Diese machen die laufende Zusammenarbeit von Zweierteams transparent und als Vorbild offensichtlich. Und zeigen wie die Koordinatoren beispielhaft Zusammenarbeit praktizieren. Lassen Sie mich zum Schluss noch etwas gestehen. Wir brauchen uns nicht auf Zweierteams zu beschränken, ich freue mich auch über Dreier- oder Viererteams. Wir müssen diesbezüglich nicht dogmatisch sein 😉
Zögern Sie nicht, mir Ihre Gedanken dazu mitzuteilen.
Strukturelle Abhängigkeitsanalysen sind nur begrenzt aussagekräftig bei der Identifikation von Architektur-Hotspots. Es gibt präzisere Alternativen.
Wie kogntivie Verzerrungen uns dazu bringen Code-Problem zu übersehen, wie wir unsere Meinungen gegen Daten verteidigen & was dagegen hilft.
Identifizierung risikobehafteter Hotspots muss mehr als nur Codequalität und Änderungsraten berücksichtigen. Es kommt auf die Architektur an!