Warum ist Kanban (wie übrigens alle agilen Methoden) eine Art böse Schwiegermutter? Weil sie einem immer wieder sagt, wie blöd man ist, aber einen nicht ändert. Damit ist gemeint, dass man mit Agilität in sehr kurzer Zeit Transparenz über viele Probleme schafft. Aber was man dann mit diesen unangenehmen Wahrheiten anfängt, das bleibt jedem selbst überlassen.

Unabhängig von Kanban gibt es allerdings ein paar interessante Erfahrungen zum Thema verteilte Entwicklung, die einer näheren Betrachtung wert sind.

Zwei grundlegende Strategien

Wenn wir verteilt arbeiten, dann gibt es dafür zwei grundlegende Strategien und wir sollten uns klar machen, welche der beiden wir verfolgen. Entweder wir machen die verschiedenen Standorte maximal unabhängig voneinander oder wir verweben sie möglichst eng miteinander. Was ich in der Praxis häufig gesehen habe, ist eine Mischung aus beiden Strategien, die sich (meistens unbewusst) entwickelt hat: Die Standorte arbeiten am selben Produkt, aber niemand investiert darin, eine wirkliche Zusammenarbeit zu etablieren.

Haben wir uns dafür entschieden, dass die verschiedenen Standorte eng miteinander zusammenarbeiten sollen oder müssen (oft gibt es dazu ja gar keine Alternative), dann sollten wir möglichst viel Bandbreite auf die Kommunikation geben. Dabei gilt die Faustregel: Face-to-Face ist besser als Video-Konferenz ist besser als Telefon ist besser als E-Mail. Das vertrackte dabei ist, dass Bandbreite hier teuer ist! Face-to-Face würde bedeuten, die Kollegen regelmäßig zusammenzubringen, oft über weite Strecken hinweg. Dies scheint absurd, wenn der Grund für die Verteilung in der (vermeintlichen) Einsparung von Kosten lag!

Wenn man genauer hinsieht, zeigt sich jedoch, dass wir zwar Lohnkosten sparen, wenn wir Teams outsourcen, dass wir uns damit aber auch hohe Kosten einhandeln, die erst mal schwer zu sehen sind: Missverständnisse, Nacharbeiten etc. Auf einen besonderen Kostenfaktor wollen wir noch einmal ausführlicher eingehen, weil er immens ist und gleichzeitig sträflich vernachlässigt wird: mangelndes Vertrauen.

Das Trust Game

Aus der Sozialforschung kennen wir das sog. Trust Game (eine Abwandlung des Gefangenen-Dilemmas, s. Wikipedia). Dazu werden zwei Personen eingeladen und in unterschiedliche Räume gesetzt. Die erste Person bekommt 10 Dollar geschenkt, die sie einstecken und mitnehmen kann. Sie bekommt allerdings mitgeteilt, dass im Nebenraum eine weitere Person sitzt, die kein Geld bekommt.

Person A kann nun Person B einen beliebigen Betrag abgeben. Der Betrag wird von den Wissenschaftlern verdreifacht. Den erhaltenen Betrag kann dann Person B nehmen und einstecken oder wiederum einen beliebigen Betrag davon zurückgeben, der ebenfalls verdreifacht wird. Wenn die beiden Personen zusammenarbeiten, können sie also beide ihren Gewinn erheblich erhöhen. Dafür müssen sie sich aber vertrauen. Nun wurde das Trust Game etliche Male durchgeführt und gemessen, wie häufig und welche Mengen an Geld übertragen wurden.

Interessant für unseren Kontext sind jetzt zwei Abwandlungen des Spiels, die durchgeführt wurden. In der ersten Variante blieb das initiale Setup gleich – mit einer kleinen Änderung: Die beiden Räume, in denen die Teilnehmer saßen, waren durch ein Fenster miteinander verbunden, so dass die Personen sich sehen konnten. Dadurch ist die Wahrscheinlichkeit, dass Geld übertragen wurde, um 50% gestiegen!

Dann wurde das Experiment ein weiteres Mal modifiziert: Die Teilnehmer konnten sich weiterhin sehen und bekamen zusätzlich einige kleine Details aus dem Privatleben des jeweils anderen mitgeteilt, z. B. Alter und Namen der Kinder, Hobbys, Lieblingsessen usw. Dadurch ist die Wahrscheinlichkeit abermals erheblich gestiegen, dass Geld übertragen wurde. Das Experiment ist u.a. beschrieben in "The Penguin and the Leviathan: How Cooperation Triumphs over Self-Interest" von Yochai Benkler.

Der unterschätzte Wert von Vertrauen

