Freitag, 11. Juli 2025
Now we've given them every freedom and they still don’t do what we want
Ich freue mich immer wenn ich auf jemanden verweisen kann den ich kenne, in diesem Fall auf Michael Mahlberg, bzw. auf seinen wie immer hörenswerten Vortrag auf der Konferenz Agile Meets Architecture 2025, der den wirklich schönen Titel trägt "Now we've given them every freedom and they still don’t do what we want".
Inhaltlich beleuchtet er die Rahmenbedingungen und der Führungsstile, deren Verständnis nötig ist, um zu wissen, wie man selbstorganisierten Teams eine Umgebung schafft, in der sie motiviert arbeiten und möglichst grosse Wirkung haben können (also das tun, was eigentlich jeder in seinem Beruf möchte).
Montag, 15. Mai 2023
Fachkräftemangel und Selbstorganisation
 |
| Bild: Pexels / Fauxels - Lizenz |
Zu den spannenden Fragen im Umfeld der stark auf selbstorganisierte Teams setzenden agilen Frameworks gehört diese: warum ist es vor allem in der Software-Entwicklung zu ihrer starken Verbreitung gekommen, während sie in anderen Branchen bisher eher Ausnahmeerscheinungen sind? Natürlich gibt es Erklärungsansätze, die aber meistens von der selben Prämisse ausgehen - der Komplexität des Arbeitsgegenstandes. Möglicherweise ist der Grund aber ein ganz anderer.
Zum besseren Verständnis kurz eine Erklärung der Arbeitsgegenstand-Hypothese. Sie beruht darauf, dass es sich bei der Softwareentwicklung um eine komplexe Tätigkeit handelt, also um eine, bei der Kleinteiligkeit, Vernetztheit und Volatilität dafür sorgen, dass ständig Neu- und Umgeplant werden muss. Da zentrale Befehls- oder Koordinations-Instanzen dabei zu verlangsamenden Flaschenhälsen werden können, wird angenommen, dass Selbstorganisation die logische Folge ist.
Was diese Annahme in Frage stellt ist ein Blick auf andere komplexe Arbeitskonstellationen. Z.B. unterliegen auch Filmproduktionen, Nachrichtenredaktionen und Spitzengastronomie den Faktoren Kleinteiligkeit, Vernetztheit und Volatilität, trotzdem ist Selbstorganisation in ihnen eher selten. Regelmässig aufkommende Skandale zeugen sogar vom Gegenteil: Macht-Zentralisierung (und Machtmissbrauch) sind weit verbreitet und werden stillschweigend geduldet.
Der zentrale Unterschied, der die IT-Branche von den gerade genannten (und vielen anderen) Branchen unterscheidet, ist der Fachkräftemangel. Während es auf dem Arbeitsmarkt ein deutliches Überangebot an Schauspielern, Kameraleuten, Journalisten und Köchen gibt, sind Softwareentwickler selten und schwer zu kriegen. Und selbst dort, wo es gelingt die freien Stellen zu besetzen, geschieht das häufig nur durch externe Dienstleister und Freiberufler.
Die sich daraus ergebenden Folgen kann sich jeder vorstellen: wer froh sein muss, einen von wenigen gut bezahlten Jobs ergattert zu haben, wird gegenüber seinem Vorgesetzten ein eher unterwürfiges Verhalten an den Tag legen, um ihn möglichst lange ausüben zu können. Und das sogar dann, wenn die Behandlung die man erfährt bestimmend, micro-managend oder sogar missbrauchend ist (in den oben verlinkten Artikeln sind z.T. verstörende Details zu lesen).
Umgekehrt wird jemand der nicht nur in kurzer Zeit sondern auch in der näheren Umgebung jederzeit eine neue, gleich gut bezahlte Anstellung finden kann, sich wenig gefallen lassen und im Zweifel durch eine Abstimmung mit den Füssen dafür sorgen, dass dominante Vorgesetzte bald niemanden mehr haben, den sie im Detail managen können. Und da jeder Manager das weiss wird er seinen Untergebenen bereits vorauseilend möglichst grosse Freiheiten gewähren.
Auch im Rahmen grosszügig gewährter Freiheiten muss aber sichergestellt sein, dass Kunden- und Unternehmens-Interessen und Gesetze gewahrt werden. Und da eine Erzwingung von oben die kostbaren Fachkräfte verschrecken könnte, ist die Gewährung von Selbstorganisation oft der beste Weg um zur Einhaltung dieser Vorgaben zu kommen - ihre Umsetzung wird einfach in die Verantwortung von selbstorganisierten Teams übergeben.
Um Missverständnisse zu vermeiden: damit soll nicht gesagt sein, dass die Annahme falsch ist, dass komplexe Herausforderungen am besten durch selbstorganisierte Teams gemeistert werden können. Vieles spricht dafür, dass das tatsächlich der Fall ist. Der tatsächliche Grund für die Zulassung und Förderung von selbstorganisiertem Arbeiten ist aber sehr oft eher darin zu finden, dass Jobs in den Mangelberufen der IT attraktiv ausgestaltet werden sollen.
Dienstag, 12. Juli 2022
Team-Charta
 |
