Nähe oder Distanz, das ist hier die Frage

Sollen Softwareteams in einem Raum arbeiten? Diese Frage haben die Agilisten ganz klar mit Ja beantwortet. Wohin man schaut die Empfehlung, Entwickler möglichst nah zusammen zu setzen. Vor kurzem hat Martin Fowler sich daher bemüßigt gesehen, Empfehlungen für die Gestaltungsfreiräume des Team Room zu geben.

Damit könnte doch das Thema ein für alle Mal zur Ruhe gebettet werden, oder? Setzt die Leute in einen Raum und der Rest wird sich finden. Die breitbandige und informelle Kommunikation in so einem Raum, wo die Entwickler “colocated” sind, kann die Software nur besser machen. Oder?

Ich habe selbst lange Jahre in solch einer Umgebung Software entwickelt und fand das gut. Und neulich beim Clean Code Developer Praktikum haben wir es auch so gehalten: eine Woche lang zu siebt in einem recht kleinen Raum lernen, planen, implementieren. Da entsteh eine sehr produktive und dichte Atmosphäre. Ich bin ganz dafür.

Aber… aber ist das alles? Golo Roden hat Zweifel angemeldet. In zwei Blog Postings hier und hier hat er keck behauptet, solche räumliche Nähe sei überbewertet. Solcher Nonkonformismus hat natürlich Widerspruch hervorgerufen in den Kommentaren und im Blog von Ilker Cetinkaya hier.

Der eine findet, räumliche Nähe wird überschätzt, der andere ist sich sicher, sie werde unterschätzt. Ja, was denn nun?

Ich neige Golos Position zu und habe das in Kommentaren bei ihm auch schon Kund getan. Aus meiner Sicht ist Golo auch nicht apodiktisch. Er sagt nicht, man müssen Entwickler dringend verteilt arbeiten lassen. Anders die Gegenposition der Agilisten, die eher darauf bestehen, dass es ohne räumliche Nähe nicht wirklich gehe.

Um nun die Diskussion zu “depolarisieren”, versuche ich einmal, einen Blick aus größerer Flughöhe.

Der historische Kontext

Ilker et al. berufen sich auf die Agilisten von Cockburn über Fowler bis Beck, die mahnen, man solle dringend Entwickler in einen Raum setzen. Das ist ein argumentum ad verecundiam, also ein Trick der Eristischen Dialektik, um den Gegner einzuschüchtern. Wer will sich schon mit seiner persönlichen, unmaßgeblichen Meinung gegen die Autoritäten wenden? Im Sinne eines rationalen oder gar wissenschaftlichen Dialogs, ist das aber natürlich zuwenig.

Damit will ich nicht sagen, dass Fowler et al. per se unrecht haben. Doch ich möchte ermuntern, auch sie als fehlbar bzw. in ihre Kontexte eingebunden zu sehen. Die Frage muss also erlaubt sein, warum Fowler et al. so sehr die Colocation befürworten?

Ich denke, die Antwort liefert der historische Kontext. Die Agilitätsbewegung ist als Gegenentwurf entstanden. Sie “lehnt sich auf” gegen eine Art der Softwareentwicklung, die auf formale Prozesse, lange Planung, strikte Rollentrennung und starre Kommunikationsmuster gesetzt hat. Früher – und auch heute noch, man soll es ja nicht glauben – wurde Softwareentwicklung als Tätigkeit angesehen, die man wie Bauprojekte generalstabsmäßig planen musste.

Das ist dann umso häufiger schief gegangne, je komplexer Software geworden ist. Und irgendwann haben die Agilisten dann gesagt: Schluss! Es kann nur besser werden, wenn sich etwas grundlegend ändert. Unter anderem war das die Kommunikation im Softwareteam.

Eine Ursache für aus dem Ruder gelaufene Softwareprojekte war für sie die inflexible, reglementierte Kommunikation zwischen Teammitgliedern (und auch mit dem Kunden). Informationsverlust, Wissensinseln, Verzögerungen und mehr können darauf zurückgeführt werden.

