Co-location als kontraproduktiv erachtet

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.

Die Sonne lacht in Hamburg, ein frischer Wind weht an der Alster. Ein guter Tag, um sich unbeliebt zu machen :-) Deshalb diese Vorschläge. Irgendwann muss ich damit mal raus. Warum nicht heute?

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:

1. 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.
2. 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]
3. 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.

---

1. 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. ↩

2. 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. ↩

3. 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”). ↩

4. 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… ;-) ↩

Bessere Resultate ohne Abhängigkeit

Wie arbeiten Sie am liebsten, wenn Sie etwas schaffen wollen oder müssen? Was fördert Ihre Konzentration?

Die Menschen sind ja verschieden. Der eine möchte Ruhe haben, die andere Musik hören, der nächste ein Räucherstäbchen anzünden… Fenster auf, Fenster zu, mehr Licht, weniger Licht… Man kann es kaum allen recht machen, oder?

Eine Konstante gibt es jedoch hinter all dieser Verschiedenheit: den Wunsch nach Autonomie.

Sie wie ich möchten die Umstände unserer Arbeit möglichst weitgehend selbst bestimmen. Umso mehr, je stärker wir unter Druck stehen. Wer von uns Resultate sehen will, der sollte uns möglichst freie Hand lassen, wie wir uns einrichten, um sie zu erzielen. Zumindest wenn man uns vertraut, dass wir uns redlich bemühen, diese Resultate auch zu erbringen.

Ich als Freiberufler lebe und arbeite so. Meine “Resultatserzielungsumstände” kann ich zu 100% selbst bestimmen. Das macht mir Freude - und meinen Kunden auch. Verlässlichkeit und Qualität scheinen für sie zu stimmen.

Anders ist das bei den Entwicklern, Testern, Supportern, POs, die ich bei meinen Kunden treffe. Deren Autonomie ist minimal. Sie können (in den allermeisten Fälle) nicht über Arbeitsort, Arbeitszeit, Arbeitsplatz, Arbeitsmittel bestimmen. Ja, sie können sogar nur begrenzt über die Arbeitszeitnutzung bestimmen.

Das finde ich von Tag zu Tag kontraproduktiver. Je häufiger ich solche Umstände sehe und auf der anderen Seite Klagen darüber höre, was alles in Unternehmen nicht läuft, wie es laufen soll… desto mehr denke ich: Da gibt es einen Zusammenhang. Die Grundverhältnisse sind einfach so, dass es nicht besser klappen kann. Unternehmen wünschen sich also etwas, das sie nicht bekommen können, solange sie an ihren Glaubenssätzen festhalten, was die Einschränkung der Autonomie ihrer Mitarbeiter angeht.

Was wollen Unternehmen auch erwarten von Menschen, die offiziell “abhängig beschäftigt” sind? Diese Formulierung müssen Sie sich auf der Zunge zergehen lassen:

• Wer angestellt ist, ist abhängig. Das Unternehmen bestimmt, der Angestellte wird bestimmt. Er ist auf die Gnade des Unternehmens angewiesen - sonst wäre er ja nicht in einem Abhängigkeitsverhältnis. Gleichberechtigung, Augenhöhe, Autonomie sind etwas anderes. Erwachsene sollten solche Beziehungen nicht eingehen wollen - sollte man meinen. Allemal ist zu fragen: Was kann ein Unternehmen erwarten von Abhängigen? Freiwilligkeit und Motivation? Kaum.
• Wer angestellt ist, ist beschäftigt, nein, muss beschäftigt werden. Das hört sich an wie im Kindergarten, wo man Kinder beschäftigt, damit sie nicht auf dumme Gedanken kommen. “Beschäftigung” klingt auch nicht nach Motivation, Energie, Fokus. Wer beschäftigt wird, der tut auch eher nichts aus sich heraus, sondern braucht einen “Entertainer”. Sobald der nachlässt, kommt Langeweile auf.

“Abhängige Beschäftigung” soll etwas optimieren. Historisch gesehen ist sie eine große Leistung. Lieber abhängig beschäftigt im Schutz eines Unternehmens unter Aufsicht von Arbeits- und Sozialgesetzen, als frei, selbstständig, autonom - aber immer auch prekär am Rande des Existenzminimums.

Die positiven Effekte der “abhängigen Beschäftigung” möchte ich nicht schmälern. Doch sie hat eben ihren Preis. Und den zahlen nicht nur Unternehmen, sondern auch die Abhängigen. Der Preis der Abhängigkeit ist die Unterkomplexität.