| Bild: Wikimedia Commons / Hrvatski Sabor - Public Domain |
Fragt man agil arbeitende Teams woran sie sich in ihrer täglichen Arbeit ausrichten gibt es als Antwort meistens die bekannten Klassiker: den Scrum- oder Kanban-Guide (oder die Entsprechung in der jeweils angewandten Methode), die dazugehörenden Werte und grundlegende Regeln wie z.B. die Definition of Done. Viele Teams haben darüber hinaus aber noch ein weiteres Dokument: die Team-Charta (auch Team Charter, Team Agreements oder Ähnliches).
Das derartige Chartas weit verbreitet sind liegt an der Natur der agilen Frameworks. Bewusst geben sie nur einen groben Rahmen vor, der dann von jedem Team mit unterschiedlichen Konventionen, Abläufen oder Quality Gates ausgestaltet werden kann. Dass das nicht versehentlich in nicht zielführender Weise geschieht soll durch die jeweiligen Werte sichergestellt werden, zu denen sich die Ausgestaltung in keinem Widerspruch befinden soll.
Die Meetings in dem die meisten dieser Ausgestaltungen stattfinden sind normalerweise die jeweiligen Retrospektiven, Kaizen-Events, o.Ä. Das hat den Vorteil, dass diese selbstgegebenen Regeln und Vereinbarungen immer aktuell gehalten werden können, der Nachteil ist aber, dass es schnell unübersichtlich werden kann. Zu wissen was wann in welchem Termin beschlossen wurde wird mit der Zeit (und dem wachsenden Umfang) immer schwieriger.
Um diesem Problem zu begegnen kann es Sinn machen die selbstgegebenen Regeln und Vereinbarungen in einem einzigen zentralen Dokument festzuhalten, das dann immer wieder aktualisiert werden kann. Genau dieses Dokument ist es, dass dann als Team-Charta bezeichnet wird. Idealerweise ist es an einem zentralen Ort zu finden, z.B. an der Wand des Team-Raums, auf der Intranet-Startseite des Teams oder weit oben im jeweiligen Ordner-Baum.
Beispiele für Inhalte einer solchen Team-Charta sind der Umgang mit Pünktlichkeit und Timeboxing (kann gerade bei Teammitgliedern mit unterschiedlichen kulturellen Hintergründen sehr hilfreich sein), die Festlegung ob im Zweifel Dokumentation oder Kommunikation wichtiger sind, Vereinbarungen über Präsenz-Tage, meeting- und störungsfrei zu haltende Uhrzeiten, Verhaltensregeln für Meetings und Konfliktsituationen und vieles mehr.
Abzuraten ist von Inhalten die bereits an anderen Stellen festgehalten sind, etwa von Produkt- oder Mehrwert-Definitionen (gehört eher in Produktvision/Produktziel), von Vereinbarungen zu technischen und Qualitäts-Standards (gehört eher in Definition of Done/Policies) oder von Liefergegenständen und Lieferdaten (gehört eher in Product Roadmap/Product Backlog). Bestenfalls entsteht dadurch redundante Datenhaltung, schlimmstenfalls entstehen Widersprüche und Unklarheit.
Um es nachvollziehbar zu machen - eine derartige Team-Charta könnte so aussehen:
Wichtig bei Team-Chartas ist, dass es sich um lebende Dokumente handeln soll, die regelmässig aktualisiert, erweitert und wieder verschlankt werden sollten. Besonders das Letzte ist etwas das häufig vergessen wird, dabei aber von hoher Wichtigkeit ist - sobald die selbstgegebenen Regeln und Vereinbarungen in Summe zu umfangreich werden wird es schwer sie im Gedächtnis zu behalten und übersichtlich darzustellen. Auch hier gilt: im Zweifel ist weniger mehr.
Zuletzt noch ein Tipp aus der Praxis: in vielen Leitfäden wird neu zusammengestellen Teams empfohlen eine Team-Charta zu erstellen bevor die gemeinsame Zusammenarbeit beginnt. Das ist gut gemeint, führt aber selten zu guten Ergebnissen, da die Teammitglieder sich zu diesem Zeitpunkt noch gar nicht gut genug kennen können um zu wissen an welchen Stellen es wichtig ist, sich auf bestimmte Dinge zu einigen. Die Einigungen gehen dann oft am Bedarf vorbei.
Bessere Erfahrungen habe ich damit gemacht nach einem oder zwei Sprints oder Monaten zu fragen ob eine Team-Charta überhaupt gewünscht ist und erst dann die Inhalte zu erarbeiten. Normalerweise hat sich bis dahin herauskristallisiert ob Regelungsbedarf besteht, und wenn ja welcher. So ist das Ergebnis wesentlich bedarfsgerechter und die Akzeptanz und Nutzung wesentlich besser.
Dienstag, 8. Februar 2022
Enterprise Awareness
 |