Deshalb  haben die Agilisten dem starren Reglement die Colocation entgegen gesetzt. Ein kompliziertes Regelwerk haben sie mit dem “Chaos” der Abwesenheit von Regeln bei breitbandiger ad hoc Kommunikation gekontert.

Eine gute Idee. Und so preisgünstig ;-)

Das Agile Manifest

Anders als die Befürworter räumlicher Nähe in der aktuellen Diskussion nun meinen, steht die Colocation jedoch nicht im agilen Manifest. Bezug zu einem dessen vier Werte - Individuals and interactions over processes and tools - besteht zwar – doch die Colocation lässt sich da nicht wirklich herauslesen. Sie mag als Interpretation dieses Wertes angesehen werden, doch nicht als Wert selbst.

Die Menschen und ihre (ungeplanten) Interaktionen über Protokolle, Regeln, Werkzeuge zu stellen, ist sogar so allgemein in der Formulierung, dass sowohl räumliche Nähe wie räumliche Distanz von Teammitgliedern dadurch gestützt werden. Denn wenn räumliche Distanz den Menschen mehr dienen sollte als räumliche Nähe, dann wäre das ganz im Sinne dieses Wertes.

Das Offshoring

In den Kommentaren zu Golo findet sich immer wieder als Beweis gegen seine Behauptung, dass Offshoring Projekte so oft fehlgeschlagen seien, dass der Traum von der verteilten Entwicklung als ausgeträumt gelten sollte.

Dagegen ist einzuwenden, dass Golo gar nicht behauptet hat, dass Offshoring “so einfach” funktionieren würde. Er hat auf ein solches Szenario nicht mal angespielt. Offshoring bedeutet zwar verteilte Entwicklung; aber nicht jede verteilte Entwicklung muss mit den besonderen Problemen des Offshoring kämpfen (z.B. Zeitverschiebung, Kulturunterschiede, Problemdomänenferne).

Also: Offshoring-Niederlagen sind kein Argument gegen Golos These.

Die Allaussage

Golos These ist eine Existenzaussage. Er sagt: “Es gibt mindestens ein Projekt, dass verteilt gut bewältigt wird.” Um diese Aussage zu beweisen, muss er nur ein positives Beispiel bringen. Das tut er. Vom Standpunkt der Logik aus ist es unerheblich, dass das ein Beispiel ist, dass nicht für viele Teams gilt. Damit kann eine Diskussion darüber beginnen, wie es sein kann, dass überhaupt so ein Positivbeispiel existiert. Diese Frage aufzuwerfen und nach den Gründen zu suchen, das wäre eine spannende Aufgabe für die Community.

Die beharrt hingegen auf der Allaussage der Agilisten: “Alle Projekte, die gut bewältigt werden sollen, müssen colocated organisiert sein.” Leider hilft das aber nichts, denn eine solche Allaussage kann mit einem Gegenbeispiel wie von Golo vorgetragen entkräftet werden. Und wieder sollte das nicht Anlass zu Wehklagen sein, sondern die Frage nach den Gründen aufwerfen.

Wie kann es sein, dass Golo positive Erfahrungen mit verteilten Teams gemacht hat? Wie kann es sein, dass andere Projekte ebenfalls kein Problem haben mit verteilten Teams? Denn dass das so ist, sollte unzweifelhaft sein, auch wenn die Literatur davon nicht überquillt. Open Source Projekte im Allgemeinen und db4o im Speziellen fallen mir da ein. Ich weiß von Carl Rosenberger, dem Chefentwickler von db4o, dass er sehr zufrieden war und ist mit seinem verteilten Team. Schon vor Jahren schwärmte er von den verteilten Pair Programming Sitzungen und pries die Möglichkeit, Entwickler nach Kompetenz rekrutieren zu können, ohne auf ihren Wohnort achten zu müssen.

Die Empirie

