Das Humpty Dumpty Syndrom

"Humpty Dumpty saß auf dem Eck, Humpty Dumpty fiel in den Dreck und auch der König mit seinem Heer, rettete Humpty Dumpty nicht mehr."

Quelle: https://de.wikipedia.org/wiki/Humpty_Dumpty

Der moderne Humpty Dumpty

924px-Denslow's_Humpty_Dumpty_1904.jpg

Kennt ihr das? Ihr merkt früh, dass in eurer Entwicklung etwas in Schieflage gerät und eigentlich muss man jetzt etwas verändern. Ihr sprecht es an und bekommt die Rückmeldung: "Keine Panik, das wird nicht passieren und wenn es passiert, dann hau' ich euch mit Manpower raus!" Eventuell setzt man noch eins drauf: "Bitte behalte deine Gedanken bzgl. dieses Problems für dich, sonst machen sich die Leute nur sorgen."

So in der Art geht es dem guten Humpty Dumpty von Alice im Wunderland auch. Er weiß zwar, dass er auf einer dünnen Mauer sitzt und für ihn als Ei das mehr als gefährlich ist, aber er verdrängt es. Zudem ist er der Meinung: Mein König haut mich da schon wieder raus.

Jetzt sitzt ihr also sprichwörtlich auf einem schmalen Grat mit der Hoffnung, dass euch euer König raushaut, wie Humpty Dumpty. Auch wenn das manchmal gut gehen kann, wird doch viel zu oft der Grat auf dem ihr sitzt schmaler und schmaler.

Der Sturz

Wer spät in der Entwicklung reagiert, der verursacht meist mehr Schaden als Nutzen (vgl. B. Brooks Law). Das Problem mit dem man oft konfrontiert ist, ist laut Gerald M. Weinberg und Brooks:

"Managers are often foolishly optimistic about things going well. Moreover, when thing do go poorly, manager imagine that they will get better by themeselves."

Das Problem wird nicht erkannt und selbst wenn es erkannt wird, dann fehlt das Wissen damit umzugehen. Sie verfallen in das Humpty Dumpty Syndrome. Abwarten, verzögern und auf Wunschdenken spielen.

Wenn dann letztlich anerkannt wird, dass ein Problem existiert, dann wird massiv gerudert. Was das System durch nicht-lineare Effekte aus den Fugen brechen lässt. Weinberg dazu:

"Instead of merely making the project late, a sufficiently foolish manager can make the project collapse."

Das Problem wird mitunter dadurch verstärkt, dass die erzeugten Änderungen sowohl die Arbeitslast erhöhen als auch die Effektivität der Arbeitenden verringern. Zudem führt ein zu langes Abwarten dazu, dass Änderungen kaum mehr Effekt haben, außer man macht sie groß, was dazu führt, dass jede Menge nicht-lineare Seiteneffekte auftreten.

Früh mit kleinen Schritten

Arbeitet man früh mit dem Feedback aus dem System, indem man die Signale der Menschen wahrnimmt, so lässt sich schnell und leicht entgegen arbeiten und man hat sogar noch Zeit zum Experimentieren. Mit frühen Änderungen lassen sich insbesondere positive Feedback-Zyklen durchbrechen, sodass diese keinen größeren Schaden anrichten können.

Ein Beispiel

Zwei Abteilungen arbeiten zusammen: Frontend und Backend. Das Frontend-Team muss das Backend stetig integrieren und ist stark vom Wissen über deren Schnittstelle abhängig. Die Integration läuft schleppend bis gar nicht, ein echter Test kann nicht stattfinden. Ein kleiner Schritt wäre jetzt das Komponenten-Team Frontend zu einem echten Feature-Team zu machen, indem man eine Person aus dem Backend-Team hinzufügt. Integration, Done und die Lieferfähigkeit wären gestärkt durch eine kleine Änderung des Team-Setups hin zu Cross-Funktionalität.

Unterlässt man das und verschleppt sich die Integration weiter und damit die fertiggestellten Features (partially done == waste), so steigt die Tendenz eine große Änderung vor Schluss zu tätigen. Beispielsweise erkennt man die Not der Integration und setzt weitere Teams (z. B. Integration, Test) auf. Oft explodieren an der Stelle dann nicht nur die Kosten, sondern das gesamte System. 

SVNWNK

Literatur

Wie viel Zwang verdient ein Team?

Auf einem Open Space war ich in der Session: "Wie viel Zwang ist gegenüber einem Team in Ordnung?". Für mich war die Session bizarr, bedrückend, belustigend, beängstigend - und unglaublich widersprüchlich.

Das Szenario war ein "gut funktionierendes Testteam", laut dem Erzähler: ein Team von Freunden. Auf dem Weg zu Agile, so meinte er, war es notwendig die Auflösung zu erzwingen und eine Umverteilung zu anderen Teams anzuordnen. Feature Teams war der geplante Schlüssel zum Erfolg und nach einiger Zeit stellte sich auch eine positive Wirkung ein, trotz anfänglichem Widerstand, Ärger und Unstimmigkeiten. Lokale Optimierung wäre ein furchtbares Übel, und die Notwendigkeit für globale Optimierung sei sein großes Anliegen.