Abhängigkeits- und Beschäftigungsverhältnisse sind immer hierarchisch. In Hierarchien fließen Segnungen von oben nach unten. Von unten nach oben wird geleistet und erbeten. Das ist klar, simpel, effizient. Das ist das Gegenteil von komplex. So soll es ja auch sein.

Historisch hat das auch lange gereicht, nein, konnte sogar nicht anders sein. Was immer an Resultaten zu erzielen war, war sehr einfach zu erzielen: Wenige denken und planen, viele, viele führen mit einfachen Handgriffen aus. Der kulturelle und bildungsmäßige Unterschied zwischen den Hierarchieebenen war bis neulich noch gigantisch.

In den letzten Jahrzehnten hat sich das nun radikal geändert. Ein Manager ist einem gemanageten Entwickler in nichts voraus. Sie sind in allem gleich - außer in ihrer Position in der Unternehmenshierarchie und damit im Gehalt und damit in den angehäuften materiellen Werten und damit in ihrem Anspruchsdenken. Allerdings leitet sich daraus kein Unterschied in der Angst ab. Angst ist auf jeder Ebene der Hierarchie gegenwärtig. Denn auf jeder Ebene ist man ja abhängig und will beschäftigt werden.

Diese Angst kostet natürlich Energie. Die wird investiert in Handlungen, die höhere Hierarchieebenen gnädig stimmen sollen. Ob daraus jedoch dem Unternehmenszweck dienliche Resultate erwachsen, ist zweitrangig. So kann es dann zu keinen besseren Resultaten kommen. Dass Unternehmen klagen, ist also nicht verwunderlich. Ihr grundsätzlicher Glaubenssatz ist falsch. Der lautet: Weil Angestellte so glücklich über die abhängige Geborgenheit sind, die das Unternehmen ihnen gibt, beschäftigen sie sich konzentriert mit der Erzielung von Resultaten zum Wohle eben dieses gnädigen Unternehmens.

Doch so funktioniert es eben nicht.

Ich glaube zwar daran, dass die meisten Angestellten gute Resultate zuverlässig liefern wollen - nur können sie es nicht. Sie sind umstellt von organisatorischen Mauern. Ihre Freiheitsgrade sind mindestens aus zwei Gründen beschnitten:

• Das Unternehmen traut den Abhängigen nicht. Denn die haben ja eine Beschäftigungsmentalität. Falls man sie nicht konstant bespaßt und beaufsichtigt, langweilen sie sich und tun nichts. Nur wenn ein Regelkorsett eng geschnürt ist, bleibt den Abhängigen quasi nichts anderes übrig, als auch in der Langeweile irgendwie noch ein Resultat zu erzielen.
• Unternehmen sind Zusammenschlüsse von Individuen, um durch ein engeres Verhältnis Energie zu sparen. Neben dem funktionalen Zweck (z.B. Software für Architekten) gibt es also auch einen nicht-funktionalen: Effizienzsteigerung. Der ist tief verankert und wird umso mehr beschworen, je enger der Markt wird. Im Verein mit der überkommenen Grundannahme, dass Abhängige, die beschäftigt werden müssen, weder rechte Motivation noch Kenntnis haben können, wie Ressourcen am besten eingesetzt werden, führt das zu weiteren Einschnürungen durch ein Regelkorsett. Vereinheitlichung, Standardisierung, Konsolidierung sind das Gegenteil von Autonomie.

Wenn ich “die Verhältnisse” so beschreibe, ist das natürlich überzeichnet. Doch nur durch die Überzeichnung wird die Grundhaltung erkennbar, die eben den meisten Unternehmen noch unterliegt. Es ist die der Hierarchie und der Unselbstständigkeit. Da helfen auch nicht 3 Monitore, der höhenverstellbare Schreibtisch oder die unternehmenseigene Kita. All das ist mit Hierarchie und Unselbstständigkeit vereinbar. Denn all das können einfach nur Geschenke und Zugeständnisse eben im Rahmen des überkommenden Paradigmas sein. Ein gelockertes Korsett ist immer noch ein Korsett - insbesondere, wenn man nicht wählen kann, ob man es auszieht.

Das Büro kann eingerichtet sein, wie es will. Mit Tischkicker und Ruheraum. Solange die, die Resultate erzielen sollen und wollen, nicht wahrhaft die Wahl haben, ihre Umstände bestmöglich selbst zu bestimmen, um eben diese Resultate zu erzielen… solange müssen sich Unternehmen nicht wundern, dass es nicht wie gewünscht klappt.