Aber die Frage nach den Gründen für Projekterfolge mit Verteilung wird nicht wirklich gestellt. Stattdessen drohen die Colocation-Befürworter mit der Messungskeule. “Hast du denn überhaupt einen Vergleich”, fragt Ilker Golo. Wieso behauptet Golo, dass die verteilte Arbeit mit Peter gut sei, wenn er es in räumlicher Nähe Peter nie probiert habe? Das kann doch wohl nicht sein.

Doch, das kann sein, denn Golo hat nie behauptet, die Verteilung sei besser als die räumliche Nähe. Er hat nur gesagt, sie sei (auch) gut. Er empfinde kein Problem durch die räumliche Distanz. Golo hat keinen Leidensdruck und tritt damit keck als Gegenbeispiel zur Allaussage der Agilisten auf. So simpel ist das. Ich halte das für absolut legitim.

Ilker hingegen suggeriert, dass er gemessen habe, welchen Unterschied es mache. Oder wenn er schon nicht selber gemessen hat, dann doch “die Autoritäten”: “Diese Behauptung ist kein Wunschtraum, sondern messbar & belegbar.”

Ich bezweifle zwar aus mehreren Gründen, dass es solche Messungen im wissenschaftlichen Sinne gibt – aber sei es drum. (Man möge mich bitte auf Quellen, die solche Messungen anstellen hinweisen, falls ich mich irre.)

Selbst wenn es tatsächlich effektiver und effizienter wäre, ein Team in einem Raum unterzubringen als es zu verteilen… – was eigentlich weder Golo noch ich bestreiten – sollte es man es denn deshalb auch immer ganz dringend tun?

Ilker behauptet, ja, das sei dringend wichtig, denn: “Golo überspringt in seiner Betrachtung meines Erachtens die Interdisziplinarität agiler Teams.”

Nähe-Distanz-Wertesystem

Was soll das eigentlich alles mit der Colocation? Bessere Kommunikation sei das Ziel. Ich behaupte aber, das ist nur ein Proxy. Bessere Kommunikation ist kein Selbstzweck. Warum also bessere Kommunikation? Damit die Entwicklung effektiver und effizienter ist. Es sollen bessere Entscheidungen getroffen werden (Effektivität) und die Arbeit soll zügig vonstatten gehen (Effizienz). Der Kunde soll das, was er wirklich haben will, möglichst schnell bekommen. Hört sich auch gut an. Ist jedoch immer noch nicht der ultimative Zweck.

Colocation muss sich – wie alles andere auch – daran messen, wie es Einfluss auf den Profit eines Unternehmens nimmt.

So einfach ist das. Und so komplex.

Denn da ist die Frage angebracht, ob denn Colocation die einzige Möglichkeit ist, den Profit zu steigern. Woraus setzt der sich eigentlich zusammen? Colocation ist der Meinung, der Profit steige, wenn die Software funktional auf den Punkt, evolvierbar, korrekt und produktionseffizient entwickelt wird. Und mehr Effektivität und Effizienz können da nur hilfreich sein, oder?

Hört sich plausibel an. Finde ich aber zu kurz gesprungen. Profit ist die Differenz zwischen Umsatz und Kosten. Woran dreht denn da aber Colocation? Scheinbar sinken durch Colocation nur die Kosten und damit steigt der Profit, weil ja der Umsatz gleich bleibt.

Kurzfristig mag das so sein. Langfristig jedoch wird der Umsatz durch Colocation aber sinken, weil die Effektivitäts- und Effizienzvorteile (zum Teil) an den Kunden weitergegeben werden. Das ist natürlich kein spezieller Nachteil der Colocation. Das passiert vielmehr immer, wenn die Produktivität steigt. Aber Colocation sollte sich eben auch nichts in die Tasche lügen.

Sinken denn aber durch Colocation die Kosten immer? Ich glaube, das ist nicht der Fall. Solange Colocation als Proxy hochgehalten wird, ist das nur nicht zu erkennen. Denn dann ist die Tendenz stark, Probleme durch Colocation zu lösen, statt nach der wahren Ursache zu suchen.