| Bild: Wikimedia Commons / José Sáez - CC BY-SA 3.0 |
Es ist ein häufig zu beobachtendes Phänomen: im Rahmen einer Umstellung auf agile Arbeitsweisen lernen die beteiligten Teams, dass sie ab jetzt autonom und selbstverantwortlich sind, treffen mutig erste Entscheidungen - und kollidieren heftig mit Notwendigkeiten der sie umgebenden Organisation. Je nach Kontext folgen Klärungen oder Eskalationen, die aber in der Regel das selbe Ergebnis haben: den Teams werden die Grenzen der Selbstorganisation aufgezeigt.
An dieser Stelle ergibt sich eine spannende (und leider zu selten gestellte) Frage: wie kann es dazu kommen? Oder präziser gefragt: ist derartig handelnden Team nicht bewusst, dass es Vorgaben oder Abhängigkeiten gibt und welche das sind? Die Antwort darauf ist erstaunlich häufig Nein. Die Gründe dafür können vielfältig sein und von fehlendem Interesse bis zu einem Herrschaftswissen hortenden Manager reichen, das Ergebnis ist aber immer ähnlich - die oben erwähnte unschöne Kollision.
Zur Vermeidung dieser Kollision haben die agilen Frameworks mit der Zeit verschiedene Ansätze entwickelt. Scrum (und davon abgeleitet Nexus und LeSS) gehen etwa davon aus, dass die Gesamt-Organisation sich an den Bedürfnissen der Teams ausrichten muss, was prinzipiell richtig, in der Realität aber schwer umzusetzen ist. SAFe stützt sich auf Top-Down Vorgaben, was das Problem auf Kosten der Agilität löst. Und Flight Levels setzen einfach voraus, dass Abhängigkeiten irgendwie bekannt werden.
Den vermutlich pragmatischsten Weg hat ausgerechnet ein Framework gewählt, das bisher noch keine nennenswerten Impulse einbringen konnte: Disciplined Agile (DA), die "agile Tochter" des Project Management Institute (PMI). DA geht davon aus, dass agile Teams die in einem grösseren Umfeld eingebunden sind "Enterprise Awareness" entwickeln müssen, also ein Bewusstsein dafür, in welche Abhängigkeiten sie eingebunden sind und wo bereits Lösungen für ihre Probleme vorhanden sind.
Da dieses Bewusstsein nicht vom Himmel fällt wird von DA empfohlen, dass die Teams in einen engen Austausch mit Personen gehen die über eine ausreichende Übersicht verfügen und darauf aufmerksam machen können wo Team-übergreifende Zusammenhänge bestehen. Spezifisch genannt werden dafür Enterprise Architekten und Portfolio Manager, aber auch andere Rollen können in Frage kommen (je nach Einzelfall dürfte das unterschiedlich sein).
Natürlich ist auch dieser Ansatz nicht ohne Risiken. Zum einen müssen die Teams überhaupt wissen, dass es diese Ansprechpartner gibt, des weiteren müssen diese auch ausreichend freie Kapazität haben um im Zweifel kurzfristig ansprechbar zu sein und zuletzt müssen sie bereit sein ihre Rolle so auszuüben, dass sie eher beratend und weniger anweisend und kontrollieren ist (was umgekehrt natürlich voraussetzt, dass die Teams bereit sind sich beraten zu lassen).
Donnerstag, 3. Dezember 2020
Selbstorganisation (V)
 |