Nehmen wir die Ergebnisse dieser Experimente ernst, dann beleuchtet dies abermals einen etwas anderen Aspekt von verteilter Entwicklung: Wenn die Kollegen an unterschiedlichen Standorten sich nicht persönlich kennen und sich nicht sehen können, dann ist es sehr schwierig, Vertrauen aufzubauen und aufrecht zu erhalten. Und wie wertvoll Vertrauen für die effektive Zusammenarbeit ist, wissen wir aus zahlreichen Kontexten (vgl. z.B. "Schnelligkeit durch Vertrauen: Die unterschätzte ökonomische Macht" von Stephen M. Covey und Rebecca R. Merrill).

Tatsächlich bestätigen diese wissenschaftlichen Erkenntnisse viele Beobachtungen, die ich mit verteilten Teams gemacht habe. Äußerungen wie "Die da in [Standort B] haben schon wieder Mist gebaut" oder "Bevor die an [Standort A] das wieder vermasseln, machen wir es lieber gleich selbst" sprechen Bände von vorhandenem Misstrauen. Wollen wir die meist immensen Kosten für mangelndes Vertrauen nicht zahlen, tun wir also gut daran, uns zu überlegen, wie wir die Kollegen an unterschiedlichen Standorten (auch persönlich) näher zueinander bringen können.

Regelmäßiges gemeinsames Arbeiten für ein bis zwei Wochen am selben Standort ist dafür sicherlich die effektivste (aber auch die teuerste) Möglichkeit. Meine Empfehlung ist, dies so häufig wie möglich zu organisieren, auf jeden Fall aber beim Start eines neuen Projekts! Für die Zeit dazwischen empfiehlt sich eine Art "Pendeldiplomatie". Idealerweise sind möglichst häufig und möglichst lange "Abgesandte" von Standort A an Standort B und andersherum. Sie verbessern das gegenseitige Verständnis und sorgen dafür, dass die Informationen zwischen den Standorten effektiv fließen.

Asynchrones Arbeiten

Sieht man sich einmal genauer an, warum verteiltes Arbeiten eigentlich so schwierig ist, dann kann man feststellen, dass einige Probleme gar nicht am verteilten Arbeiten selbst hängen, sondern an der Asynchronität. Hierzu ein kleines Beispiel: Ich arbeite gerade an einem schwierigen Problem und hänge fest. Mein Kollege kann mir vielleicht bei meinem Problem helfen. Sitzt er im selben Raum oder Gebäude, kann ich idealerweise kurz zu ihm hingehen und ihn um Rat fragen. Sitzt dieser Kollege jedoch am anderen Ende der Welt, dann liegt es nahe, ihm eine E-Mail mit der Bitte um Hilfe zu schreiben und dann eine neue Aufgabe zu beginnen.

Irgendwann kommt dann die Antwort. Jetzt stecke ich aber gerade mitten in meiner neuen Aufgabe, also lasse ich die E-Mail erst einmal wieder liegen. Wenn ich dann hineinschaue, weiß ich vielleicht gar nicht mehr so genau, worum es eigentlich ging und muss mich erneut einarbeiten. Wenn ich Pech habe, dann haben sich inzwischen die Umstände geändert (z.B. die Codebasis), und ich muss zusätzlichen Aufwand investieren. Durch diese Art des Arbeitens entstehen also Warteschlangen, die erhebliche Schwierigkeiten verursachen: Wartezeiten, mehr Fehler, unnötige Nacharbeiten, Unzufriedenheit. Und noch schlimmer: Lange Warteschlangen haben die unangenehme Eigenschaft, immer länger zu werden.

Zum Glück hat dieses Problem nur indirekt mit verteiltem Arbeiten zu tun. Denn auch wenn mein Kollege an einem anderen Ort sitzt, könnte ich ihn ja direkt um Hilfe bitten (per Video-Chat, Telefon oder ICM). Das tun wir zwar selten, aber es ist möglich und in erster Linie eine Frage der Gewohnheit. Anders sieht es hingegen aus, wenn wir soweit verteilt sind, dass die Zeitverschiebung synchrones Arbeiten sehr schwer, wenn nicht gar unmöglich macht. Deshalb ist es durchaus sinnvoll, verteiltes Arbeiten erst einmal konzeptionell vom asynchrones Arbeiten zu trennen und sich Gedanken darüber zu machen, welche Vor- und Nachteile uns die verschiedenen Arbeitsweisen bieten bzw. wie wir die größten Schmerzen lindern können.

Fazit

Verteilte Entwicklung (wie verteiltes Arbeiten allgemein) kann für Firmen aus verschiedenen Gründen attraktiv sein (niedrigere Lohnkosten, Zugriff auf Experten, Zugang zu entfernten Märkten). Allerdings kauft man sich damit oft erhebliche versteckte Kosten ein, von denen mangelndes Vertrauen ein wesentlicher Teil ist. Um effektiv verteilt arbeiten zu können, sollte man sich deshalb Gedanken darüber machen, wie man Vertrauen zwischen den Standorten stärken und aufrecht erhalten kann und wie sich asynchrones Arbeiten minimieren lässt.