Ich nenne zwei Probleme in bewusst etwas drastischer Sprache, die Colocation verschärft, statt sie zu lösen:

• Motivation: Colocated Teams sind Zwangsveranstaltungen. Colocation bedeutet gleicher Raum und gleiche Zeit für alle. Das mag irgendwie der Kommunikation förderlich sein – aber fördert das auch die Motivation? Ich habe in Büros mit mehreren Entwicklern gearbeitet und es gehasst. Ein Team Room wie bei Martin Fowler kann die Hölle sein. Alle sind am Telefon, wenn einer es ist. Alle hören die Gespräche der anderen. Alle werden gestört, wenn der Chef reinplatzt. Es sei denn, man schützt sich durch einen Kopfhörer und Musik.
  Ich habe solche Zwangsgemeinschaften immer als Belastung empfunden. Sie haben meine Motivation gedämpft und damit meine Leistung verschlechtert.
  Geschieht das über längere Zeit, steigt die Fluktuation im Team. Und das (!) ist richtig teuer.
• Kompetenz: Colocated Teams müssen mit den Kompetenzen leben, die sich an einem Ort sammeln lassen. Sind das aber wirklich die besten für das Projekt? Ist ein Team mit 10 schlechten colocated Entwicklern besser als ein Team mit guten 5 Entwicklern in räumlicher Distanz? Das bezweifle ich.
  Wer Colocation als so wichtig ansieht, verschenkt aber die Chance, ein verteiltes Team aus 5 guten Entwicklern zu geringeren Kosten einzusetzen. Er kann das nicht mal denken, denn räumliche Nähe ist ja “messbar & belegbar” besser.

So einfach ist es also nicht mit dem Profit und der Colocation, würde ich sagen. Colocation “best practice” steht vielmehr der besten Lösung im Weg. Die findet nämlich nur, wer wahre Werte und keine Tools in den Blick nimmt.

Wie ist es also mit dem Profit? Wann ist der hoch? Es tragen u.a. bei zum Profit:

• Flüssige Kommunikation
• “Barrierefreiheit”, d.h. weitgehende Abwesenheit von Hierarchien als Kommunikationslenker
• Hohe Motivation
• Hohe Kompetenz
• Hohe Kohärenz, d.h. die Ausrichtung der Kräfte auf ein gemeinsames Ziel

Diese Punkte schlage ich mal als Wertesystem hinter der Frage nach Nähe oder Distanz von Teammitglieder vor. Wem da Werte fehlen, mag sie gern vorschlagen.

Wer also über Colocation oder nicht entscheiden muss, sollte sich überlegen, inwiefern die Entscheidung dafür/dagegen diesen Werten dient.

Der Misserfolg von Offshoring ist mit diesen Werten zum Beispiel recht leicht zu erklären, würde ich sagen: Das typische “leichtfertig” Offshoring-Projekt widerspricht den Werten wie folgt:

• Keine flüssige Kommunikation aufgrund von verschiedenen Zeitzonen, Kulturen und Sprachen
• Mangelnde Barrierefreiheit, weil Teams in anderen Kulturen oft nicht genauso egalitär arbeiten wie Europäer
• Mangelnde Motivation, weil Entwickler beim Auftraggeber oft die letzten Übriggebliebenen sind und Entwickler in der Ferne keinen Bezug zur Problemdomäne haben. Angst, Unsicherheit, zähe Kommunikation und Entfremdung sind schlechte Motivatoren.
• Mangelnde Kompetenz, weil Entwickler in der Ferne bei allem Marketing der Offshore-Firmen eben doch nicht so kompetent sind, wie man es gern hätte. Davon abgesehen ist die Fluktuation bei Offshoring-Firmen oft sehr hoch, so dass kompetente Kollegen in der Ferne bald aus dem Projekt verschwinden.
• Geringe Kohärenz, da Kulturunterschiede und Problemdomänenferne es schwer machen, Entwickler in Nah und Fern zu einem Team zusammenzuschweißen, das eine gemeinsame Vision hat.

