Archiv für den Monat: März 2012

Future Leadership Camp 2012

Veröffentlicht am von

Drei Tage im wunderschönen Ostseehotel Schlossgut Groß Schwansee, zwei Tage Open Space im „Future Leadership Camp„, das von der intrinsify! GmbH ausgerichtet wurde. Worum ging es? Die Grundrichtung hat Niels Pfläging bereits am ersten Abend mit seinem Impulsvortrag „Bye-bye Management – Warum Management verzichtbar ist“ vorgegeben: Wie sieht Führung aus, wenn man einmal davon ausgeht, dass Mitarbeiter gute Arbeit leisten wollen und dazu auch qualifiziert sind? Was bedeutet es für eine Organisation, wenn man sich von dem tayloristischen Gedanken verabschiedet, dass im Management gedacht und vom Personal gemacht wird, sondern wenn man auch die Mitarbeiter als denkende, erwachsene Menschen ernst nimmt? Nicht so überraschend lief das in Niels‘ Vortrag berechtigter Weise auf den Beta Codex hinaus, der sich weitgehend mit den Vorstellungen deckt, die wir von agilem Management selbstorganisierter Teams haben.

Um sich mit diesem „neuen“ Führungsbild zu beschäftigen, hatten sich etwa 30 Führungskräfte aus allen Arten von Unternehmen zusammengefunden. Das reichte von doch eher traditionell geprägten Großunternehmen wie der Deutschen Bahn bis hin zu Unternehmen, die Selbstorganisation in die eigene DNA eingebaut haben, wie V&S oder it-agile. Ein großer Teil der Diskussionen drehte sich um die Frage „Wie kann ich das trotz meines Chefs für meinen Verantwortungsbereich umsetzen?“ – eine Diskussion, die mir aus unseren Beratungseinsätzen recht bekannt vorkam. Die Vorschläge werden Agilisten denn auch vertraut erscheinen:

  • Stelle klar, was eigentlich Dein Auftrag ist und wer was will
  • Versuche nicht, Änderungen durchzusetzen, sondern bau Strukturen auf, die änderungswillige Kollegen unterstützen
  • Nimm die Bedenken auf und gestalte gemeinsam mit den Skeptikern begrenzte Experimente, um die Hypothesen zu verifizieren oder falsifizieren und festzustellen, welche Regeln wirklich notwendig sind
  • Offene Kommunikation ist der Schlüssel zu Veränderung
  • Das Team muss nicht nur auf den Kunden achten, sondern auch auf sich selbst

Einen großen Raum nahm das Thema Gehaltsfindung ein. Nur zwei Unternehmen hatten sich von der traditionellen Gehaltsfindung entfernt und überließen das Gehalt nicht mehr dem Vorgesetzten: Benno Löffler von V&S berichtete, dass die Gehaltsfindung bei ihnen den einzelnen Mitarbeitern überlassen wird, alle Kollegen hätten aber ein Vetorecht. Entgegen den üblichen Befürchtungen machten sie aber die gleiche Beobachtung, über die Ricardo Semmler bereits in „Maverick!“ berichtet hatte: Die Mitarbeiter stuften sich selbst tendenziell eher zu niedrig ein, die Personalkosten sanken letztlich durch die Maßnahme.

Ob das it-agile System der selbstgewählten Peergroup (siehe „Selbstorganisation bei it-agile„) wirklich darauf hinausläuft, dass die Mitarbeiter das Gehalt festlegen, kann man sicherlich diskutieren. Aber auf jeden Fall waren wir neben V&S die einzige weitere Firma vor Ort, die sich davon verabschiedet hatte, Hierarchien über Bezahlung entscheiden zu lassen. Alle waren sich allerdings einig, dass eine grundlegende Voraussetzung für einen solchen Schritt die Offenlegung der bestehenden Gehaltsstruktur ist. Nur die Transparenz ermöglicht informierte und verantwortungsvolle Entscheidungen der Mitarbeiter – ein Beleg für die zu Beginn von Niels Pfläging zitierten These von Douglas McGregor, dass die Bedingungen stimmen müssen, damit Menschen sich verantwortungsvoll verhalten – und dass sie es tun, wenn die Bedingungen stimmen. Dass ein Teilnehmer berichtet hat, das Offenlegen des eigenen Gehalts sei in seinem (großen) Unternehmen ein Grund für eine fristlose Kündigung zeigt aber auch, welcher Aufwand zum Teil betrieben wird, um diese Transparenz zu verhindern und so die Rolle des traditionellen Managements aufrecht zu erhalten.

