Wo ein Entwicklungsteam noch an einem Ort sitzt, sollte es verteilt werden. Entwicklungsteams, die gebildet werden sollen, fangen am besten gar nicht erst an, sich an einem Ort zu versammeln. Verteilte Teams sollten der Default sein.
Ja, so denke ich inzwischen immer mehr. Co-location ist ein Problem.
Aber der Reihe nach:
Im Jahr 2001 wurde das Agile Manifest unterzeichnet von 17 umtriebigen Geistern - alle weiß, männlich, vor allem Amerikaner und im Durchschnitt zu dem Zeitpunkt wohl um die 50 Jahre alt. Das sage ich so, weil ich glaube, dass wir Agilität wie sie seitdem von den Unterzeichnern gepredigt und von anderen übernommen wurde, davon nicht unabhängig sehen dürfen. Die Unterzeichner sind auch nur Menschen. Sie sind mithin Kinder ihrer Zeit und ihrer Erfahrung. Sie hatten und haben einen je eigenen Horizont, in dem sie denken und innovieren können. Genauso wie Sie und ich ebenfalls.
Scrum wurde von Schaber/Sutherland Mitte der 1990er entwickelt. Da war Schwaber schon 50 und Sutherland wahrscheinlich auch. Sie haben sich darin eingebracht mit allem besten Willen und all ihrer Erfahrung. Nicht weniger - aber eben auch nicht mehr.
Die Frage ist daher: Was war ihre Erfahrung? Und was für ein Ziel lässt sich daraus ableiten?
Das Ziel beschreibt am Ende das Agile Manifest: Es geht um den Softwareproduktionsprozess. Der soll flüssiger werden, der soll näher am tatsächlichen Bedarf laufen. Die Softwareentwicklung soll sich nicht ablenken lassen durch eingefahrene Regularien, Werkzeuge, Dokumentationsanforderungen, Vertragsverhandlungen oder überdimensionierte, schnell veraltende Pläne.
Gut so! Das Manifest enthält wunderbare vier Maximen.
Und dennoch: Es geht um Produktivität. So sehen denn auch die Mittel aus, die zum Einsatz kommen:
- Statt einmaliger Großplanung lieber iteratives Vorgehen in Lernschleifen.
- Statt technischer Meilensteine lieber inkrementelles Vorgehen für schnelleres Feedback.
- Statt Abteilungsgerangel lieber cross-functional teams.
- Statt langsamer indirekter Kommunikation über Hierarchieebenen hinweg lieber schnelle persönliche Kommunikation auf Augenhöhe durch co-location aller Teammitglieder.
Habe ich noch etwas vergessen? Bestimmt. Aber ich glaube, das sind die zentralen Mittel agiler Softwareentwicklung. Auf die sind 50jährige Männer nach intensiver Beobachtung und Diskussion gekommen.
Das ist wunderbar - außer, wenn es nicht wunderbar ist ;-) Denn es steckt in diesen Mitteln Zeitgeist und technische Möglichkeit. Man wusste es halt nicht besser, man konnte nicht anders. Doch seitdem hat sich die Welt gedreht. Wir sind 20 Jahre nach Scrum, 14 Jahre nach dem Agilen Manifest.
Innerhalb meines bescheidenen Horizonts halte ich das iterative/reflektierende Vorgehen für zeitlos. Auch am inkrementellen Vorgehen habe ich nichts auszusetzen. Außer, dass ich es oft noch für zu grobgranular halte und die Iterationen mir zu lange dauern. Aber grundsätzlich bin ich ganz dafür. Und auch die cross-functional teams sind für mich eine sine qua non. Nur so lassen sich Abhängigkeiten flüssig entschärfen.
Bei der co-location hingegen bin ich nicht mehr dabei. Hier sehe ich die weithin real existierende agile Praxis in den 1990ern verharren. Schwaber, Jeffries, Martin & Co sind eben keine digital natives. Sie hatten Email, aber auch wenn Ward Cunningham mit von der agilen Partie war, waren Wikis kein für die Massen verfügbares Werkzeug. Social Media waren in den Kinderschuhen wenn überhaupt Smartphones gab es noch lange nicht. Verteilte Versionsverwaltung lag noch in der Zukunft. Infrastruktur in der Cloud zum kleinen Preis ließ sich noch nicht denken.
Und so sah man sich außerstande, etwas anderes als co-location für die Zusammenarbeit zu empfehlen. Das war ja auch viel besser, als Leute auf office cubicles zu verteilen, oder?[1]
Irgendwie schon. Aber dann doch wieder nicht. Denn ich sehe durch die co-location drei fundamentale Probleme in der Praxis entstehen:
- Co-location öffnet Unterbrechungen Tür und Tor. Wer im team room nahe beieinander sitzt, kann die Kollegen schnell mal ansprechen. Das ist auch Sinn und Zweck. Fowler sagt: “[I]t promotes lots of informal and deep communication between people on the team.” Was für den, der einen anderen anspricht eine tolle Vereinfachung ist, ist für den Angesprochenen hingegen oft das Gegenteil, nämlich eine Erschwernis seiner Arbeit. Wer angesprochen wird, wird unterbrochen, d.h. aus seinen Gedanken gerissen, im Arbeitsfluss gestört. Da macht es auch nichts, dass der Ansprechende ganz wohlmeinend oder sehr bedürftig ist. Unterbrechungen stören die konzentrierte Herstellung von Resultaten. Das gilt für Unterbrechungen durch Manager, die plötzlich im Raum stehen, genauso wie für Unterbrechungen durch Teammitglieder - oder auch selbstverschuldete Unterbrechungen durch Social Media Benachrichtungen.
- Co-location leistet unentdeckten Abhängigkeiten Vorschub. Wer im team room sitzt, muss sich tendenziell weniger Gedanken machen über das, was er braucht, um seine Resultate zu erzielen. Abhängigkeiten von Technologien oder Anforderungsverständnis müssen nicht vorher entdeckt und aus der Welt geschafft werden, sondern können ja im Zweifelsfall jederzeit durch Nachfrage bei einem Kollegen aufgelöst werden. Irgendwer weiß immer Bescheid, dafür ist das Team doch cross-functional. Daraus entstehen nicht nur Unterbrechungen für Kollegen, sondern auch geringere Produktivität. Denn so wie ein Koch produktiver ist, wenn er in Phasen arbeitet, also z.B. Gemüse erst komplett schneidet, so ist Softwareentwicklung auch produktiver, wenn sie in Phasen arbeitet; das sind mindestens Analyse, Entwurf, Implementation.[2]
- Co-location fördert monolithischen Code. Wenn auch nur irgendetwas an Conways Gesetz ist, dann dürfen wir uns nicht wundern, dass 14 Jahre Agilität den monolithischen Anwendungen nicht den Garaus gemacht haben.[3] “Organizations which design systems […] are constrained to produce designs which are copies of the communication structures of these organizations.” Und was für eine “communication structure” soll ein co-located team im team room haben? Eine sehr, sehr enge. Was bedeutet das für das “design”, d.h. die Struktur ihres Produktes Software? Es wird aus eng verbundenen Teilen bestehen.
Auch ich habe meinen Hintergrund. Vor dem sehe ich auf Agilität. Ich bin weniger am Prozess interessiert als am Code.[4] Der muss wandelbar, evolvierbar sein, sondern ist die Softwareentwicklung nicht zukunftsfähig.
Ja, da sehe ich das große Problem unserer Tage in der Softwareentwicklung: Wandelbarkeit. Sogar nicht nur Code, sondern auch Teams (und Unternehmen) müssen wandelbar sein, sich also anpassen können. Dazu gehört natürlich Reflexion, wie sie in der Agilität drinsteckt. Doch es braucht noch mehr. Ohne passende Strukturen lassen sich Ergebnisse der Reflexion nur schwer oder gar nicht umsetzen.
Die meisten Projekte leiden nicht unter technologischen Schwierigkeiten. Wir haben Hardware und Frameworks und Dienste, die leistungsfähig genug sind, um die Effizienzanforderungen an Software zu erfüllen. Das war bis vor 10 Jahren noch ganz anders. Deshalb war Wandelbarkeit für die Agilität auch kein großes Thema. Clean Code kam erst sieben Jahre nach dem Agilen Manifest und 13 Jahre nach Scrum.
Doch nun haben sich die Zeiten gewandelt. Wandelbarkeit ist das zentrale Thema - wenn man nicht grad dem nächsten noch besseren Framework hinterherjagt. Auch die aktuelle µService-Bewegung ist ein Ausdruck des Leidens am Monolithen, an der Unwandelbarkeit.
Und wodurch sind wandelbare Strukturen gekennzeichnet? Durch lose Kopplung. Ein älteres Prinzip gibt es wohl kaum in der Softwareentwicklung.
Lose Kopplung entsteht durch Kapselung (klare Schnittstellen, Autonomie, geringe Abhängigkeiten) und asynchrone Kommunikation.
Wenn man diese Eigenschaften für ein Softwaresystem will, wie ist das zu vereinbaren mit co-location im team room? Wie können lose Kopplung und auch wandelbare verteilte System einfach entstehen, wenn die, die sie herstellenn sollen, einander auf dem Schoß sitzen?
Hier sehe ich die vorherrschende Implementation von Agilität gegen eine Wand laufen. Man macht es sich schwer bis unmöglich, das zentrale Problem der Softwareentwicklung unserer Zeit zu lösen, wenn man als Default für die Teamorganisation den team room setzt.
Entwickler, die man im selben Raum zur selben Zeit sehen will, können eine Menge herstellen - aber entkoppelte Strukturen bzw. wandelbare Software ist sicherlich nicht das Produkt, was ihnen am leichtesten aus den Fingern fließt.
Das Agile Manifest ist gut, wofür es gedacht ist: Produktivität. Es kommt aber an seine Grenzen, wenn es Mittel verschreibt, die der Erfüllung anderer Anforderungen im Wege stehen, hier der Wandelbarkeit.
Deshalb mein radikaler Vorschlag: Geben wir die co-location auf! Setzen wir die Verteilung von Teams als Default. Befreien wir Teammitglieder von Bindungen an Raum und Zeit.
Wir haben genügend Kommunikationsmittel und Tools, um jederzeit Kontakt aufzunehmen zu Kollegen, egal wo sie sich befinden. Chat, Telefon mit Anrufbeantworter, Diskussionsforen, Wikis, Issue Tracker, Repositories, Videokonferenzen, online Whiteboards und was es noch alles gibt in tausend und einer Ausprägung. Asynchrone Kommunikation in unterschiedlicher Geschwindigkeit ist kein Problem. Jeder ist immer erreichbar. Gut so! Wir können unsere Anliegen immer zustellen - ohne den anderen zu unterbrechen. Das sorgt für konzentrierte Arbeit. Das ist gelebte Autonomie: Ich bestimmte selbst über die Nutzung meiner Zeit.
Wohlgemerkt schließt solcher Default der Verteilung nicht die synchrone Kommunikation aus. Zu einem Telefonat oder eine Videokonferenz kann man sich jederzeit verabreden. Das gilt sogar für persönliche Treffen, also Meetings. Niemandem wird verwehrt, sich eine Art der Zusammenarbeit zu wünschen, die für ihn und seine Resultate zuträglich ist. Nur muss das jeder mit den Kollegen verhandeln, denn die mögen andere Vorstellungen davon haben, wie sie ihre Ergebnisse am liebsten erzielen.
Verteilte Arbeit macht es schwerer, dass lokale Resultatsoptima entstehen. Ein Resultat kann weniger einfach auf Kosten vieler anderer Resultate hergestellt werden. Das Ganze wird betont, optimiert - ja, auch wenn ein Einzelner, ein individuelles Resultat dabei einmal zu kurz kommen sollte.
Dass man für verteiltes Arbeit ein paar andere oder gar mehr Soft Skills benötigt, als für die befohlene Arbeit am selben Ort zur selben Zeit wie andere, das mag sein. Man muss sich besser organisieren können, verantwortungsbewusster sein, expliziter und verlässlich kommunizieren… Aber nur weil das schwierig für manche sein mag (ja, auch und gerade für Manager), sollte das nicht bedeuten, dass verteilte Teams nicht anstrebenswert seien. Denn es steht viel auf dem Spiel. Es geht um nicht weniger als die verlässliche Herstellung von Wandelbarkeit. Ohne die gibt es nämlich keine Zukunftsfähigkeit. Sowohl für Code wie für Teams.
Mit verteilten Teams entstehen nämlich nicht nur (einfacher) wandelbare Softwarestrukturen, sondern auch wandelbare Teams. Wo ein Team verteilt arbeitet, ist die Einbindung von neuen Kollegen an beliebigen Orten einfacher. Das ist doch eine gute Nachricht für das Recruiting, oder? Dadurch kommen leichter neue Impulse zu allerlei fachlichen Aspekten ins Team.
Ganz davon abgesehen, dass verteilte Teams weniger hausinterne Infrastruktur brauchen. Heute gibt es alles, was das Entwicklerherz begehrt, in der Cloud. Wer wollte da auch nur einen Server kaufen? Was Entwickler brauchen, sind gute Laptops und viel Internetbandbreite. Gelegentlich noch ein Raum, um tatsächlich mal zusammenzukommen. Am besten mit Beamer/Smartboard und Flipchart. Und das Internet muss stets verlässlich da sein wie Strom aus der Steckdose. Ohne lästige Spezialfirewalls, die Superproxys brauchen, die den Zugriff auf ein DVCS behindern.
Wohlgemerkt, ich rede hier über Entwickler, nicht über sonstige Mitarbeiter von Unternehmen. Was die brauchen, ist eine andere Sache. Aber nur weil die vielleicht etwas brauchen - zum Beispiel ein total supersicheres Firmennetz -, sollte das nicht bedeuten, dass die Softwareentwicklung sich aus Solidarität auch ein Bein hochbinden muss.
Bottom line: Ich glaube, die Zeit der co-location als Default ist vorbei. Angesichts der Kommunikationsmöglichkeiten, die wir haben, hat sie den Punkt erreicht, wo sie kontraproduktiv wird.
Ja, wir haben das Zusammenhocken lieb gewonnen. Irgendwie ist es auch kuschelig mit den Kollegen. Aber was wollen wir? Kuscheln oder wandelbare Software?
Wer kuscheln will, kann z.B. per Chat im Team anfragen, wer mitmachen möchte. Dann kann ein Meeting vereinbart werden. Das sollte jedoch die Ausnahme sein. Synchrone persönliche Kommunikation vieler Teammitglieder macht vielleicht ein gutes Gefühl - aber es wird andererseits auch ganz schnell ganz viel Geld verbrannt.
Die Väter der Agilität haben es gut gemeint. Doch sie waren eben auch begrenzt in ihrer Erfahrung mit Kommunikationstechnologie. Ken Schwaber konnte z.B. nicht anders, als lange Jahre seines Lebens mit Telefon ohne Anrufbeantworter zu leben und zu arbeiten. Dann mit Anrufbeantworter und gelegentlichem Fax. Dann irgendwann später mit Email usw. Kein Wunder, dass er und die anderen co-location als Wunderwaffe empfanden. Irgendwie liegt sie uns ja auch im Blut. Die Bandbreite der Kommunikation ist da so schön hoch.
Aber kuschelige Bandbreite ist eben nicht alles. Wenn ungehinderte Kommunikation in hoher Bandbreite die Norm ist, ist irgendetwas optimiert – und irgendetwas bleibt auf der Strecke. Das ist die Wandelbarkeit.
Drum sage ich: Vorsicht vor der co-location!
So viel Verteilung und Autonomie und Entkopplung wie möglich, so wenig co-location wie nötig.
-
Wir können spekulieren, wie das Agile Manifest ausgesehen hätte, wenn 50% der Unterzeichner Frauen gewesen wären. Oder das Durchschnittsalter 25 Jahre. Oder unterschiedliche Kulturen vertreten gewesen wären. ↩
-
Wer hier herauslesen will, dass ich für Big Design Up-Front (BDUF) wäre, liegt falsch. Diese Phasen können manchmal nur Minuten oder Stunden dauern. Selbst in der agile Praktik TDD stecken sie drin - ohne dass das betont würde. 30 Minuten Entwurf mit 2 Stunden folgender Implementation können 5 Stunden vermeintlich reiner Implementation ersetzen, in denen der Entwickler dauernd in unvermutete Abhängigkeiten läuft. Dass man durch beliebig lange Analyse- und Entwurfsphase alle Abhängigkeiten entdecken könnte, behaupte ich auch nicht. Aber ein gesundes Maß an Analyse und Entwurf ist nötig; mehr als oft aufgewandt wird in agilen, co-located Teams. ↩
-
Ganz davon abgesehen, dass Agilität ja nicht Wandelbarkeit als ausdrückliches Ziel hat. Wie man ganz deutlich an Scrum sehen kann, kümmert sich der agile Prozess gar nicht um die Sache - Code -, sondern nur um den Rahmen für die Produktion der Sache. Nicht umsonst hat Jeff Sutherland nun auch ein Buch geschrieben, das Scrum auf alle möglichen Arbeitsfelder anwendet (“The Art of Doing Twice the Work in Half the Time”). ↩
-
Allerdings verschiebt sich dieser Fokus notgedrungen in den letzten Jahren. Denn ich merke, dass ich die Verbesserungen, die mir für Code vorschweben, in Unternehmen nicht gut verankert bekomme, wenn mir der Prozess oder gar die Unternehmenskultur egal ist. Aber das ist ein Thema für einen anderen Artikel… ;-) ↩
18 Kommentare:
Hallo Ralf,
ich kann Deiner These, dass Co-Location nicht sein sollte, nicht zustimmen.
Leider ist nämlich die Allen Curve aktueller denn je, wie jetzt gerade erst herausgefunden wurde. Dachte man bislang, dass lediglich die Intensität der direkten (physischen) Kommunikation abnehmen würde, je weiter Menschen räumlich voneinander getrennt sind, so trifft dieses interessanterweise auch auf mediale Kommunikation via Email, Telefon, etc. zu: http://www.harvardbusinessmanager.de/blogs/wie-raeumliche-distanz-die-kommunikation-beeinflusst-a-1015090.html
In der europäischen Raumfahrt arbeiten Entwickler, Konstrukteure und Systems Engineers gewöhnlicherweise in sogenannten Concurrent Design Facilities zusammen, weil die Komplexität der Missionen und der zu entwickelnden Systeme derart hoch ist, dass man das "remote" wahrscheinlich kaum hinbekommen würde: http://www.esa.int/Our_Activities/Space_Engineering_Technology/CDF Mich wundert es sowieso, warum CDF's nicht auch in anderen Branchen, wie Automotive oder Railway Transportation anzutreffen sind - gehört habe ich bislang davon noch nicht.
Natürlich ist das planlose Zusammenpferchen von Entwicklern in einem Großraumbüro nicht gut, keine Frage. Es gibt aber mannigfaltige Möglichkeiten das entsprechend zu gestalten.
Die Prämisse hinter deinem Argument ist: Mehr Kommunikation ist besser.
Denn wenn die Allen Curve sagt, dass die Kommunikation abnehme mit der Entfernung, und du das als Argument für co-location anführst, dann meinst du ja, dass hohe Kommunikationsdichte zu wünschen ist. Sonst bräuchte es keine Nähe.
Aber genau das (!) ist es ja, was ich kritisiere. Du lieferst mir also ein Argument. Danke :-) Ich behaupte also, dass wir nicht mehr, sondern weniger (!) Kommunikation haben müssen. Viel weniger sogar. Raus aus dem ständigen Rauschen der Kommunikation, rein in die Ruhe und Konzentration.
Wieviele Teammitglieder sitzen mit Kopfhörern im team room, damit sie den ganzen Lärm der anderen nicht ertragen müssen? Der eine plaudert mit dem andern über eine wichtige technische Frage, der nächste telefoniert mit dem Support, der Dritte wird von einem Manager in die Mangel genommen...
Aber wer will denn gezwungen sein, Musik zu hören?
Wir brauchen nicht besonders viel Kommunikation, sondern relevante Kommunikation und vor allem verlässliche. Team rooms kaschieren insofern auch Unzuverlässigkeit sehr schön. Face2face kann man nicht so unzuverlässig sein wie bei der Beantwortung einer Email.
Ich bleibe dabei: Da sind Skills zu lernen, klar. Verlässlichkeit muss geübt werden. Aber die Gewinnchance ist groß.
Und wer will, der kann sich große, verteilt entwickelte Systeme gern als Belege für die schiere Möglichkeit solcher Arbeit zu Gemüte führen. Open Source wird so weltweit entwickelt mit gutem Erfolg.
Wenn Open Source sonst schon für so vieles herhalten muss, dann gern auch hier :-)
PS: Über das, was Raumfahrtingenieuren gut tut, kann ich nichts sagen. Ich sehe in meiner täglichen Arbeit, was team rooms für Schaden anrichten. Störung, Konzentrationsmangel, nachlässige Entwürfe, Arbeit auf Zuruf, enge Kopplung grassieren.
Da kann man versuchen, mit weiteren Regeln es zu verbessern. Und noch einen Stillarbeitsraum einrichten. Aber warum nicht mal den grundlegenden Glaubenssatz hinterfragen? Ist co-location eigentlich wirklich, wirklich nötig?
Wenn es besser werden soll, muss es halt mal anders werden. Hier wäre ein Aspekt, den man anders gestalten kann - und dabei auch noch Geld spart.
Nun ja, ich denke es ist kein Geheimnis, dass viele Projekte unter zu wenig Kommunikation leiden, oder sogar schon gescheitert sind.
Ich würde eher sagen, dass eine angemessene Kommunikationsdichte zu wünschen ist. Und große, räumliche Distanz tendiert eher dahin, dass die Kommunikationsdichte möglicherweise zu gering wird. Das besagt meines Erachtens die Allen Curve.
Der sogenannte Team Room, also ein großer Raum wo alle Teammitglieder lediglich hineingepfercht werden, ist natürlich keine adäquate Lösung für Wissensarbeiter, da bin ich auf Deiner Seite.
Es kommt stark auf die Gestaltung des Raums an. Die Concurrent Design Facilities der ESA finde ich dahingehend faszinierend, weil sie, wenn erforderlich, ein hohes Maß an Kollaboration und Kommunikation ermöglichen, aber in unmittelbarer Nähe auch Rückzugsgebiete für konzentrierte Einzelarbeit existieren, oder kleinere Meeting-Räume, wo man in kleinen Teams zusammenarbeiten kann. Mit anderen Worten: die Räumlichkeiten und ihre Infrastruktur sind auf die Bedürfnisse und Anforderungen der dort arbeitenden Menschen zugeschnitten. Das ist vorbildlich, finde ich.
Insofern stimme ich Dir zu, dass einfache Team Rooms in Form von Großraumbüros mit vielen Arbeitsplätzen sehr schädlich sind.
Open Source ist übrigens m.E. dahingehend kein gutes Beispiel, weil nur vergleichsweise wenige dieser Projekte wirklich einen großen, durchschlagenden Erfolg haben, und auch bei weitem nicht alle eine gute Qualität aufweisen können. Und dort, wo es gut funktioniert, gibt es äußerst restriktive Regeln - viel strenger, als ich es in vielen Organisationen gesehen habe.
Das Problem bei Kommunikation ist: woher wissen wir, wie viel richtig und angemessen ist?
Die Frage ist doch, warum womöglich nicht genügend kommuniziert wird?
Ich sehe da vor allem diese Gründe:
1. Unklarheit in Bezug auf Resultate. Wer nicht weiß, was er machen soll, der ist still. Führung tut Not.
2. Unklarheit in Bezug auf Kommunikationstools. Wer nicht weiß, wie er was wann benutzen soll, der scheut die Kommunikation. Übung tut Not.
Wie konkret Verteilung eines Teams aussieht, lasse ich mal dahingestellt. Ich würde sagen, alles beginnt mit Autonomie. Lass die Leute doch wählen, wo sie wann arbeiten. Stelle nur sicher, dass sie immer erreichbar sind.
Ob einer im Stillarbeitsraum sitzt oder zuhause... egal. Ob einer um 5h arbeitet oder um 15h... egal.
Es zählt nur eines: Dass Resultate erzielt werden. Welche das sind, das wird auf Augenhöhe gemeinsam festgelegt.
Wer ein Ziel hat, läuft los und versucht es zu erreichen. Dafür kommuniziert er nach Bedarf. Soviel Eigenverantwortung und Erwachsenheit darf sein, oder?
Weil nun aber die anderen nicht mehr zwangsläufig neben einem sitzen, muss man das Kommunikationsverhalten umstellen. "Auf Zuruf" geht nicht mehr. Und das ist ein Feature dieser Organisation!
Der Preis der Ungestörtheit ist natürlich Verlässlichkeit. Man muss die Kommunikationskanäle im Blick behalten und verlässlich bearbeiten. Das muss man vielleicht üben. So wie andere Präsentationen üben müssen.
Aber der Zweck ist klar: Konzentrierte Arbeit.
Auch muss man üben, mal ein bisschen nachzudenken bevor man loshackt. Ja, sorry, es hilft nix ;-) Die Tage der ad hoc Programmierung sind vorbei. Bye, bye Künstlerhackerleben :-)
Warum geht das bei OSS nicht immer gut? Siehe oben. Es fehlt Führung, d.h. ein klares gemeinsames Ziel. Und es fehlt die Übung in verlässlicher Kommunikation.
Beides kompensieren zu wollen durch co-location halte ich für falsch.
Es müssen vielmehr Verhältnisse her, die klar machen, wo die Schwächen sind.
Als Freiberufler arbeite ich mit meinem Kunden seit Jahrzehnten auch nicht anders. Gelegentlich sehen wir uns. Zwischendurch kommunizieren wir, wie es gerade passt. Am besten aber asynchron, damit jeder möglichst viel ungestörte Zeit hat.
Wieviel Kommunikation ist angemessen? So wenig wie möglich, so viel wie nötig :-)
Die Frage ist doch, was brauche ich, um mein pers. Ergebnis zu erreichen? Oder wie kann ich helfen, um das Teamergebnis zu erreichen.
Da reden manche zuviel. Denen muss man Feedback geben. Da hilft, Abhängigkeiten vorher besser zu klären. Die können ja überall lauern. Der eine versteht die Anforderungen nicht, der nächste beherrscht sein Tool nicht. Das wird aufgedeckt.
Da reden manche zuwenig. Denen muss man das Feedback geben. Sie antworten z.B. unzuverlässig oder liefern schlechte Resultate. Also müssen die etwas üben. Jenachdem.
Das ist ein Lernprozess. Als wäre das was Neues. Als müsste man bei co-location nichts lernen.
Für das Ziel konzentrierte Arbeit und hohe Wandelbarkeit sehe ich das als geringen Preis an.
Sehr interessanter Artikel. Ich finde ihn etwas "amerikanisch", wenn ich mir diese Charakterisierung erlauben darf -- ein typischerweise als Problem gesehenes Phänomen (Kommunikationsprobleme) wird hier als Chance zum Lernen ("opportunity") dargestellt. Ich mag die Idee dahinter, aber aus der Erfahrung bin ich geneigt zu glauben, dass die geforderte Lernfähigkeit im Bereich Kommunikation für viele dann doch eher ein Problem als eine Chance ist. Es gibt sie immer noch und immer wieder, die gerne und mit Begeisterung als Lonesome Cowboys coden, sich in ihrer Arroganz ihren technischen Fertigkeiten sonnen, aber aufgrund ihrer mangelnden kommunikativen Fähigkeiten mehr Probleme schaffen als sie lösen. Der enge Einbezug in ein Team ist da hilfreich, wobei man sicher argumentieren kann, dass Führung ("Leadership") vielleicht sogar noch wichtiger ist.
Hallo die Herren,
ich möchte mal in die Diskussion um das Thema verteilt vs. co-located mit einem kleinen Erfahrungsbericht einsteigen:
Ich studiere im Moment nebenberuflich an der DHBW Stuttgart, um meinen Master in Informatik zu machen. Was hatten wir da als Fach? Agile Prozessmodelle. Logisch! Wir haben also ganz theoretisch gelernt, wie Extreme Programming und Scrum gelebt werden sollen, haben das Agile Manifest besprochen etc.
Dann wurde der Kurs in zwei Gruppen geteilt und wir bekamen als Aufgabe zwischen zwei Präsenz-Blöcken eine App zu entwickeln. Für iOS, Android und Windows Phone. Und wir sollten Scrum als Vorgehensmodell nutzen. Verteilt!
Unser Dozent (Prof. Dr. Eckhart Hanser, Autor von "Agile Prozesse: Von XP über Scrum bis MAP" http://www.springer.com/computer/swe/book/978-3-642-12312-2) hat uns da sozusagen als "Laborratten" genutzt. Er wollte nämlich mit unserem Kurs herausfinden, ob Scrum auch verteilt gelebt werden kann. Um das Ergebnis vorweg zu nehmen: Es kann. Aber nicht die reine Scrum Lehre nach Ken Schwaber, das ist auch klar.
Was haben wir also gemacht? Zunächst einmal haben wir uns vor Ort - alle zusammen, co-located - eingerichtet. Haben die Rollen und Regeln festgelegt. Und die Kommunikationsplattform: Yammer war unser Mittel der Wahl, denn das kannten wir schon aus der vorhergehenden Vorlesung über Social Media. Zur Sourcecode-Verwaltung haben wir ein Open Source-Projekt in GitHub angelegt.
Die Sprints waren - der Tatsache geschuldet, dass wir die Aufgabe nur zu Hause, neben der normalen Berufstätigkeit durchführen konnten - länger als üblich. Nämlich 5 Wochen. Aus den "Daily Scrums" wurden "Weekly Scrums" in Form von Web Konferenzen (erst mit Vitero von der DHBW, später mit TeamViewer). Dabei mussten wir auch erst einmal lernen, wie wir uns verhalten mussten. Zu Anfang waren das ca. 1,5-stündige Diskussionen über Technik, Implementierung etc. Unser letztes Weekly Scrum (nach 3 Sprints) dauerte gerade noch 12 Minuten. Die offenen Fragen und technischen Diskussionen haben wir in der Zeit sukzessive in Yammer verlegt. Ich für meinen Teil (ich hatte die Rolle des Product Owner) habe es mir einfach angewöhnt einmal täglich in Yammer zu schauen, was für neue Fragen aufgetaucht sind, habe die Fragen, die mich betrafen, beantwortet und die anderen Diskussionen einfach nur gelesen um informiert zu bleiben. An und für sich hat das gut funktioniert.
Trotzdem gab es zwei Präsenztermine, an denen möglichst viele Mitglieder des Teams bei einem Mitglied zu Hause zusammen gekommen sind um komplexe Bereiche der App gemeinsam zu implementieren. Gerade für Kern-Aufgaben wie die Implementierung des Kommunkiations-Moduls, das von allen anderen Modulen später verwendet wurde um auf die Datenbasis zuzugreifen, machte es echt Sinn co-located zu sein. Denn alle mussten genau wissen wie dieses Modul später zu nutzen ist, wie es funktioniert etc. Und es musste stabil und schnell funktionieren. Da war es einfach sinnvoll die geballte Expertise von 5-6 IT Master-Studenten in einem Raum konzentriert zu haben. Danach konnten alle ihre eigenen Module für bestimmte Bereiche der App mehr oder weniger unabhängig implemeniteren (das zweite gemeinsam entwickelte Modul war das HTML5-Offline-Daten-Modul, das unter das Kommunikations-Modul geschoben wurde um Daten auch in Offline-Szenarien anzubieten).
Unser Fazit aus der Übung war dann auch, dass Scrum durchaus verteilt gelebt werden kann. Allerdings muss man erst lernen, was man wann und wie kommuniziert/diskutiert. Mit der Wahl von Yammer haben wir einen Glückstreffer gelandet, denn dort konnten wir super asynchron kommunizieren, Dokumente austauschen etc. Ganz auf Präsenztermine verzichten konnten wir aber auch nicht.
Hallo Ralf,
also ich bin zu dem Thema bisher andere Erfahrungen und kann deiner Argumentation hier nicht ganz zustimmen. Ich möchte dir aber dennoch danken, dass du immer wieder auch kontroverse Themen aufbringst und ich glaube solche Querdenker wie dich brauchen wir dringend in unserer Branche.
Deine ganze These basiert ja auf der Annahme, dass die Organisationsstruktur sich in der Software-Struktur widerspiegelt. Selbst wenn wir das mal als gegeben hinnehmen, dann ist das für mich noch lange kein Argument gegen Co-Location. Wer sagt denn dass ein co-located Team wirklich monolithisch ist? Und vor allem was wäre denn die Alternative? In deinem Post und Kommentaren hast du nur die Nachteile von Co-Location aus deiner Sicht beleuchtet. Aber bei einem verteilten Team das nach deiner Vorstellung lose gekoppelte Einzelkomponenten bauen soll, da kommen bei mir meine schlimmsten Alpträume meiner Vergangenheit wieder hoch. Das bedeutet doch Silos, einzelne Entwickler die sich nur um ihre Komponente und die Schnittstellen kümmern aber gar nicht das große Ganze im Blick haben. Selbst wenn die Software-Struktur bei co-located Teams nicht optimal sein sollte, in unseren Projekten haben wir das Gesamtergebnis durch echte Team-Arbeit klar verbessert. Dass das auch ohne co-location funktionieren kann, will ich gar nicht bestreiten, aber es ist zumindest deutlich aufwändiger und es ist so schon schwer genug, die Leute dort hin zu bekommen.
Also ich werde weiterhin co-location als die Idealform ansehen. Ich danke dir aber für den Gedankenanstoß, dass bei co-located Teams stärker auf Entkopplung im Code geachtet werden muss. Da können wir sicher noch besser sein, aber ich glaube das gilt immer.
Hi Ralf,
deine Forderung nach räumlicher Entkopplung für mehr Ergebnisentkopplung teile ich.
Denn der Anspruch in (kurzen) Iterationen auf einander zu zu arbeiten legt die Messlatte für die Kommunikation deutlich höher und fordert jedem Einzelnen ein hohes Maß an Disziplin ab.
Ich skizziere kurz das Problem zur Lösung. Eine oder Zwei Hände voll Personen sitzten co-located in einem Büro. Jede Anforderung wird instant in Code gegossen und dann Stück für Stück beim hacken gelernt, geforscht und redesignt (nicht refaktort).
Der Kollege nebenan soll mal schnell draufkucken weil die aktuelle Sackgasse scheinbar unumgänglich ist und vielleicht hat der kautzige Nerd in der Ecke eine Idee wie man mit einem düsteren Kunstgriff ohne zeitverflust aus der Sackgasse und zum Ziel kommt.
Wir fangen an irgendwas zu machen weil die personellen Resourcen AdHoc erreichbar sind, sie sitzten ja nur 5m weg. Die räumliche Trennung ist der größte Knüppel den man diesem Vorgehen in den Lauf werfen kann. Hier muss erst überlegt, geredet und gemalt werden und dann kann jeder munter hacken. Aber eben mit einem klaren Ziel und einer echten, greifbaren Vorstellung der
Lösung.
Wenn man das co-located hinbekommt und die anderen nette Menschen sind, spricht nichts dagegen den ArbeitsRaum zu teilen. Ich mag meine Kollegen und hätte auch nicht die Freiheit mir meinen Arbeitsort auszusuchen und spreche daher als Blinder über die Farben. Aber ich sehe die Probleme die entstehen wenn man mal schnell jmd Fragen kann Tag für Tag live und in UHD.
Aus diesem Grund sehe ich das all zu verrufene BDUF in einem neuen Licht. Natürlich weiß keiner was wir in 4 Wochen für Probleme haben und sicherlich kann ich dir auch nur schwer zusagen was ich bis in 10 Wochen an Features in die Version gepusht hab. Deshalb wurde der komplette Ansatz des "erstmal denken, reden, skizzieren" über Board geworfen und wir fangen ganz agil sofort
an mit hacken. Vielleicht wäre ein "Short iterational mico-BDUF" eine ernste Alternative mit dem Besten aus beiden Welten. Natürlich immer nur auf kleine Featurehäppchen bezogen und nicht für alles sofort.
Erst co-located oder wenigstens kollaborativ ein Problem analysieren, technische Fragen klären, einen Flow malen, ein Screendesign einholen etc. Dann wenn alle Karten auf dem Tisch liegen am besten daheim, in Ruhe ohne Zwischenrufe und Unterbrechungen, total fokusiert den Code zur erarbeiteten Lösung implementieren.
Wie unwahrscheinlich wichtig Kommunikation ist, wissen wir alle. Aber die richtige Form und der passende Zeitpunkt spielen eine erhebliche Rolle, denn die Kommunikation ist in diesem Fall auch nur Mittel zum Zweck, nämlich gute Software.
@Alexander: Danke für deinen Erfahrungsbericht. Schön, dass das bei euch so positiv ausgegangen ist. Nichts anderes hatte ich erwartet ;-) Niemand sage also, es ginge nicht.
Allerdings: Es geht eben nicht "einfach so". Man muss sich Mühe geben. Und man muss manches üben. Aber das ist doch nichts Neues, oder? Muss man immer. Wer glaubt, er sei nach dem Abi oder Bachelor oder so fertig, der hat etwas nicht begriffen.
Ich glaube sogar, dass man daran, wie ihr gearbeitet habt, noch mehr verbessern kann. Ihr habt ja die Verteilung noch versucht, mit Scrum überein zu bringen. Aber das ist ein anderes Thema.
@Thomas: Wer sagt, dass co-located Teams monolithisch sind? Das sagt im Grunde Fowlers Definition des team room. Deshalb (!) wird co-location eingeführt: damit enge Kommunikation entstehen kann. Und "eng", d.h. möglichst direkt und unmittelbar (!), ist für mich per definitionem monolithisch.
Und der ewige Silo der als Alternative heraufbeschworen wird... Silos entstehen also, wenn man nicht nebeneinander sitzt? Und es gibt keine Silos, wenn man nebeneinander sitzt? Hm... die Gleichung will mir nicht in den Kopf.
Ich dachte, das hat eher mit einem Prozess oder einer Organisation zu tun. Und ich habe nie behauptet, dass es beides nicht geben sollte, nur weil man nicht co-located ist. Review findet auch nicht statt, wenn die Leute im selben Raum sind, keine Sorge. Das ist für viele Teams kein Problem.
Es ist eine Frage des Anspruchs und nicht der räumlichen Nähe, ob man agil arbeitet, clean code produziert und Silos vermeidet.
Den strukturellen Silo will man ja auch. Das ist Entkopplung.
@Rico: Finde ich gut zusammengefasst: "Wie unwahrscheinlich wichtig Kommunikation ist, wissen wir alle. Aber die richtige Form und der passende Zeitpunkt spielen eine erhebliche Rolle, denn die Kommunikation ist in diesem Fall auch nur Mittel zum Zweck, nämlich gute Software." So isses. Und mir scheint, dass co-location einfach nur einen Fliegenklatsche ist, mit der man sich ein Problem vom Hals schaffen will. "Setzen wir die Leute mal zusammen, dann kaspern die das schon aus. Alles informell. Kurze Wege. A dream comes true."
Well... bis der Traum dann ein Code-Albtraum ist. Und man sich wundert, wie das passieren konnte. Und/oder die Verlässlichkeit im Keller, weil es ja immer locker informell zugeht.
Eine strenge Hierarchie der Kommunikation "wie früher" mag unterkomplex gewesen sein. Aber team room/co-location als Default scheint mir oft überkomplex. Das führt dann zu Software, die das widerspiegelt.
Und du sprichst "µDUF" an. Ja, so sehe ich das auch. (Das B hab ich mal weggelassen wg dem µ.) Explizite "Microplanung" scheint mir wichtig, um Abhängigkeiten zu einem guten Teil zu entschärfen. Sonst entstehen zuviele Störungen. Noch schnelleres Feedback und noch häufigere Fertigstellungspunkte finde ich sehr sinnvoll. Deshalb auch zu Alexander, dass ich Scrum für überdenkenswert halte.
Einander Fragen und Antworten zuwerfen im team room, das ist kein Feedback generieren. Das ist Unsystematik.
Aber es kommt aufs rechte Maß an. Und da sehe ich, dass sich das immer mal wieder ändert. Es gibt Abschnitte, die erfordern engere Kommunikation, dann wieder kann es loser sein. Und mal mehr vordenken, mal weniger. Wer in co-location eingepfercht ist, verliert die Fähigkeit, sich solchem Bedarf anzupassen.
Ralf, das ist ja mal wieder ein gelungener Versuch von Dir, alle Leute aufzuregen, sehr cool! :-)
Kurze Anmerkung dazu: Conways Gesetz sagt ja: "Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure."
Das bedeutet m.E.: Wenn eine Organisation in ihrer Kommunikationsstruktur eine Schnittstelle hat (z.B. zwei Teams an verschiedenen Standorten), dann wird das Design des Systems an der Stelle ebenfalls eine Schnittstelle haben (z.B. zwei große Subsysteme, die sich aufrufen).
Das ist jedoch eine gerichtete "wenn A dann B"-Aussage! Daraus darf ich "wenn nicht B, dann nicht A" machen, also: wenn ein Monolith, quasi ohne Schnittstellen, erschaffen wurde, kann man daraus schließen, dass die Organisation wohl auch keine Schnittstellen gehabt hat, z.B. weil die Leute alle co-located saßen.
Umgekehrt gilt das aber nicht! "wenn nicht A dann nicht B" kann man daraus nicht ableiten! Daher kann es sein, dass Deine Behauptung "wenn co-located, dann Monolith" durchaus stimmt, doch sie folgt eben nicht aus Conway's Law.
Cheers,
Matthias
@Matthias: Wo heilige Kühe in Massentierhaltung leben, da ist es nicht so schwer, mal eine zum Schlachten zu finden :-)
Ich freue mich, wenn du die schiere Möglichkeit des Zusammenhangs zwischen co-location und Monolith in Betracht ziehst. Was könnte ich mehr erwarten? ;-)
Ob du da nun auch noch einen Anklang von Conway's law siehst oder nicht, ist mir nicht wichtig.
Genauso wie die Agilität bin ich natürlich weit davon entfernt, Beweise für irgendetwas zu haben. Die Agilität kommt ohne Empirie aus, ich auch :-) Dort wie hier geht es um Hypothesen. Am besten aber natürlich immer, wenn die klar formuliert sind und der Zweck des Ganzen deutlich gemacht ist.
Für die co-location der Agilität formuliere ich mal: "Co-location führt zu (kurz- bis mittelfristig) höherer Produktivität durch Kommunikation die direkter, breitbandiger und synchron ist. Denn solche Kommunikation räumt Abhängigkeiten, die die Arbeit behindern, schneller aus."
Und die Hypothese mag sogar verifizierbar sein. Bei gegebenen unentdeckten (!) Abhängigkeiten (unknown unknowns) wird der gewünschte Effekt durch co-location erzielt. Könnte sein. Da könnte man ja mal Experimente à la Bavelas-Leavitt machen (http://www.analytictech.com/networks/commstruc.htm).
Meine Hypothese ist jedoch eine andere! Mein Thema ist nicht Produktivität. Mein Thema ist Wandelbarkeit - womöglich sogar auf Kosten (!) von kurzfristiger Produktivität.
"Wenn Teammitglieder autonom sind in der Entscheidung über Arbeitsplatz und mit Arbeitsmitteln ausgestattet sind, die die Mobilität fördern, dann steigt die Wandelbarkeit des Softwareproduktes und die Zuverlässigkeit. Denn um in Flexibilität zu produzieren, muss mit Abhängigkeiten bewusster umgegangen werden; das führt zu einer für die Wandelbarkeit günstigen Modularisierung."
Teammitglieder, die ihre Autonomie hoch schätzen und erhalten wollen, werden daran interessiert sein, sowohl ihre Werkzeuge wie auch ihr Produkt so zu gestalten, dass sie die Autonomie nicht negativ beeinflussen.
...
...
Wenn ich zuhause oder im Café oder im Büro arbeiten will, wähle ich keinen Desktop-Rechner und auch keine inhouse Server mit VPN-Zugang und auch nicht SVN.
Wenn ich zügig meine Aufgaben abarbeiten will, dann kläre ich Abhängigkeiten möglichst frühzeitig - und entkopple mich ansonsten von anderen. Laufe ich dann trotzdem noch in unerwartete Abhängigkeiten, dann wähle ich einen geeigneten Kommunikationsweg, um sie aufzulösen.
Weil konzentrierte Arbeit für mich und ad hoc Auflösung von Abhängigkeiten für andere im Widerspruch stehen, muss sehr bewusst kommuniziert werden. Meine Freiheit in der Arbeitsweise kann schnell die Freiheit anderer einschränken. Das wird bei verteilter Arbeit sehr viel bewusster. Verteilte Arbeit hat also eine ethische Dimension. (vgl. den Ethischen Imperativ, http://de.wikipedia.org/wiki/Ethischer_Imperativ)
(Co-located gilt das natürlich eigentlich genauso. Nur sitzen da schon alle mit geladenem MG unterm Tisch nebeneinander. Wahl der Mittel ist keine Option, wenn die Aufrüstung am Anschlag ist: synchrone Kommunikation.)
Ich schließe keine Kommunikationsform aus. Auch nicht das Meeting, auch nicht die Arbeit in co-location.
Nur sehe ich im Default (!) der co-location, also dem Ausrichten aller Ressourcen (Raum, Zeit, Infrastruktur) darauf ein Problem. Die Kommunikationsstukturen fördern den Monolithen. Die in dieser Organisation innewohnende Starrheit führt zur Atrophie der generellen Flexibilität, d.h. nicht nur der softwarestrukturellen, sondern auch der geistigen, emotionalen, organisatorischen.
Ja, ich fasse das sehr weit. Und damit komme ich natürlich ans allgemein Gesellschaftliche: Es ist zu überlegen, wieviel Wandelbarkeit ein Produkt haben kann, das von Menschen hergestellt werden, die ihr Leben auf Unwandelbarkeit ausgelegt haben: sie lassen sich abhängig beschäftigen, streben nach einer Immobilie und immobilisieren sich durch steigenden Fixkosten und persönliche Abhängigkeiten weiter.
Ich behaupte nicht, dass irgendetwas davon schlecht sei. Kann man alles so machen... Aber führt dann womöglich nicht zu den gewünschten Ergebnissen. Seltsamerweise.
Guter Artikel, noch bessere Kommentare. Danke! Grundsätzlich teile ich deine Ansicht. Dennoch würde ich, vor allem in Rücksicht auf ein vielleicht nicht so erfahrendes Entwicklungsteam, einen Kompromiss bevorzugen. Wie bei Open-Source Projekten auch, ist ein 2-4 wöchiger Sprint innerhalb eines Team-Rooms eine sehr lohnenswerte Sache. Sollten Open Source Projekte das Kapital haben, wird diese Möglichkeit natürlich auch wahr genommen. Für ein paar Tage, Quick-and-Dirty, meinetwegen monolithisch, einen großen Teil eine Aufgabe gemeinsam zu bearbeiten hat großen Wert. Natürlich muss darauf eine Bewertungs- und Qualitätsphase voraus- und nachgehen. Ich denke 6-8 Wochen in sehr kleinen Teams (Pair) oder allein sind dabei sehr, sehr hilfreich. Das ist sogar hilfreich um Gemeinsamkeiten und Unterschiede zu finden und diese später als konkrete und fokussierte Arbeitsaufgaben zum refactor vorzubereiten.
Unternehmen haben das Kapital und damit auch die Möglichkeit für eines solchen Vorgehen. Leider nutzen Unternehmen und Berater die Chance eines agilen Vorgehens, Entwicklung und damit auch Architektur nicht vollständig aus. Sie ist meist einseitig - unbedingte und direkte Kommunikation steht abseits im Vordergrund. Alles andere muss sich unterordnen. Warum - Kontrollverlust? Wie seht Ihr das?
@Mike: Klar, nix muss übers Knie gebrochen werden. Es gibt Anforderungen oder Phasen (in der Teamentwicklung), die eine co-location mal nahelegen. Auch ich kenne ein positives Gefühl der Nähe zu Kollegen.
Sowas kann am Anfang stattfinden - aber vielleicht kennt man da gar nicht alle Teammitglieder. Oder es kann zwischendurch (immer mal wieder) stattfinden. Whatever. Egal. Wenn es einem Bedürfnis dient und der grundsätzlichen Flexibilität und Modularität nicht im Wege steht, find ich das völlig ok.
Mir ging es darum, den Default (!) zu verändern. Wenn der Default "Verteilung" lautet (oder noch allgemeiner: Freiheit, Autonomie), wenn also Flexibilität auf allen Ebenen als hohes und zu bewahrendes Gut anerkannt ist... dann ist alles möglich und alles ok, was gute Resultate in anderen Bereichen nicht gefährdet: zusammen sitzen wie homeoffice, zusammen im Café sitzen oder im Beta-Haus oder im Firmenbüro, oder früh morgen vs spät abends arbeiten.
So tun wir es doch auch hier grad bei den Kommentaren. Unser gemeinsames Ziel: eine gedeihliche Kommunikation. Jeder trägt dazu bei - nach seinen Bedürfnissen in Bezug auf Zeit und Ort. Trotzdem - oh, Wunder! :-) - entsteht ein Ganzes.
Klar, das ist weniger geplant, weniger zielgerichtet als ein Softwareprojekt. Aber der graduelle Unterschied ist für mich kein Grund, die grundsätzliche Form aufzugeben. Wir können hier ja auch entscheiden, dass wir unser Resultat noch besser erreichen, wenn wir uns mal zu einem Bier treffen, also ein Meeting veranstalten.
Warum sind so viele so scharf drauf, diese Freiheit aufzugeben, wenn es um den Job geht? Oder anderes herum: Warum glauben Manager (und Berater), nur durch die Aufgabe dieser Freiheit, ließen sich verlässlich und mit hoher Qualität Resultate in der Softwareentwicklung erzielen?
+1 Hinter diese Frage stelle ich mich ebenfalls.
@Stephan Roth: "Open Source ist übrigens m.E. dahingehend kein gutes Beispiel, weil nur vergleichsweise wenige dieser Projekte wirklich einen großen, durchschlagenden Erfolg haben"
Ich sehe hier eher - fehlendes bzw. unzureichendes Kapital für Entwicklung und Marketing. Das erhöht das Risiko und verringert die Gewinnchance.
"Und dort, wo es gut funktioniert, gibt es äußerst restriktive Regeln - viel strenger, als ich es in vielen Organisationen gesehen habe."
Niemand hat etwas gegen Regeln. Sie sind mit großen Freiheiten nötig.
Wer die "großen" Linux, Apache, MongoDB, NodeJS, MySQL, AngularJS, Spring, NServiceBus, etc. verfolgt hat kennt die höhen und tiefen eines Open-Source Projektes. Doch alle haben etwas gemeinsam. Sie sind mit hohem Engagement jedes einzelnen und verteilt entstanden. Und dabei würde ich auch nicht mehr von Einzelfällen sprechen.
@Mike: Da sehe ich auch einen zentralen Erfolgsfaktor: Führung.
Führung zeigt eine Richtung. In diese Richtung können und wollen Menschen dann mit Engagement laufen. Und für diesen Lauf brauchen sie Autonomie, um sie den jeweils passenden Weg in die gewiesene Richtung zu bahnen.
Führung ist aber nicht Regelwerk, sondern Vorangehen und Zeigen. Und manchmal Hinterhergehen, um verlorene Schafe aufzusammeln - während vorne weitergegangen wird auf den Nordstern hin.
Deshalb funktioniert Open Source am besten (oder ausschließlich) bei Themen, vor die Richtung für die Beitragenden sonnenklar ist. Sie tun es nämlich letztlich für sich selbst.
Damit spart Open Source an expliziter Führung durch Personen. Aber das heißt ja nicht, dass die verteilte Arbeit von Open Source nicht übertragbar wäre auf andere Themen, wo explizitere Führung nötig ist. Man muss dann nur schauen, wie man diese Führung einrichtet. Da erweist sich die wahre Führungspersönlichkeit.
Häufig wird aber genau deren Mangel versucht zu kompensieren, dann man Menschen einpfercht. Quasi Viertransport in Richtung Ziel. Da darf man sich nicht wundern, wenn das Ergebnis nicht so gut schmeckt und nicht nachhaltig ist.
Bei Quarks und Co. gab es vor kurzem eine sehr interessante Sendung über Teams. Das war sehr aufschlussreich.
Es wurde dort die Entwicklung von Teams bei Volvo mit Toyota verglichen. Leider hat das Modell Selbstbestimmung bei Volvo dort gegen Fremdbestimmung bei Toyota verloren. Aber ein Auto zu bauen kann man auch nicht mit Software-Entwicklung vergleichen.
Kommentar veröffentlichen