Follow my new blog

Sonntag, 22. August 2010

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

image 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.

imageDie 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.

image 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.

imageEs 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.

Kommentare:

sas hat gesagt…

Um den Kommentar von Ilker hier mal aufzugreifen: "Golo überspringt in seiner Betrachtung meines Erachtens die Interdisziplinarität agiler Teams."

Bei uns bedeuted Interdisziplinarität auch eine enge Zusammenarbeit mit Art Direktoren und anderen Berufsbildern, welche man in einer Marketingagentur findet. In der Diskussion welche Arbeitsumgebung ideal ist gibt es häufig unterschiedliche Ansichten, welche überspitzt so gegenübergestellt werden können:

Wir (die Entwickler) möchten ein ruhiges Umfeld wo wir in Ruhe auch mal bei offenem Fenster arbeiten können.

Wir möchten in einer Umgebung arbeiten, in der die Post abgeht und die Inspiration auf der Strasse liegt.

Trotz in Teilen gegensätzlicher Anforderungen - und auch aktuell gegensätzlicher Gestaltung - der Arbeitsumgebung sind beide Gruppen ein nicht wegzudenkender Bestandteil eines Projektes. Jeder besucht den anderen gerne um den aktuellen Stand zu besprechen. Keiner würde jedoch seine Arbeitsweise gerne der des Anderen anpassen.

Ich würde also in diesem Punkt Golo nicht nur zustimmen, sondern behaupten, dass eine gewisse räumliche Trennung (und sei es nur über eine Treppe ins nächste Stockwerk) dazu führen kann, dass sich jede Gruppe innerhalb eines interdisziplinären Teams den Arbeitsraum so einrichten kann, wie sie es braucht um produktiv sein. Einer kann also Bach hören, der andere Iron Maiden.

Jeder von uns weiss, dass Arbeit ungemein einfacher von der Hand geht, wenn sie Spass macht. In diesem Fall würde ich also vielleicht noch ein wenig weiter gehen: Eine räumliche Trennung kann durchaus auch dazu führen, dass ein Team überhaupt erst ohne Reibungsverluste funktioniert. Lediglich die Kommunikation muss im Sinne des agilen Manifestes sichergestellt werden.

Es gibt sicher noch andere Beispiele (mir fällt da zB die Entwicklung von Embedded Software im Automobilsektor ein).

Ralf Westphal - One Man Think Tank hat gesagt…

@sas: Danke für den Hinweis darauf, dass räumliche Distanz womöglich sogar ein Erfolgsfaktor sein kann. Da fällt mir nämlich wieder Conway´s Law ein und ich stelle die Frage in den Raum:

Inwiefern trägt der Colocation-Reflex dazu bei, dass Software oft eine so schlechte Architektur hat?

Meine Vermutung: Colocation suggeriert, dass Kommunikation es schon richten wird. Hauptsache, die Leute können sich ständig austauschen, dann wird die Software schon verständlich und evolvierbar und korrekt und effizient hergestellt.

Dagegen halte ich mal: Evolvierbarkeit, Korrektheit, Produktionseffizienz ergeben sich nie von allein. Colocation kaschiert ihr Fehlen jedoch. Mangelnde Evolvierbarkeit wird durch mehr Kommunikation wett gemacht. Da Kommunikation bei Colocation ganz bewusst quasi kostenlos ist, fallen schlechte Strukturen länger nicht auf.

Colocation ist das Gegenteil von Entkopplung. Nach Conway´s Law müssen daher Colocated Teams dazu tendieren (solange sie nicht bewusst Gegenmaßnahmen ergreifen), stark gekoppelte Software zu bauen.

Dasselbe gilt für Teams, die naiv dem Collective Code Ownership huldigen.

Und auch ein ständiger Kontakt zu anderen Disziplinen mag nicht nur positiv sein. Wer Kinder hat, weiß, wie nervig es sein kann, wenn sie alle 5 Minuten ankommen, um irgendetwas zu fragen. Sie tun das, weil man eben mit ihnen colocated ist, man ist verfügbar.

Eltern halten deshalb Kinder dazu an, sich auch mal selbst Gedanken zu machen. Das bringt aber nicht nur Ruhe, sondern auch die Kinder weiter, die sich dann mehr mit einer Sache auseinandersetzen.

Warum soll das nicht auch bei Softwareteams von Vorteil sein? "Denk nach!" mag man auch manchem Entwickler zurufen, der schon wieder über den Tisch irgendetwas fragt, was für den anderen eine Selbstverständlickeit ist.