Und bei der nachgebeteten Colocation ist es nicht viel anders. Auch sie läuft Gefahr, den Werten für mehr Profit zu widersprechen – trotz aller guten Intention. Das Ergebnis sieht dann schnell so aus – ohne, dass es jemand merken würde, weil ja keine Messung/kein Vergleich durchgeführt wird, da man sich ja im Einvernehmen mit den agilen Vordenkern sieht:

• Flüssige Kommunikation im interdisziplinären Team. Super! Pluspunkt für Colocation.
• Barrierefreiheit mag gegeben sein. Pluspunkt für Colocation.
• Aber: Suboptimale Motivation, weil die Autonomie gering ist. Menschen, die viel leisten müssen, wollen viel Freiheit darüber haben, wie sie diese Leistung erbringen. Das gehört zur conditio humana. Je größer die Belastung, desto höher sollte die Autonomie sein, über die “Lösungsverhältnisse” zu bestimmen. Die ist bei Colocation per definitionem aber sehr gering.
• Und: Suboptimale Kompetenz. Die Führung nimmt die Entwickler, die sich “zusammenpferchen lassen”, statt die besten für den Job zu suchen. Da Personalkosten der größte Kostenfaktor in der Softwareentwicklung ist und es Leistungsunterschied im Zehnerpotenzbereich gibt, sind die Kosten durch suboptimale Kompetenz womöglich ungeahnt groß.
  Wer auf Colocation setzt – aus welchen Gründen auch immer –, der verschenkt schlicht die Chance, bares Geld zu sparen mit Entwicklern, die nicht in der Nähe sind, aber deutlich besser. Und sei es auch nur für “Spezialaufträge”, die ab und an anfallen.
• Schließlich: Munteres Geplauder im Team Room und am Kicker ist eine schöne Sache – kann allerdings auch darüber hinwegtäuschen, dass Kohärenz fehlt. Wo Kommunikation stetig so unbewusst abläuft wie bei der Colocation fehlt es womöglich an Signalen für Missverständnisse.

Ich will damit nicht sagen, dass Colocation schlecht sei. Mir geht es nur darum, sie nicht zu beweihräuchern. Colocation gehört nicht auf den Altar. Auch sie ist nur ein Tool, das man in bestimmten Situationen einsetzen sollte und in anderen eben nicht.

Darüber hinaus möchte ich aber auch motivieren, räumlich verteilte Teams als Ziel zu haben. Wenn das nicht erreicht werden kann, dann ist Colocation auch ok. Aber ich halte die räumliche Verteilung als default Modus eines Teams für unverzichtbar. Warum? Weil mit Motivation und Kompetenz so wichtig sind.

Wer schonmal gute Entwickler gesucht hat, der weiß, wie schwer es sit, gute Leute zu finden. Warum also die Suche erschweren dadurch, dass man neue Kollegen dazu zwingt, umzuziehen? Aber auch wenn das heute noch nicht genügend Grund für viele Manager sein wird, räumliche Distanz im Team zu akzeptieren… ich denke, in 5 oder 10 Jahren ist das anders. Der Fachkräftemangel wird nur größer, nicht kleiner. Keine Sorge. In 10 Jahren ist ein Team in München froh, einen Entwickler in Schwerin sitzen zu haben; und das Team in Paderborn ist froh über den Kollegen auf Madeira.

Voraussetzung für erfolgreiche Distanz

Entwickeln in räumlicher Distanz mag von mir aus aber sogar die zweitbeste Lösung sein. Am Ende hilft es nichts: Wir kommen nicht drumherum, die Verteilung “ins Programm aufzunehmen”. Entwickler werden sie fordern. Sie ist in vielen Fällen ökonomischer und ökologischer für alle Beteiligten. Und auf lange Sicht lassen sich benötigte Kompetenzen nicht mehr anders finden.