Für mich überraschend war, dass bei V&S die freie Gehaltswahl funktionierte, obwohl die Mitarbeiter dort (noch?) nicht nennenswert am Unternehmen beteiligt sind. Das schwächt leider meine Position in der Diskussion mit meinem Kollegen Stefan Roock, ob das it-agile Beteiligungsmodell eine notwendige Voraussetzung für so weitreichende Selbstorganisation ist – wie ich meine – oder nur eine hilfreiche – wie Stefan meint.

Ein weiteres Thema, das sich durch viele Gruppen zog, war Kommunikation: Wie stellt man offene Kommunikation zwischen allen Beteiligten sicher, was allgemein als Voraussetzung für neue Führungsansätze gesehen wurde. Dabei ging es sowohl um die Kommunikation von Missständen und Veränderungen, als auch um direkte Kommunikation, wie Feedback- und Beurteilungsgespräche. Gegenseitiger Respekt, Vertrauen und Augenhöhe waren wichtige Attribute, aber eben auch der regelmäßige Austausch abseits von Meetings und operativen Erfordernissen. Auch hier dürften wir bei it-agile mit unseren monatlichen Open Spaces, dem internen Microblogging und einer sehr offenen Kommunikationskultur ganz gut dabei sein.

Sehr faszinierend fand ich persönlich auch den Bericht von Robindro Ullah, der in einem internen Vorhaben der Deutschen Bahn 400 „interne Arbeitslose“ nicht nur wieder in den Berufsalltag integriert hat, sondern ihnen auch den Freiraum geschaffen hat, nach zwei bis fünf Jahren ohne Beschäftigung wieder einer erfüllenden und großteils selbstorganisierten Tätigkeit nachzugehen. Dabei handelte es sich nicht im aufstrebende Akademiker, sondern um Facharbeiter, die als „nicht umschulbar“ bereits seit mehreren Jahren durch die internen Raster gefallen waren. Diese Personen nach vielen Jahren der Frustration wieder in selbstorganisierte Teams einzubinden war eine Herausforderung der besonderen Art. Die Begeisterung, mit der Robindro von „seinen Leuten“ sprach und die Erfolge, die er vorweisen konnte, waren ein guter Beleg, dass Selbstorganisation auch in Großkonzernen möglich ist und auch für jene Personenkreise, die der Arbeitsmarkt fast schon ausgespuckt hätte. Zentraler Schlüssel ist dabei das Menschenbild des Vorgesetzten, nicht die Fähigkeiten der Mitarbeiter.

Um nicht nur zu konsumieren, warf ich eine Session über Human Systems Dynamics und das CDE-Modell ein, die anschließend für einigen Gesprächsstoff sorgte. Ich bin immer wieder erstaunt, welche Anwendungs- und Interpretationsmöglichkeiten das Modell bietet, wenn man es einer ausreichend breit aufgestellten Gruppe vorstellt.

Alles in Allem ein interessanter Workshop, gut organisiert und ich habe viele interessante Menschen kennengelernt. Meine Strategie, auf einen Open Space zu gehen, wenn sich die Zusammensetzung der Teilnehmer interessant anhört, hat sich einmal wieder bewährt. Ich persönlich hätte mir noch etwas mehr Selbstorganisation im Open Space gewünscht, aber ich gehöre ja auch zu denen, die mittlerweile die Open Space Einführung als Rap vorziehen, bin also nicht wirklich repräsentativ.

Ein wenig frappiert hat mich, dass offensichtlich recht wenige Firmen bisher konsequent auf neue Führungskonzepte setzten. Meine Hoffnung, einige Mitstreiter zu finden, die uns um so viel voraus sind, dass wir bedenkenlos von ihnen klauen, äh lernen können, hat sich nicht erfüllt. Vielleicht sieht das nächstes Jahr ja schon anders aus. Ich habe mir auf jeden Fall schon mal den 18.-20. März 2013 reserviert und das Schlossgut Groß Schwansee wird mich wohl auch nicht das letzte Mal gesehen haben.