-Ralf

Jens Schauder hat gesagt…

Ich kann mir nicht helfen, ich sehe das Problem nicht.

Ich habe bisher keinen ernstzunehmenden Artikel gesehen, der behauptet Kolokation wäre zwingend notwendig. Genauso wenig habe ich einen gefunden, der behauptet Entwickler sollten idealerweise abgeschottet von ihren Kollegen in Einzelboxen arbeiten.

Das Distanz die Kommunikation erschwert wird sehr schnell offensichtlich.

Das ein Raum auch schnell zu laut oder unruhig werden kann um produktiv zu arbeiten auch.

Und ob Kolokation über oder unterbewertet wird, hängt doch erstmal von der aktuellen Bewertung ab und die ist in jedem Umfeld eine andere.

Ich habe Manager gesehen, die tatsächlich glauben, sie bekommen mit einem internationalen Team die gleiche Produktivität wie mit einem Team, das an einem Ort versammelt ist.

Es hat aber auch schon Vorschläge gegeben Teams ähnlich dicht zu stapeln wie Hühner in einer Legebatterie, damit alle in einen Raum passen.

Gerade das ist die stärke der Agilen Ansätze, dass es keine harten Regeln gibt, sondern das gewisse Dinge als wichtig, andere als nicht soo wichtig angesehen werden.

Es verbleibt die Aufgabe für eine gegebene Situation ein gutes oder gar das beste Vorgehen zu finden.

Ralf Westphal - One Man Think Tank hat gesagt…

@Jens: Das Problem ist, dass eben nicht alle Agilisten so agil denken wie du. Wie die Kommentare bei Golo zeigen, sehen sich die Gegner von verteilten Teams verwurzelt in der Agilität.

Ob Sie da nun wirklich, wirklich auf Gurus verweisen können, sei nochmal dahingestellt. Grad hab ich nochmal zum Thema gegooglet und sehe die Guru-Meinung tatsächlich entspannter als gedacht. Die ist eher, "Wenn Colocation, dann so und so". Aber nicht "Colocation muss sein!"

Das finde ich schön im Detail. Aber mein Eindruck ist, dass diese differenzierte Sichtweise eben nicht in der Allgemeinheit angekommen ist. Schau dir das Internet an. Hier ein paar Links gefunden in 3 Minuten googeln.

http://www.truthtable.com/RadicalCol-ocation.html
http://www.smartagile.com/2007/08/team-co-location.html
http://martinfowler.com/bliki/TeamRoom.html
http://agileshrugged.com/blog/?p=28
http://en.wikipedia.org/wiki/Scrum_(development)
http://alistair.cockburn.us/What+the+agile+toolbox+contains (Cockburn nennt Colocation eines der "top social tools")

Sie sind alle eindeutig positiv gegenüber Colocation. Ihre Argumente widmen sich der Nähe und nicht den möglichen Vorteilen von Distanz oder der Ermöglichung von Distanz.

Ob du diese Quellen ernstzunehmen findest? Ich denke, das ist zweitrangig, wenn sie de facto meinungsbildend sind. Auch Bild mag nicht ernstzunehmen sein - aber es bildet definitiv die Meinung vieler.

Und so sind wir wieder am Anfang: es gibt einen starken Colocation-bias. Gegen den wenden Golo und ich uns. Wir möchten motivieren, auch die Chancen verteilter Teams zu sehen. Nicht mehr, nicht weniger.

Marco hat gesagt…

Ich sehe bei dem Problem auch noch ein andere Seite: Bei den Softwareentwicklern gibt es mit den höchsten Stand von asperger Autisten in einer Berufsgruppe. Und somit viele Menschen, die gar nicht so gut Produktiv mit anderen zusammen arbeiten können.
Man muss auch auf die Individuen achten, wie diese am produktivsten eingesetzt werden können.
Es hilft ja nichts Mitarbeitern einer großen Nähe aus zu setzen, wenn nachher das Ergebnis in diesem Fall schlechter wird.
Es gibt ja diese Entwickler, die alleine besser sind als 5 (vielleicht nicht ganz so gute) die zusammen hocken.
Man kann zwar Argumentieren, dass 4 Augen immer mehr sind als 2....das klappt aber nur soweit, soweit das Gehirn der Personen keine genetische Schwäche im sozialen Zusammenspiel mit anderen Menschen aufweist.

Kostja hat gesagt…

Hallo Ralf,