| Bild: Pixabay / Schoggimousse - Lizenz |
Es gibt Begriffe die scheinbar selbsterklärend sind, bei denen eine Diskussion aber hervorbringen kann, dass verschiedene Menschen sehr unterschiedliche Verständnisse von ihnen haben. Selbstorganisation gehört zu diesen Begriffen, vor allem dann wenn dieses Wort im Umfeld der agilen Frameworks benutzt wird. Gerade wegen seiner häufigen Verwendung in diesem Kontext lohnt es aber näher hinzuschauen - was könnte gemeint sein wenn von Selbstorganisation (genauer gesagt von selbstorganisierten Teams) die Rede ist? Folgende Varianten sind möglich:
I. Selbstorganisiertes Abarbeiten vorgeplanter und vorgegebener Tätigkeiten
Die vermutlich häufigste Variante. Anders als bei angeleitetem Arbeiten kann das Team selbst entscheiden wer welche Aufgaben übernimmt, allerdings unter der Voraussetzung, dass alles durchgehend oder zu vorgegebenen Zeitpunkten stattfindet. Ein Beispiel dafür wäre das Personal eines Supermarktes, das jeden Tag selbst entscheidet wer die Kasse besetzt, wer die Regale einräumt und wer den Boden reinigt.
II. Selbstgeplantes Abarbeiten vorgegebener Tätigkeiten
Ähnlich wie Variante I, aber mit einem zentralen Unterschied: selbst für die Planung des Abarbeitens verantwortlich zu sein bedeutet, dass man zwar weiterhin an die Umsetzung der vorgegebenen Themen gebunden ist, dass aber selbst entschieden werden darf wann, bzw. in welcher Geschwindigkeit das stattfinden wird. Ein Beispiel dafür wäre ein Fertigungsteam das nach dem Pull-Prinzip arbeitet.
III. Selbstorganisiertes Planen und Arbeiten in Richtung eines vorgegebenen Ziels
Das hier ist bereits etwas was man in vielen (mehr oder weniger) nach Scrum oder ähnlichen Frameworks arbeitenden Teams findet. Vorgegeben wird nur noch das Sprint- oder Produktziel, wie dieses erreicht wird ist aber nicht vorgegeben, solange es im Rahmen der eigenen Arbeit und des eigenen Budgets geschieht. In gewisser Weise Management by Objectives für Teams.
IV. Selbstorganisiertes Planen und Arbeiten in Richtung eines selbstgegebenen Ziels
In den meisten Organisationen die weitgehendste Form der Selbstorganisation die einem Team gewährt werden kann. Nicht nur über Art und Zeitplan der Arbeit kann selbst entschieden werden sondern auch über das Ziel das damit erreicht werden soll. Ein Beispiel dafür wäre ein Innovation Lab in dem Product Innovation und Product Discovery stattfinden.
V. Selbstorganisierter Zusammenschluss mit selbstgegebenem Ziel und selbstorganisiertem Planen und Arbeiten
Die Extremform. In dieser Variante schliessen sich Menschen aus freien Stücken zusammen um selbstbestimmt an einem selbstgewählten Ziel zu arbeiten. Beispiele hierfür wären ein buddhistisches Kloster oder ein Kibbuz, innerhalb grösserer Organisationen ist dieser Typ praktisch nicht existent.
Freitag, 5. Juni 2020
Der 'Gesellschaftsvertrag' als Grundlage der Selbstorganisation in Unternehmen
 |
