HomeopathicCocoa
(c) by Michael Coghlan, er meint:

Homöopatischer Kakao? Ich wusste gar nicht, dass es so etwas gibt. Aber man lernt immer dazu… 😉

In den paar Jahren, in denen ich nun bereits Unternehmen coachen darf, ist mir immer klarer bewusst geworden, dass Coaching ähnlich wie Medizin wirkt. Wenn die Dosis zu klein ist, dann ist der Nutzen für das gecoachte Unternehmen gleich Null.

Die Unternehmensgrösse spielt, wie die Körpermasse eines Patienten auch eine Rolle. Je grösser das Unternehmen, desto grösser müsste eigentlich die verabreichte „Coaching-Dosis“ sein.

Nicht nur in der „agilen“ Welt gibt es Probleme mit der Dauerhaftigkeit der guten Ratschläge, die man gibt, wie folgende Artikel im Bereich anderer Verbesserungsansätze zeigen:

Die folgende Aufstellung ist nach grösser werdender Wirkung priorisiert:

  1. 100%-ige (zeitlich) Mitarbeit in einem Projekt, mit mindestens 50% Anteil von „Coaches“ im Team, über einen Zeitraum von mindestens 6 Monaten (bei grösseren Unternehmen mindestens für ein Jahr).
  2. 100%-ige (zeitlich) Mitarbeit in einem Projekt als „ScrumMaster“ oder in einer ähnlichen Rolle, über einen Zeitraum von mindestens 6 Monaten (bei grösseren Unternehmen mindestens für ein Jahr).
  3. Begleitung eines Teams über mindestens 6 Monate als Coach, mindestens einen Tag pro Woche, mit Schulungen und „Hands-on“-Mitarbeit bei einzelnen Tätigkeiten.

Einige zusätzliche Pointer:

 

Ich war vor kurzem bei einem Kurs und bin so mal wieder mit der „Aussenwelt“ in Kontakt gekommen. Man unterhielt sich und plauderte auch über die eigene Arbeit, das Unternehmen und später sogar darüber was einen störte.  Ich war überrascht in was für Umgebungen so mancher meiner „neuen Kollegen“ arbeitet und wie Unternehmen mit ihren Mitarbeitern und Teams umgehen. Hier einige Beispiele:

  • Vor /während/ nach jedem Projekt werden die Mitarbeiter in neue Teams verschoben, weil dort „Not am Mann“ ist.
  • Während eines Projekts müssen sie sich prozentual aufteilen (20% hier, 10% dort, 30% ganz woanders), da das Wissen sonst nicht vorhanden ist.
  • Sie werden in Technologiekatekorien unterteilt, da jemand der Meinung ist so das Beste aus dem Team herauszuholen.

Schon 1965 beschrieb Bruce Tuckman die verschiedenen Phasen der Teambildung. Zu allererst wird das Team gebildet. Dabei versucht jeder keinem anderen auf die Füsse zu treten, sich anzupassen und akzeptiert zu werden (Forming). Nach einiger Zeit gibt es die ersten Reibereien und jeder versucht seine Ideen/Perspektiven den anderen näher zu bringen (Storming). Sollte das Team es schaffen in die nächste Phase überzugehen, steht das gemeinsame Ziel an oberster Stelle (Norming) und die eigenen Ziel treten in den Hintergrund. Einige der Teams schaffen es noch eine Stufe weiter: Performing – das Team funktioniert als eine Einheit und erledigt die Aufgaben reibungslos.

Somit sollte auch klar sein, das es nicht möglich ist Teams auf dem Papier zu erschaffen und zu hoffen, das daraus „High-Performance-Teams“ werden.

  • Jeder Mensch braucht Zeit um sich in Gruppen/Teams zurecht zu finden
  • Jeder einzelne in einem Team sollte zu 100% in diesem arbeiten.
  • Das Team sollte eine Technologie beherrschen, nicht nur Einzelne im Team.

Aber auch jedes „gestandene“ Team ist nicht vor diesen Veränderungen gefeit. Ein neues Teammitglied, ein neuer Vorgesetzter oder andere Umstrukturierungen innerhalb des Unternehmens können dazu führen, das ein Team alle Phasen erneut durchleben muss. Aus diesen Gründen sollten man allen Teams auch Zeit geben, um sich zu finden und die Chance zu erhalten ein „High-Performance-Team“ zu werden.

Immer wieder werde ich gefragt, ob es besser ist einen agilen Prozess mit einem „Big Bang“ in eine Organisation einzuführen, oder ob es nicht besser ist ganz langsam kleine Veränderungen  vorzunehmen, die man im Vorfeld mit der bestehenden Organisation austariert.

Ich will hier nicht sagen: „it depends“. Stattdessen ein paar Grundsätze, die sich aus der Erfahrung mit verschieden grossen Unternehmen ergeben:

  1. „Big Bang“ funktioniert selten.
  2. „Big Bang“ funktioniert nur, wenn das Top-Management voll dahinter steht und alle gemeinsam anpacken.
  3. „Alle gemeinsam“ bedeutet nicht nur eine kleine Schar von Eingeweihten.
  4. Ohne Einbezug aller (und vor allem derer, die die Hauptlast der Arbeit tragen, oder von der Veränderung am meisten Betroffen sind), ist der Effort zum Scheitern verurteilt.
  5. Man kann nicht nur eine Softwareentwicklungsabteilung in Isolation „transformieren“. Ohne den Einbezug des Fachs (sprich der Fachabteilungen, bzw. des Kunden) funktioniert gar nichts.
  6. Ohne Freiraum geht es nicht. Man kann nicht von seinen Mitarbeitern erwarten, dass sie den Entwicklungsprozess ändern, ohne dass sie die Zeit und Musse haben, sich selbst aktiv in die Veränderung einzubringen. Keiner wird dafür seine Freizeit opfern. Das kann man von niemandem erwarten!

Die Veränderung von Arbeitsweisen, von Gewohnheiten und das Schlachten von „heiligen Kühen“ stösst bereits selten auf Gegenliebe. Erschweren wir den Prozess nicht unnötig, sondern suchen nach Wegen, um das Unmögliche möglich zu machen!