wie man meinem Kommentar zu Ilkers Artikel bereits entnehmen kann vertrete ich mal wieder eine mittlere Position zu dieser Thematik. Nun könnte man mir vorwerfen, dass ich mich nicht auf eine klare Meinung zum Thema Colocation festlegen kann. Dies ist aber nicht der Fall. Ich glaube nur, dass die Arbeit in verteilten Teams bestimmte Herausforderungen mit sich bringt, die nicht immer einfach zu meistern sind.

Dennoch glaube ich, dass es eine wachsende Forderung nach verteilten und dennoch erfolgreichen und effizienten Teams gibt. Zwei Punkte werden für mich aber bei Eurer bisherigen Diskussion nicht ausreichend betrachtet.

Dies ist zum einen das Thema interdisziplinäre Teams. Ich finde, dass die Diskussion bisher sehr softwareentwicklerlastig geführt wird. Da Teams aber in der Regel interdisziplinär gebildet werden, ist der Umgang mit den moderneren Kommunikationsmitteln nicht für alle Teammitglieder gleichermassen gewohnt und natürlich. Dies kann eine große Hürde bedeuten und neben dadurch verursachten Missverständnissen auch zum Ausstieg von Teammitgliedern aus der Kommunikation führen.

Der zweite Punkt ist die richtige Vorbereitung oder "Ausbildung" von Menschen, die in solchen Teams arbeiten sollen. Grundsätzlich bin ich begeistert von Deinem Ansatz des Nähe-Distanz-Wertesystems. Ich denke dies wäre eine gute Grundlage für entsprechende Trainingsinhalte. Meine persönliche Erfahrung zeigt aber, dass Teams eben häufig als verteilte Teams arbeiten sollen, ohne das die Teilnehmer eine entsprechende Vorbereitung auf die damit verbundenen Schwierigkeiten erhalten haben. In diesem Falle würde ich wieder eindeutig die Colocation bevorzugen.

Fazit
Ich bleibe bei meiner Aussage, dich ich auch im Blog von Ilker schon getroffen habe: Damit ein Team ein gut funktionierendes Team werden kann, halte ich es für unbedingt erforderlich, dass es regelmäßig die Möglichkeit bekommt an einem Ort zusammen zu kommen. In welcher Frequenz und mit welchem Ziel dies bei welcher Konstellation von Team erforderlich ist, das ist für mich die eigentlich spannendste Frage. Ich glaube trotzdem, dass insbesondere zur Teambildung hier ein wesentlicher Grundstein gelegt werden kann. Vielleicht auch indem bei einem ersten Teambildungstreffen Dein Nähe-Distanz-Wertesystem sowie die von Dir genannten Vorraussetzungen für erfolgreiche Distanz gemeinsam be- und verarbeitet werden können. Ob das allen klar ist, die für verteilte Teams plädieren??

Ich hoffe es.

Viele Grüße
Kostja

P.S.: Ich glaube im Abschnitt Kompetenz Deines Nähe-Distanz-Wertesystem soll es heißen: "Er kann das nicht mal denken, denn räumliche Nähe ist ja “messbar & belegbar” besser."

Ralf Westphal - One Man Think Tank hat gesagt…

@Kostja: Kommunikationsfähigkeit ergibt sich nicht einfach so, nur weil man Sprechen lernt. Das ist ja gerade das weit verbreitete Missverständnis.

Und insofern ergibt sich die Fähigkeit zur Arbeit in einem verteilten Team nicht einfach so. Das will gelernt sein. Die einen können das am Ende auch womögl besser als die anderen.

Aber das ist doch auch nichts besonderes. Dasselbe gilt für die Softwareentwicklung. Dasselbe gilt für die Konfliktfähigkeit bei Colocation. Dasselbe gilt für die Führung von Teammitglieder nah und fern.

Wir lernen alle soviel - und doch immer noch nicht. Da sollte es uns nicht abschrecken, mal etwas anderes als den nächsten API zu lernen.

Warum? Weil es das wert ist. Und genau diesen Punkt vermisse ich bei eigentlich allen Beiträgern zum Thema. Da wird davon geredet, Verteilung sei schwer, die Literatur würde was anderes empfehlen, das eigene Team hätte es nicht hingekriegt usw. usf.

Die meisten suchen nach einem Nein zur Verteilung. Immer wieder wird der Kopf in Skepsis gewogen. "Ei, ei, ei, das ist aber schwierig... Hm... Ne, besser Colocation..."

Das versteh ich nicht. Was ist denn das für eine Argumentation? Die ist nämlich immer aus dem Blickwinkel von Kunde und Chef. Denen will man mit möglichen Friktionen durch Distanz keinen Schaden zufügen.