Human Systems Dynamics: Ein Modell zur Selbstorganisation

Veröffentlicht am von

„Welche Theorien nutzen Sie eigentlich, um Ihre Firma zu organisieren?“ werde ich gelegentlich von jenen gefragt, die verstanden haben, dass wir immer weniger nach klassischen Unternehmensstrukturen arbeiten und dennoch kein wildes Chaos zelebrieren. Ich persönlich beschäftige mich seit vielen Jahren mit systemischen Ansätzen, spätestens seit ich vor 12 oder 13 Jahren Peter Senges „Fifth Discipline“ und Jerry Weinbergs „Quality Software Management Series“ gelesen habe. Aber das wirklich operationalisierbar zu machen, ist mir erst gelungen, nachdem ich letztes Jahr von Diana Larsen Human Systems Dynamics (HSD) kennengelernt hatte und mich anschließend intensiver damit beschäftigt habe. Der Ansatz findet auch innerhalb von it-agile mehr und mehr Anwender, so dass ich wohl nicht zu sehr daneben greife, wenn ich ihn zumindest als eine von mehreren Theorien sehe, auf denen wir aufbauen.

Worum geht es? Etwas flapsig formuliert ist HSD ein Mashup verschiedener Modelle aus dem Umkreis der System- und Komplexitätstheorie, angepasst für den Einsatz in Organisationen. Der Grundkurs dauert 14 Tage, Sie werden also vermutlich gar nicht wollen, dass ich das hier ausführlich darstelle… Grundlage ist die Sicht einer Organisation als komplexes, adaptives System von Individuen. Diese Sicht funktioniert für jede Organisation, von der straff durchorganisierten Behörde bis zum chaotischen Grundlagenforschungs-Team. Jede Organisaton lässt sich mit Hilfe des sogenannten CDE-Modells modellieren, das hilft, die Organisation oder Teilaspekte von ihr als komplexes System zu verstehen. In diesem Modell wird das System nach drei verschiedenen Aspekten modelliert: Container, Differences und Exchanges

  • Container sind die Grundelemente, aus denen die Organisationen aufgebaut sind. Das können individuelle Mitarbeiter sein, Abteilungen oder Arbeitsgruppen, also alles, was in einem Organigramm sichtbar ist. Aber es gibt auch ganz andere Formen von Containern, zum Beispiel Meetings und Boards für Kommunikation, Büros, Standorte, Regelwerke und so weiter. Im wesentlichen kann alles ein Container sein, was nach außen halbwegs klar abgrenzbar ist und in sich ein Eigenleben führt – und sei es auch noch so traurig. Wobei Regelwerke genau genommen Container definieren. Die Container entsprechen also den Aktoren in der klassischen Systemtheorie. Anders als Aktoren in der klassischen Systemtheorie können Container in HSD allerdings geschachtelt sein, also jeder Container besteht für sich wieder aus einem kompletten System
  • Differences sind Unterschiede zwischen verschiedenen Containern, aber auch innerhalb eines Containers. Wenn ich eine Entwicklungsabteilung und eine Testabteilung als zwei verschiedene Container habe, ist deren unterschiedliche Aufgabe ein „Difference“, aber auch die unterschiedliche Ausbildung, unterschiedliche Berufserfahrungen, unterschiedliche Aufgabenstellung, unterschiedliche Vorlieben beim Essen, in der Kleidung, in der Partnerwahl usw. sind Differenzen. Einige dieser Unterschiede sind relevant für das System, wie z.B. Ausbildung oder Aufgabenstellung, andere sind nicht relevant, wie z.B. die Unterschiede in der Partnerwahl oder die Vorlieben beim Essen. Welches die „Unterschiede sind, die einen Unterschied machen“ hängt dabei vom Kontext ab. So können die Vorlieben bei der eigenen Partnerwahl, die in unserer Branche keine Rolle spielen (sollten) durchaus eine Rolle spielen, wenn man in einer Konfliktberatung für Homosexuelle arbeitet, oberster Schwulen-Hasser der Tea-Party-Bewegung oder weißrussischer Diktator ist. Welche Unterschiede wirklich relevant sind, ist nicht immer offensichtlich und kann durchaus auch zu Überraschungen führen. Unterschiede sind nichts schlechtes, sondern sie stellen nach HSD die potenzielle Energie dar, die das System antreibt. Ein klassischer Antrieb sind zum Beispiel die Unterschiede in der Hierarchie einer Organisation, die über Arbeitsanweisungen und ähnliche Mittel Energie in das operative Geschäft einspeisen, über Statusunterschiede und Karrierewünsche aber auch die Energie für persönliche Veränderungen erzeugen. Wichtig für eine zielgerichtete Organisation ist, dass die potenzielle Energie dieser Unterschiede im wesentlichen auf das Ziel hinführen und nicht in internen Streitereien oder Grabenkämpfen aufgebraucht wird. Unterschiede sind also neutrale Fakten, weder gut, noch schlecht – die potenzielle (chemische) Energie eines Stücks Dynamit kann ja auch ebenso zum Freisprengen eines Tunnels genutzt werden, wie für die Expansionsgelüste weißrussischer Diktatoren.
  • Exchanges sind schließlich die Interaktionen zwischen oder innerhalb von Containern. Exchanges können breit, ungerichtet und informell sein, wie das Gespräch in der Kaffeeküche oder – ein wenig formalisierter – ein Open Space. Sie können aber auch sehr schmal und zielgerichtet sein, wie das Einreichen eines Formulars. Sie können synchron und breitbandig sein, wie ein persönliches Gespräch oder ein Meeting, oder asynchron und schmalbandig, wie ein E-Mail-Kanal, ein Microbloggingsystem oder ein Bugticket. Auch hier gilt wieder: Es gibt kein richtig und kein falsch, kein besser und schlechter, sondern nur unterschiedliche Effekte, je nach Gestaltung des Exchanges. Es gibt auch Container, die ihrerseits Exchanges sind. So kann man ein Kanbanboard als Container auffassen, der dem Team einen asynchronen Exchange mit hoher Breite und geringer Tiefe bietet. Hängt das Kanbanboard an der Wand, benötigt das Team weniger Energie für den Exchange und nutzt ihn damit häufiger, liegt es elektronisch vor, benötigt es mehr Energie und der Exchange büßt damit Bandbreite und und Austauschfrequenz ein. Ob das ein Unterschied ist, der einen Unterschied ausmacht, muss man ausprobieren. Das Daily Standup ist ebenfalls ein Container für einen weniger formalisierten Exchange, das Formular für Reisespesen ist ein Beispiel für einen hochformalisierten Exchange.