Es scheint mir daher angezeigt zu überlegen, was denn dann die Bedingungen für die Möglichkeit gelingender Teamentwicklung in Distanz sein kann. Statt dass wir uns in “Ich hab recht, du hast unrecht”-Zuwürfen ergehen oder im Lamentieren verharren, wie schlecht denn die letzte Erfahrung mit der räumlichen Distanz gewesen sei, sollten wir notwendige Kriterien für erfolgreiche verteilte Projekte finden. Hier meine Vorschläge:

• Erreichbarkeit: Wer nicht im selben Raum sitzt, soll im selben Space sitzen. Alle Teammitglieder müssen einander erreichen können mit Chat, Email, Telefon, Desktopsharing und evtl auch Video und Wiki. Diese Medien müssen denkbar einfach zu bedienen sein. Diese Medien müssen ständig zur Verfügung stehen.
  Wo ein Teammitglied arbeitet, ist letztlich egal. Aber da wo es arbeitet, muss es erreichbar sein. Je nach Medium sollten die Antwortzeiten unterschiedlich, aber medienbezogen kurz sein.
• Kommunikationskompetenz: Teammitglieder müssen die Medien nicht nur bedienen können, sondern auch wollen. Manche Menschen tun sich schwer mit der elektronischen Kommunikation – auch in unserem Job. Mit denen ist verteilte Arbeit schwierig. Bei der Besetzung eines verteilten Teams ist daher darauf zu achten, ob die Mitglieder “etwas anfangen können” mit den Medien. Lippenbekenntnisse dazu sorgen schnell für Friktionen. Also Obacht!
• Verlässlichkeit: Wer technisch und charakterlich kompetent ist in der notwendigen elektronischen Kommunikation, der muss auch dem Erwartungsniveau entsprechen. Er muss verlässlich kommunizieren. Und er muss natürlich auch verlässlich arbeiten außerhalb der Kommunikation. Dazu braucht es sicher einige teamspezifische Regeln, auf jeden Fall aber klare Aufgabenzuordnungen.
• Vertrauen: Aus Verlässlichkeit speist sich dann ganz natürlich Vertrauen. Wer verlässlich arbeitet, gewinn Vertrauen. Da braucht es gar keine Kickerturniere oder Hochseilgärten. Nichts ist teambildender als Verlässlichkeit in der Kommunikation und Arbeit.
  Aber wo das Management es bezahlen kann, da dürfen natürlich weitere vertrauensbildende Maßnahmen hinzukommen. Vor allem aber sollte alles unternommen werden, Vertrauen nicht zu zerstören durch künstliche Fluktuationen im Team.
• Moduswechsel: Manches lässt sich dann doch einfacher im persönlichen Gespräch klären. Dafür mag es angezeigt sein, gelegentlich Teile eines Teams oder das ganze Team in einem Raum zu sammeln. Eine gesunde Balance zwischen Nähe und Distanz ist also nötig.
  Wann ist eine Colocation-Phase sinnvoll? Wenn einer der obigen Werte droht kompromittiert zu werden. Colocation könnte nötig sein, um doch mal die Motivation zu heben oder die Kohärenz zu stärken oder Kompetenz aufzubauen oder noch zügiger zu kommunizieren.

Soweit meine Vorschläge für eine Diskussion über Nähe vs Distanz für Entwicklerteams. Lasst uns nicht auf Autoritäten verweisen, lasst uns nicht Überkommenes wiederkäuen, sondern mit freiem Geist darüber nachdenken. Es gibt viel zu gewinnen durch eine Befreiung aus der unverbrüchlichen “best practice” Colocation. Denn ich glaube, es gibt nur wenige Entwickler, die mehr Autonomie bei der Wahl ihrer Arbeitszeit und ihres Arbeitsplatzes ablehnen. Oder?

Also sollten wir mehr persönliche Autonomie in den Blick nehmen und schauen, wie wir das Arbeitsumfeld, d.h. die Teamorganisation darauf ausrichten können. Der Mensch ist das Maß, nicht das Projekt.