Auf meine Frage hin "habt ihr das Team vorher gefragt, sie mit den Informationen konfrontiert, die euch zum Handeln veranlasst haben?", antwortete er: "Nein, sie hätten sich sicher nur gesträubt, da sie ein eingespieltes Team wären und das große Ganze nicht sehen würden."

Ein Widerspruch?

Kommen wir zu den Punkten, die mir nicht besserwisserisch und doch schwer im Magen liegen. Agile ist bedeutungsschwer mit dem Stichwort Selbstorganisation  verknüpft. Vereinfacht bedeutet Selbstorganisation ein Ausgleich an Mitteln und Verantwortung sowie dezentrale Entscheidungen an der erstmöglichen Stelle, die die Frage beantworten kann. Oder klassisch ausgedrückt: eine Verschiebung von Entscheidungen aus dem Management in die unteren Hierarchieebenen. Damit das funktioniert ist der Ausgleich von Information zur Verantwortung notwendig.

"Camp Delta in Guantanamo" by Christian Seebauer (Own work) CC-BY-SA-3.0, via Wikimedia Commons

Wie passt das nun zum obigen Beispiel? Ganz einfach: Hier schickt man mit Agile Leute in die Selbstorganisation und traut ihnen gleichzeitig nicht zu richtige oder wichtige Entscheidungen für das Unternehmen zu treffen. Die Entscheidung wie man sich ggf. besser organisieren könnte. Man traut ihnen nicht zu, dass, wenn sie die Informationen bekommen, sie sich für das Wohl der Organisation entscheiden und es ggf. über die eigene Schwerfälligkeit stellen. Daher fragt man sie vorher gar nicht und verschwendet das Potential eines gemeinsamen konstruktiven Wegs. Ein Solcher birgt die Möglichkeit sich schrittweise auf etwas hinzubewegen, was das Problem auch adressiert. Es gibt mehr als eine Option Zusammenarbeit zu verbessern, vielleicht fände man etwas, an das ein paar Wenige gar nicht gedacht haben und besser funktionieren würde als ein Pauschalrezept.

Stattdessen fällt es nur zu leicht zu sagen: "Ich kenne die Antwort, andere werden nur falsch entscheiden". Unterstellt wird dann oft, es geht nicht anders, denn außerhalb meines Kopfes herrscht Unwissenheit, mangelnder Intellekt, Bequemlichkeit oder gar Boshaftigkeit. Ironischerweise tragen im nächsten Schritt die Teammitglieder die Entscheidung und Konsequenzen, sollen ihr Bestes geben und ohne Murren Entscheidungen hinnehmen. Hier fordert man dann die erwachsene und professionelle Reife ein, die vorher nicht zugetraut wurde. Vielleicht redet man sich noch ein, etwas Gutes getan zu haben, denn man hat sie dann "zum Glück gezwungen" und "nicht mit einer Entscheidung belastet".

Fazit

Dass eine Veränderung in diesem Beispiel etwas Positives bewirken kann, zweifle ich nicht an. Was mir fehlt ist der Respekt gegenüber den Menschen. Wie viel von dem mangelnden Respekt Selbstüberschätzung, fehlende Courage, Kommunikationsfertigkeit oder Konfliktfähigkeit ist, kann jeder selbst entscheiden. Egal wie man es sieht, für mich persönlich ist das ein Weg ganz weit weg von Agile, denn wenn ich ernst nehme, was hinter dem Gedankengut steht, dann gehören die Entscheidungen über die Organisation der eigenen Arbeit zu den Menschen, die sie ausführen:

The best architectures, requirements, and designs
emerge from self-organizing teams.
— http://agilemanifesto.org/principles.html
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
— http://agilemanifesto.org/principles.html
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
— http://agilemanifesto.org/principles.html

Arbeitsplatzschmerzen - Nicht nur für Wissensarbeiter

Wenn der Arbeitsplatz schadet

Es ist wenig verwunderlich, dass große Firmen wie Google stolz auf die Arbeitsplätze für ihre Mitarbeiter sind und sie der Welt zeigen.  Ist doch der Arbeitsplatz entscheidend bei der Wahl für oder gegen ein Unternehmen. Denn über die Arbeitsplatzgestaltung lässt sich viel auf die Unternehmenskultur schließen. Der Arbeitsplatz drückt aus, was unausgesprochen bleibt: wir atmen etwas der Kultur ein, zumindest suggeriert unser Hirn uns das, und wir stellen Erwartungen und treffen Annahmen. Obwohl Kultur spannend ist, möchte ich hier über die Gestaltung von Arbeitsplätzen von Wissensarbeitern schreiben. Über unterschiedliche Arbeitsplätze, die ich gesehen und über das was ich dort gefühlt habe, über das was für mich wichtig ist an einem Arbeitsplatz.

First things first