HSD beitet nun eine Reihe von Werkzeugen und Ansätzen, um durch geeignete Gestaltung von Containern, Differences und Exchanges zu erreichen, dass sich in dem System hilfreiche Verhaltensmuster ausbilden. Die Organisation wird also nicht durch Organigramme, Rollen und Artefakte gesteuert, sondern auf der Meta-Ebene, indem Container mit sinnvollem Schnitt von Differenzen und adäquaten Exchanges etabliert werden. Dadurch entwickelt das System ein bestimmte Verhaltensmuster, es tritt also Emergenz auf. Ich komme gleich noch mal auf die Gestaltung eines solchen Systems.

Ein System kann nun in verschiedenen Modi operieren: Vom effizienten, kontrollierten aber unflexiblem über selbst-organisiert-adaptives Verhalten bis hin zum chaotisch-innovativem Verhalten. Dieses Kontinuum ist auch vom Stacey-Diagramm bekannt. Welches Verhalten zielführend ist, hängt von der Aufgabenstellung ab. So möchte man das Finanzamt gerne im kontrolliert-vorhersehbares Bereich verortet wissen, während die Experimentalphysiker besser im innovativ-choatischen Bereich nach Higgs-Bosonen suchen. Produktentwicklung wiederum findet sinnvollerweise im selbstorganisiert-adaptiven Bereich statt, weil dort sowohl Zielerreichung als auch innovative Ideen eine Rolle spielen (genau genommen muss auch Grundlagenforschung einen großen Teil der Zeit in diesem Bereich spielen, wenn es darum geht, Ideen wissenschaftlich sauber aufzuarbeiten). Als Faustregel gilt: Je größer die Container und Differenzen sind und je breiter und ungerichteter die Exchanges sind, umso mehr arbeitet die Organisation Richtung innovativ-chaotisch, je kleiner die Container und Unterschiede und je enger die Exchanges sind, umso mehr arbeitet das System im kontrollierten Bereich. Daher basieren Exchanges in Behörden stark auf Formularen und Dienstwegen und führen damit zu kontrolliertem Verhalten. Grundlegende Forschungserkenntnisse, die durch das Ausfüllen von Formularen gewonnen wurden, sind mir nicht bekannt (wobei Umfragen nur Exchanges sind, um Rohmaterial zu besorgen, die Forschung findet in der Auswertung statt).