| Bild: Wikimedia Commons / Peter Bircks - Public Domain |
1. Wir, das Management, geben unseren Mitarbeitern das Recht sich selbst zu organisieren und wir, die Mitarbeiter, werden diese Freiheit nicht nutzen um gegen die Interessen der Firma zu arbeiten
2. Wir, die Mitarbeiter, gewähren einen offenen Einblick in alle Arbeit die wir tun und wir, das Management, werden diese Transparenz nicht für Micro-Controlling und Micro-Management ausnutzen
3. Wir, Management und Mitarbeiter, sind uns bewusst, dass die verschiedenen Teile unseres Gesellschaftsvertrages sich gegenseitig bedingen und dass die Aufkündigung eines Teils immer auch den Rest ungültig macht
Donnerstag, 22. Februar 2018
Selbstorganisation auf der grünen Wiese
Eine Anekdote aus dem Leben eines Agile Coaches: in einem Unternehmen welches sich inmitten einer Transition befand waren die Parkplätze knapp. Um diesem Missstand abzuhelfen wurde der Bau eines Parkhauses beschlossen, und zwar genau auf der Stelle an der sich bis zu diesem Zeitpunkt der Parkplatz befunden hatte. Die unschöne Nebenwirkung - für die Dauer der Bauzeit wurden die Parkplätze nochmal knapper. Bis zum nächsten Parkplatz war es ein längerer Weg durch Matsch und Kälte. Und an dieser Stelle begann das Wunder der Selbstorganisation.
Als erstes entschied sich ein Mitarbeiter, auf dem Rand der Wiese neben der Strasse zu parken. Zunächst stiess es damit auf große Skepsis, schließlich befinden sich an der Strasse Halteverbotsschilder. Seine Argumentation war aber die: da die Wiese kein Teil der Strasse ist sondern Privatgrund gilt die Strassenverkehrsordnung dort nicht, Parken ist also erlaubt. Und da niemand auf dieser Wiese je einen Strafzettel bekommen hatte schien er recht zu haben. Bald war der Streifen entlang der Strasse zugeparkt.
Zu Beginn war das zwar eine kleine Verbesserung, es gab allerdings noch immer zu wenige Parkplätze. Irgendwann kam ein anderer Mitarbeiter auf eine weitere Idee: bis dahin hatten alle Autos längs zur Strasse am Wiesenrand geparkt, wenn sie stattdessen quer zur Strasse parken würden gäbe es mehr als doppelt so viele Parkmöglichkeiten. Also drehte er seinen inoffiziellen Parkplatz um 90 Grad. Sobald die anderen Mitarbeiter das sahen erkannten sie den Sinn und handelten genauso. Und bald parkten alle Autos quer zur Strasse.
Die beiden Notlösungen, das Parken an der Strasse und das Drehen der Behelsparkplätze um 90 Grad, waren nie ein Teil einer offiziellen Verkündung. Es gab keine Rundmail, keine Aushänge und keine Intranetseiten. Und trotzdem fanden sie beide im Abstand von ca. einem Monat statt, alleine dadurch, dass sich die Mitarbeiter selber organisierten. Zum Teil durch Gespräche untereinander, zum Teil einfach dadurch, dass sie dem Beispiel der anderen folgten.
Immer dann wenn in dieser Zeit ein Manager behauptete, dass seine Mitarbeiter nicht zur Selbstorganisation in der Lage seien trat der Agile Coach mit ihm an das nächste Fenster, zeigte auf die Autos und erzählte was es damit auf sich hatte. Das ging so weit, dass irgendwann ein Manager lachend abwinkte und sagte: "Ja, ja, die Autos. Ich sehe es ein, unsere Mitarbeiter können sich selber organisieren, man sieht es vor dem Fenster."
In vielen Unternehmen gibt es vergleichbare Beispiele für Selbstorganisation. Wenn man sie findet können sie als mächtige Metaphern dienen, mit denen sowohl das Management als auch die Mitarbeiter selbst von dem in ihnen vorhandenen Potential überzeugt werden können. Es lohnt sich also danach zu suchen.
Donnerstag, 26. Oktober 2017
Das Ende der Selbstorganisation
 |