Wenn Du deine Leute über ihren Arbeitsplatz entscheiden lässt, dann zahlen sie dir das tausendfach zurück. Überstimmst Du sie bei der Gestaltung des eigenen Arbeitsplatzes, dann zerkratzt Du ihre Verbindung zu dir. 

Ein Beispiel: Die Bürowände gehören den Menschen, die dort arbeiten und nicht irgendeinem Hausdienst, Management oder externen Beratern. Keine Diskussion!

Pigs und Chicken auf der Arbeit

Ein Arbeitsplatz im Hauptquatier von Zappos. By lizzielaroo CC-BY-SA-2.0  or CC-BY-SA-2.0, via Wikimedia Commons

Der Arbeitsplatz sollte der Ort sein an dem gearbeitet wird, sofern der Arbeitsplatz einem nicht daran hindert.

Ein Muster dem viele Agile Transitionen folgen ist Colocation. Sicherlich ist Colocation mächtig, jedoch ist das Wichtigste dabei die Leute selbst zu fragen, in welchen Konstellation sie gerne zusammensitzen möchten: ein Raum, zwei Räume, wie viele Leute in einem Raum, was auch immer. Als Chicken sollte man nicht über sie bestimmen, sie in einem Pferch einsperren. Vertraue den Leute, die die Arbeit verrichten und nenne ihnen die Einschränkungen und den Rahmen.

Separation, Fragmentierung und ungezwungener Austausch

Viel Schaden wird am Arbeitsplatz dadurch angerichtet, dass Teams auseinander gerissen und separat untergebracht werden. Wahrscheinlich leidet die Arbeit darunter, wenn Teammitglieder losgelöst voneinander. Was dabei definitiv verloren geht, ist der ungezwungene Austausch untereinander. Über diesen Austausch bauen sich Verbindungen und damit eingehend Vertrauen auf und es entstehen Handlungsspielräume. Man verliert viel, wenn man Teams nicht zusammen sitzen lässt.

Zudem fördern verstreute und verteilte Teams Verschwendung (Waste). Wenn man es vermeiden kann, dann sollte man solche Teams nicht in Betracht ziehen - mit einer Ausnahme: das Team möchte es selbst so. Teams, die bestimmt werden agieren üblicherweise weit unter ihren Möglichkeiten. Verteilte Teams, die bestimmt werden tun sich noch weitaus schwerer.

Boxenstop von McLaren 2006 in Malaysia. By Kamalsell (Flickr) CC-BY-2.0, via Wikimedia Commons

Teams auf verschiedene Standorte aufzuteilen ist schädlich, aber Teammitglieder in ihren Aufgaben zu fragentieren ist weitaus schlimmer. Arbeiten Leute an mehr als einem Projekt, Produkt oder was auch immer, dann führt das dazu, dass sie weniger fokussiert arbeiten und mit enorm mehr Störungen umgehen müssen. Sie ringen und stolpern die meiste Zeit, da es ihnen schwer fällt mit der Anzahl der menschlichen Interaktionen umzugehen. Das hindert sie wiederum, sich in einen Flow-Zustand zu begeben. Bevor es ihnen gelingt etwas abzuschließen, reißt sie wieder jemand heraus und stiehlt ihre Aufmerksamkeit. Man fühlt sich dann wie ein Formel 1 Auto, das für immer beim Boxenstop steht: viel Power, doch keine Performance, da ständig jemand einem die Reifen und andere Teile wechselt. Leider ist dieses Szenario weit verbreitet und erzeugt mehr Verschwendung als Wert.

Ruhe und der Flow-Zustand

Von einem Flow-Zustand spricht man, wenn Menschen beim Arbeiten in eine Leichtigkeit verfallen. Um einen Flow-Zustand zu erreichen, benötigt man Zeit. Üblicherweise erledigt man während eines Flow-Zustands außerordentlich viel. Um dorthinzukommen muss man sich konzentrieren, dafür braucht man Ruhe. Um einen Arbeitsplatz zu schaffen, der das unterstützt, fragt man am besten die Leute selbst. Sie werden sehr gute Vorschläge machen, was sie benötigen um ungestört zu arbeiten. Lässt man sie, werden sie ihren Arbeitsplatz verbessern. Besser man ist zuvorkommend und hilf ihnen dabei, den besseren Arbeitsplatz zu schaffen. Das Prinzip Colocation unterstützt auch dabei, um in einem Flow-Zustand zu kommen: Teammitglieder tendieren dazu zur gleichen Zeit ruhig zu werden und ihre Arbeit zu verrichten, das führt für gewöhnlich zu weniger Unterbrechungen und Störungen. Fragmentierung von Teams, wie oben angesprochen, führt letztlich zu wenig bis gar keiner ruhigen Zeit zum arbeiten.

Natürlich und ...

Sicherlich ist das was ich hier schrieb nichts Neues, nichtsdestotrotz wird es viel zu oft überhört. Oftmals hat es gar nicht so viel damit zu tun, dass bspw. das Management unfähig ist diese Konzepte anzunehmen, es fällt Menschen viel schwerer die alten Ideen zu vergessen, wie John Maynard Keynes sagen würde.

SVNWNK

this article in English: click