Ein schönes Beispiel für die Gestaltung eines solchen Systems ist Scrum: Es definiert Container für die Struktur (Team, Product Owner, Scrum Master, Stakeholder) und Exchanges (Planning, Daily Scrum, Taskboard, Product Review und Retrospektive). Einige sind breit und relativ ungerichtet (Planning, Retrospektive), andere eher eng und formalisiert (Daily Scrum, Storycard). Der Containerschnitt trennt manche Unterschiede, wie z.B. PO und Team (Was? und Wie?), um die Exchanges zu kanalisieren. Andere Schnitte definieren, welche Unterschiede innerhalb der Container liegen sollten, um dort sehr breite Exchanges zu ermöglichen (Entwickler und Tester im cross-funktionalen Team). Es gibt Änderungen an Scrum, die diese Struktur nicht beeinträchtigen und damit verträglich sind mit Scrum, zum Beispiel die Frage, ob das Team mit oder ohne Taskplanung arbeitet. Andere Änderungen beeinträchtigen die Strukturen und führen daher in der Regel zum ScrumBut, zum Beispiel wenn der Product Owner oder ein anderer Manager die Containergrenzen missachtet und dem Team in technische Entscheidungen hineinpfuscht.

Wie kann man HSD nun zur Gestaltung von Organisationen nutzen? Letztlich geht es wie gesagt darum, die „richtigen“ Container, Differenzen und Exchanges zu etablieren. Das ist aber leichter gesagt, als getan, weil sich die Auswirkungen von Änderungen in komplexen adaptiven Systemen nicht vorhersehen lassen. Bei dem einen Team setzt ein kurzer Scrum-Lehrgang ungeahnte Energien frei und verändert das gesamte Miteinander. In einem anderen Team müht sich der gleiche Coach zwei Jahre ab und das Team fällt binnen weniger Monate in die alten Arbeitsweisen zurück, sobald es wieder auf sich gestellt ist. Beide Verhaltensweisen lassen sich sich mit HSD erklären: Das System (=Team) bildet ja nicht nur aufgrund der formalen Container, Differenzen und Exchanges Verhaltensmuster aus, sondern auch aufgrund der informellen, die sich oft über zehn oder mehr Jahre entwickelt haben. Ein wesentliches Merkmal komplexer Systeme ist ihre „Resilienz„, die Fähigkeit, äußere Veränderungen abzupuffern, ohne die Muster nachhaltig zu verändern. In der Regel sind versteckte Regeln dann mächtiger, als die offiziellen. Welche Änderungen notwendig sind, um echte Veränderung zu bewirken, lässt sich also nicht vorhersagen, weil man nicht weiß, wie die einzelnen Individuen und Container tatsächlich auf die Veränderung reagieren.

Man muss also experimentieren: Eine Änderung vornehmen und schauen, ob sie zu der gewünschten Veränderung führt. Dann die nächste Änderung vornehmen und so weiter. Um Resilienz zu durchbrechen, muss man manchmal auch „eine Bombe zünden“, also grundlegende Strukturen verändern, wie Scrum das meist tut. Aber es gibt nun mal Bunker, die sich auch mit viel Dynamit nicht sprengen lassen.

Das Experiment umfasst übrigens immer die Option des Scheiterns. Deshalb lassen sich agile Einführungen auch nicht vorweg planen und per „Blueprint“ ausrollen. Und deshalb haben wir beim „Agile Enterprise Adoption Workshop“ der Agile Alliance auch das „Ständige Lernen durch Experimente“ als eines der fünf kennzeichnenden Merkmale agiler Organisationen identifiziert.