| Bild: Wikimedia Commons / Famartin - CC BY-SA 4.0 |
Man kann es am einfachsten an den Extremfällen sehen. Ein Team in einer Firma für Bürosoftware kann noch so selbstorganisiert sein, wenn es sich entscheiden würde statt eines Antivirus-Patch der Bürosoftware lieber Computerspiele zu programmieren würde das Management das zu Recht verhindern. Und ein Entwicklungsteam einer Bank kann noch so selbstorganisiert entscheiden, dass es seine Prozesse nicht mehr dokumentiert, die Bafin würde ungerührt untersagen, dass die so entstandene Software in Produktion geht.
Auch Grenzfälle sind bei genauerer Betrachtung offensichtlich: ein Team das die eigene Anwendung sowohl weiterentwickelt als auch wartet kann zwar selbstorganisiert entscheiden wann seine Mitglieder ihren Urlaub nehmen, es muss aber dafür sorgen, dass immer jemand da ist der die Live-Version am Laufen hält. Und ein Team das eine neue Software baut kann zwar wählen welche Programmiersprache es benutzt, das Unternehmen kann aber verlangen, dass es eine ist die auch ausserhalb des Teams verstanden wird.
Schwierig wird es schließlich wenn die Selbstorganisation mit Unternehmensgrundsätzen kollidiert. Darf ein Team für seine MVPs Quick & Dirty-Lösungen implementieren wenn das Unternehmen Clean Code will? Dürfen sich Entwickler selbstorganisiert zu Teams von über 20 Personen zusammenschliessen wenn das Unternehmen auf kleine Squads oder Scrum Teams setzt um agil zu bleiben? Spätestens hier heißt es oft: "Wenn Ihr das vorschreibt schafft Ihr die Selbstorganisation ab!" Aber ist das wirklich ein Argument?
In den meisten Fällen zeigt sich an solchen Situationen, dass nie daran gedacht wurde festzulegen bis wohin Selbstorganisation geht (dass es solche Grenzen gibt sieht man an den ersten Beispielen). Bei vielen agilen Transitionen heisst es einfach "Ab jetzt sind die Teams selbstorganisiert". Und wenn die im Rahmen ihrer Selbstorganisation auf eine Stelle stossen an der diese doch nicht gewünscht ist knallt es gelegentlich. Das muss nicht sein.
Es ist empfehlenswert, dass Management und Team gemeinsam (!) Grenzen festlegen bis zu denen die Autonomie reicht. Welche das sind kann von Fall zu Fall unterschiedlich sein, sie sollten aber begründet und nachvollziehbar sein. Und es sollte auch jedem klar sein, dass diese Grenzen nicht unverrückbar sind sondern sich verschieben können. So kann etwa zu Beginn noch ein Architekt vorhanden sein, der sich irgendwann später selbst abschafft und in das Team geht.
Zuletzt kann jedes einzelne Teammitglied anhand dieser Grenzen entscheiden ob es sich hier noch richtig aufgehoben fühlt. Und wenn das nicht der Fall ist kann es mit den Füssen abstimmen und gehen, in ein anderes Team oder ein anderes Unternehmen.
Montag, 19. Juni 2017
Selbstorganisierte und sich selbst weiterentwickelnde Teams
 |
| Bild: Wikimedia Commons / Ron Scheffler - CC BY-SA 2.0 |
Selbstorganisierte Teams haben die Inhalte und Ziele ihrer Arbeit, die Eigenheiten ihrer Software (oder ihres sonstigen Arbeitsgegenstandes) und die Funktionsweise ihres Organisationsframeworks (Kanban, Scrum, etc.) verstanden und können das Erlernte anwenden. Arbeit nach dem Pull-Prinzip, realistische Commitments und ständige Optimierungen durch Retrospektiven o.ä. sind gegeben. Was ich bei derartig selbstorganisierten Teams aber mehrfach erlebt habe war, dass sie durch sich ändernde Rahmenbedingungen völlig aus der Bahn geworfen wurden. Beispiele dafür waren neue Technologien, neue Produkte, neue Mitarbeiter oder neue Organisationsprinzipien. Die erlernten Lösungswege passten nicht mehr, häufig mit Chaos, Stillstand oder Rückfall in Kommandostrukturen als Folge.
Sich selbst weiterentwickelnde Teams sind mit den selben Herausforderungen konfrontiert, sind aber in der Lage sie zu überwinden. Was sie von den "nur" selbstorganisierten Teams unterscheidet sind das Ziel und das Ergebnis des ständigen Verbesserungsprozesses. In ihm geht es nicht nur darum Bestehendes zu optimieren sondern auch darum sich an Neues anzupassen, Neues zu lernen und Neues auszuprobieren. Im besten Fall werden sogar neuartige Ansätze proaktiv ausprobiert, selbst wenn es noch keine offensichtliche Notwendigkeit dafür gibt. Wenn sie dann da ist gibt es bereits Erkenntnisse auf deren Basis man mit der neuen Situation umgehen kann.
Wenn ich für das Coaching eines Teams genügend Zeit bekomme ist in meinem Transitionsmodell das Herausbilden der Fähigkeit zum sich selbst weiterentwickeln Teil der Experimentierphase, nach der das Team keine Unterstützung mehr brauchen sollte. Häufig wird sie von meinen Auftraggebern weggespart, wodurch oft Teams entstehen die durch unbekannte Entwicklungen wie oben beschrieben aus der Bahn geworfen werden können. Dem Management zu vermitteln was für ein Risiko das ist gehört zu meinen anspruchsvolleren Aufgaben, an denen ich weiterhin wachse.