Das ist natürlich eine löbliche Haltung. "Brav, liebe Angestellte, dass ihr so für uns Unternehmer denkt."

Aber wie kommt es, dass diese Haltung so reflexhaft eingenommen wird? Warum spricht denn niemand den Wunsch aus, die Freiheit, die Autonomität einer verteilten Entwicklung erleben zu wollen? Warum schwärmt niemand, "Ach, das wäre ja cool... Ich kann zuhause bleiben für die Arbeit. Kein Stau morgens und abends beim Pendeln. Ich nachmittags meinen Kindern mal bei den Hausaufgaben helfen. Ich kann auch mal am Wochenende arbeiten und dafür unter der Woche etwas unternehmen. Nicht länger den Tag durch den Wecker takten lassen. Wie entspannend das doch sein könnte..."

Niemand, nicht ein einziger hat so reagiert. Warum? Warum sucht keiner ein Ja zur Verteilung für sich selbst - um dann natürlich zu überlegen, wie das Projektziel immer noch erreicht werden kann?

Ist Autonomie/Freiheit so furchtbar? Ist es soviel angenehmer, die lieben Kollegen jeden Tag 9-17 sehen zu müssen? Steht das Wohl des Projektes (das anscheinend an der Colocation hängt) höher als mein Wohl?

Ich kann das nicht glauben.

Golo Roden hat gesagt…

Ich habe zunehmend das Gefühl, dass die Kritiker von verstreuter Entwicklung noch kein Projekt miterlebt haben, in dem verstreute Entwicklung funktioniert hat.

Aus dieser Empirie wird der (naheliegende, aber falsche) Schluss gezogen, dass man dies zur Regel erheben könne - verstreute Entwicklung funktioniert eben nicht und Colocation ist besser.

Dabei wird übersehen, dass es durchaus erfolgreiche verstreute Teams gibt - doch niemand fragt, was die anders machen. Niemand fragt, warum es bei denen und nicht bei einem selbst funktioniert.

Alle gehen davon aus, dass die angeblich erfolgreichen verstreuten Teams ja ein Sonderfall seien, sie das ganze sowieso nicht nachweisen könnten und sie - mal mehr oder weniger direkt postuliert - von verstreuter Entwicklung eigentlich keine Ahnung, zumindest aber keine Erfahrung damit haben. Anders kämen sie ja nicht auf die Idee, zu behaupten, dass es auch verstreut funktionieren würde.

Insofern kann ich mich Ralf nur anschließen:

Niemand, nicht ein einziger hat so reagiert. Warum? Warum sucht keiner ein Ja zur Verteilung für sich selbst - um dann natürlich zu überlegen, wie das Projektziel immer noch erreicht werden kann?

Ist Autonomie/Freiheit so furchtbar? Ist es soviel angenehmer, die lieben Kollegen jeden Tag 9-17 sehen zu müssen? Steht das Wohl des Projektes (das anscheinend an der Colocation hängt) höher als mein Wohl?


Ja - warum?

Hagen Siegel hat gesagt…

Räumliche Nähe, mmh? Das kommt darauf an, wie groß die Räumlichkeiten sind und was genau unter Nähe verstanden wird.

Je mehr Leute in einem Büro sitzen, desto häufiger fragt einer den anderen ´was quer über den Schreibtisch. Es geht häufiger die Tür auf und zu, es klingeln öfter die Telefone. Wenn z.B. alle fünf Minuten so eine "Störung" auftritt, kann man auch genausogut zu Hause bleiben. Es kommt keine hochwertige Software dabei raus, wenn man sich nicht konzentrieren kann und dauernd unterbrochen und gestört wird. Vielleicht bringen manche die selbe Leistung, auch wenn sie in einem "Hexenkessel" arbeiten müssen. Ich kann das von mir jedenfalls nicht behaupten.

Wenn räumliche Nähe bedeutet, dass die Entwickler im selben Gebäude sind, dann ist das okay. Die Arbeitsbediungen innerhalb der Entwicklungsbüros sollten aber ruhig und angenehm sein.

Ansonsten würde ich die Entwicklung in einem verteilten Team bevorzugen. Allerdings nur dann, wenn das Team aus erfahrenen Entwicklern besteht.

Holzhammer-Pauschalaussagen sind in den allermeisten Fällen falsch und deshalb sollte man davon Abstand nehmen. Es muss auch nicht immer nur schwarz oder weiss sein, oder?