Je länger ich darüber nachdenke, desto mehr glaube ich, dass der Default für die Zusammenarbeit Unabhängigkeit sein sollte. Nur wenn Verlässlichkeit und/oder Resultat zu wünschen übrig lassen, sollte nachgebessert/optimiert werden. So wenig wie möglich.

Unternehmen als Ganzes und Manager in Unternehmen in ihren Bereichen sollten also nicht Regeln einführen, sondern stets Ausschau halten nach Regeln, die entfernt werden können. Denn je weniger Regeln, desto größer die Autonomie der Mitarbeiter. Und je größer die Autonomie, desto eher kann die Konzentration entstehen, die dafür nötig ist, dass Resultate verlässlich in hoher Qualität entstehen.

Wer Resultate sehen will, wer etwas bekommen will, sollte daher mit Geben beginnen. Das geschieht am besten mit einer simplen Frage: “Was brauchst du, um deine Resultate zu erzielen?”

Manchmal wünscht sich die Gefragte dann eine Regel; das ist nicht schlecht, denn dann kommt die Regel von unten, von dort, wo echter Bedarf ist.

Es können jedoch auch Antworten kommen, die dem Paradigma widersprechen. Aber warum davor Angst haben? Kann denn wirklich etwas Katastrophales passieren, wenn man die Leine der Abhängigkeit und der Beschäftigung lockert? Alle Wünsche sind doch nur Hypothesen. Auch der wünschende Angestellte weiß nicht wirklich, ob es stimmt, dass es seinen Resultaten hilft, wenn er nur seinen Wunsch erfüllt bekommt. Deshalb sollte die Wunscherfüllung zunächst als Experiment gesehen werden.

Auch hier gilt “Individuals and interactions over processes and tools” und “Responding to change over following a plan” und “Working software over comprehensive [rule set]” und “[…] collaboration over contract [adherence]”. Die Iterationen der Agilität helfen überall. Eine lernende Organisation gibt es nicht ohne Experimente. Die sollten nicht nur am Markt stattfinden, sondern eben auch intern. Viel mehr intern. Denn dort ist viel Potenzial für Kreativität, Motivation, gar Innovation hinter Mauern aus Regeln angestaut.

Wenn es also im Unternehmen im Allgemeinen bzw. in der Softwareentwicklung im Speziellen nicht läuft, wie es laufen sollte, wenn es knirscht in der Zusammenarbeit, wenn die Unzuverlässigkeit grassiert… dann, so glaube ich, ist eine wesentliche Stellschraube die Autonomie jedes einzelnen Beteiligten. Mehr und mehr Freiheitsgrade helfen. Nicht nur für sauberen Code gilt also: Raus aus den Abhängigkeiten! ;-)

 

PS: Dass Autonomie kein Garant für Erfolg ist, ist selbstverständlich. Sie ist keine hinreichende Voraussetzung. Aber ich halte sie für eine notwendige. Ohne Autonomie, ohne Augenhöhe, ohne Selbstbestimmung und damit einhergehend auch Selbstverantwortung keine wirklich dauerhaft guten Resultate. Autonomie ist insofern im eigenen Interesse jedes Unternehmens.

PPS: Zur gewährten Freiheit muss auf der anderen Seite natürlich auch Fähigkeit treten, damit umzugehen. Die mag nicht bei jedem “Befreiten” in gleichem Maße vorhanden sein. Aber wer seine Aufgaben als Manager schwinden sieht, bekommt hier ein bedenkenswertes neues Betätigungsfeld: die Förderung von echten Mit-Arbeitern. Die Frage bleibt nämlich: “Was brauchst du?” Dieses mal jedoch Bezogen auf die Autonomie: “Was brauchst du, um mit der neu gewonnenen Autonomie zum Nutzen der Resultate am besten umzugehen?”

PPS: Und wer nicht glaubt, dass man mit mehr Autonomie und Augenhöhe Erfolg haben kann, der schaue mal diesen Film: http://vimeo.com/118219210

AUGENHÖHE OmU (dt.) from Daniel Trebien on Vimeo.

Die meisten, die darin zu Wort kommen, sind zwar formal noch “abhängig beschäftigt”, doch ihre Berichte machen deutlich, dass auch in Angestelltenverhältnissen Autonomie und echte Mit-Arbeit möglich ist. Und das ist nur der Anfang.

Die Frage ist daher nicht, ob mehr Autonomie in Ihrem Unternehmen sein sollte, sondern wann das der Fall ist und unter wie großen Schmerzen es dazu kommen wird. Meine Empfehlung: Lieber bald mit der “Entkopplung” beginnen, um mehr Zeit zum Lernen und Anpassen zu haben.