Was, wenn sich mein Team gar nicht entwickeln will? E-Book

Michel Eggebrecht

• Herausgeber: Carl-Auer Verlag
• Kategorie: Fachliteratur
• Serie: Management
• Sprache: Deutsch
• Veröffentlichungsjahr: 2024

Seitenzahl: 275

Beschreibung

Das Zwischenmenschliche im Blick Teamentwickler:innen und Führungskräfte haben die Aufgabe, auf die Entwicklung von Teams positiv einzuwirken. Sie stehen dabei vor schwierigen Fragen: Wohin soll die Entwicklung überhaupt gehen, und wer bestimmt die Richtung? Was mache ich, wenn mir ein Team abwehrend gegenübersteht? Stehe ich auf der Seite des Teams oder auf der Seite der Organisation? Das Buch behandelt mehr als 40 dieser herausfordernden Fragestellungen und richtet dabei einen besonderen Blick auf "selbstgesteuerte" Teams, wie sie im agilen Umfeld häufig anzutreffen sind. Zu Beginn klärt Michel Eggebrecht zentrale Grundbegriffe wie Team, Teamentwicklung, Teamentwickler, die für das weitere Verständnis wichtig sind. Die folgenden Kapitel behandeln jeweils nach einem einheitlichen Schema eine besondere Herausforderung. Sie können unabhängig voneinander und in beliebiger Reihenfolge gelesen werden. Querverweise stellen inhaltliche Beziehungen zwischen den einzelnen Fragestellungen her. In der Summe entsteht so ein theoretisch fundierter und gleichzeitig praxisnaher Begleiter, der alle Beteiligten im Blick hält: das Team, die Organisation und die Führungskraft bzw. Teamentwickler:in selbst. Der Autor: Michel Eggebrecht, M. Sc.; Wirtschaftspsychologe, systemischer Organisationsberater und Agile Coach; vormals Scrum Master in verschiedenen Teams und disziplinarische Führungskraft im agilen Umfeld sowie Dozent an der Hochschule Fresenius für Sozialpsychologie, Konfliktmanagement und Moderation. Arbeitsschwerpunkte: selbstgesteuerte Teams, Einbettung agiler Teams in komplexe Unternehmenskontexte, Entscheidungsprozesse im agilen Umfeld, Teammediation, Ausbildung von Scrum Mastern.

Leseprobe

Die Reihe Management / Organisationsberatung

Die heutige Gesellschaft ist eine organisierte Gesellschaft. Man muss schon lange suchen, um überhaupt noch Bereiche zu finden, die nicht von Organisationen geprägt sind. Unternehmen jedweder Größe und Eigentumsform, Verwaltungen, Schulen, Gerichte, Krankenhäuser, Universitäten, Kirchen, Verbände, Parteien, Vereine etc. – allesamt übernehmen sie gesellschaftliche Funktionen und bestimmen unser Leben. Die Fülle an Aufgaben, die unter den Bedingungen zunehmender Globalisierung und Digitalisierung gleichzeitig zu erfüllen sind, wie auch die Bandbreite an Organisationskonzepten und Führungsansätzen, mit denen der komplexe Alltag bewältigt werden soll, stecken das Feld ab, in dem Management und Beratung mehr oder weniger wirksam werden.

Die Zeiten, in denen es einfache Antworten auf die vielfältigen Fragen zur Überlebenssicherung einer Organisation und auch zur Steuerung tagtäglicher Entscheidungsprozesse gab, sind seit Langem vorüber. Der Komplexität, mit der heute alle konfrontiert sind, die in verantwortlichen Funktionen in und mit Organisationen arbeiten – Führungskräfte, Manager und Organisationsberater etc. –, wird man mit Rezeptwissen nicht mehr gerecht. Hier setzen die neuere Systemtheorie und mit ihr die Reihe Management/Organisationsberatung im Carl-Auer Verlag an. Beide liefern Konzepte und »Landkarten«, die auch im unübersichtlichen Terrain von Wirtschaft und Organisation Orientierung ermöglichen und Handlungsfähigkeit sicherstellen.

Das Ziel der Reihe ist es, empirisch gehaltvolle Forschungen über die Prozesse des Organisierens wie auch theoretisch angemessene Führungs- und Beratungsansätze zu präsentieren. Zugleich sollen bewährte Methoden einer system- und lösungsorientierten Praxis im Kontext von Organisationen überprüft und neue Ansätze entwickelt werden.

Torsten Groth

Herausgeber der Reihe

Management/Organisationsberatung

Michel Eggebrecht

Was, wenn sich mein Team gar nicht entwickeln will?

Herausforderungen für Teamentwickler und Führungskräfte

2024

Mitglieder des wissenschaftlichen Beirats des Carl-Auer Verlags:

Prof. Dr. Dr. h. c. Rolf Arnold (Kaiserslautern)

Prof. Dr. Dirk Baecker (Dresden)

Prof. Dr. Ulrich Clement (Heidelberg)

Prof. Dr. Jörg Fengler (Köln)

Dr. Barbara Heitger (Wien)

Prof. Dr. Johannes Herwig-Lempp (Merseburg)

Prof. Dr. Bruno Hildenbrand (Jena)

Prof. Dr. Karl L. Holtz (Heidelberg)

Prof. Dr. Heiko Kleve (Witten/Herdecke)

Dr. Roswita Königswieser (Wien)

Prof. Dr. Jürgen Kriz (Osnabrück)

Prof. Dr. Friedebert Kröger (Heidelberg)

Tom Levold (Köln)

Dr. Kurt Ludewig (Münster)

Dr. Burkhard Peter (München)

Prof. Dr. Bernhard Pörksen (Tübingen)

Prof. Dr. Kersten Reich (Köln)

Dr. Rüdiger Retzlaff (Heidelberg)

Prof. Dr. Wolf Ritscher (Esslingen)

Dr. Wilhelm Rotthaus (Bergheim bei Köln)

Prof. Dr. Arist von Schlippe (Witten/Herdecke)

Dr. Gunther Schmidt (Heidelberg)

Prof. Dr. Siegfried J. Schmidt (Münster)

Jakob R. Schneider (München)

Prof. Dr. Jochen Schweitzer † (Heidelberg)

Prof. Dr. Fritz B. Simon (Berlin)

Dr. Therese Steiner (Embrach)

Prof. Dr. Dr. Helm Stierlin † (Heidelberg)

Karsten Trebesch (Dallgow-Döberitz)

Bernhard Trenkle (Rottweil)

Prof. Dr. Sigrid Tschöpe-Scheffler (Köln)

Prof. Dr. Reinhard Voß (Koblenz)

Dr. Gunthard Weber (Wiesloch)

Prof. Dr. Rudolf Wimmer (Wien)

Prof. Dr. Michael Wirsching (Freiburg)

Prof. Dr. Jan V. Wirth (Meerbusch)

Themenreihe »Management und Organisationsberatung«

hrsg. von Torsten Groth

Reihengestaltung: Uwe Göbel

Umschlaggestaltung: B. Charlotte Ulrich

Umschlagfoto: © Joschua – stock.adobe.com

Redaktion: Markus Pohlmann

Satz: Drißner-Design u. DTP, Meßstetten

Printed in Germany

Druck und Bindung: CPI books GmbH, Leck

Erste Auflage, 2024

ISBN 978-3-8497-0543-5 (Printausgabe)

ISBN 978-3-8497-8505-5 (ePUB)

© 2024 Carl-Auer-Systeme Verlag

und Verlagsbuchhandlung GmbH, Heidelberg

Alle Rechte vorbehalten

Bibliografische Information der Deutschen Nationalbibliothek:

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Informationen zu unserem gesamten Programm, unseren Autoren und zum Verlag finden Sie unter: https://www.carl-auer.de/

Dort können Sie auch unseren Newsletter abonnieren.

Carl-Auer Verlag GmbH

Vangerowstraße 14 • 69115 Heidelberg

Tel. [phone] • Fax [phone]

[email protected]

Inhalt

Einleitung

1

Grundlagen: Das Team, der Teamentwickler und die Organisation

1.1

Braucht es überhaupt Teamarbeit?

Was ist ein Team?

Wann sind Teams sinnvoll?

Wann sind Teams nicht sinnvoll?

1.2

Ich soll das Team entwickeln. Was bedeutet das?

1.3

Die Organisation als Umwelt des Teams: Freundin oder Feindin?

2

Die passende Haltung des Teamentwicklers

2.1

Ist es mein Job, die Teammitglieder beziehungsweise deren Mindset zu verändern?

Lassen sich Mindsets verändern?

2.2

Wenn ich die Menschen nicht verändern soll, was dann?

Ein Spiel besteht aus den Spielregeln und nicht aus den Spielern

Verschiedene Teams bilden unterschiedliche Regeln aus

Wie Teamregeln entstehen

Vor- und Nachteile von Regeln im Team

Was bedeutet das für Teamentwickler?

2.3

Fördern und fordern: Wie direktiv darf und soll ich als Teamentwickler sein?

2.4

Es heißt, die Lösung liege bereits im Team. Gilt das immer?

2.5

Stehe ich auf der Seite des Teams oder auf der Seite der Organisation?

Offenheit gegenüber dem Team

Offenheit gegenüber dem Management

3

Die Anfangsphase einer Teamentwicklung: Anschluss finden und Weichen stellen

3.1

Worauf sollte ich für einen guten ersten Eindruck beim Team unbedingt achten?

»Hoffentlich will der nicht verändern, was gut ist«

»Hoffentlich versteht der, dass wir noch andere Sachen zu tun haben«

»Hoffentlich kann der auch mit den schwierigen Themen umgehen«

3.2

Wie stelle ich in der Anfangsphase die richtigen Weichen für die Arbeit am Team?

3.3

Ist es bereits zu spät, wenn ich einen guten Anfang mit dem Team verpasst habe?

3.4

Was tun, wenn sich das Team gar nicht entwickeln will?

Ansatzpunkte im Team

Nachdruck vonseiten des Managements

Den Auftrag abbrechen

4

Den Auftrag klären

4.1

Wozu brauche ich eine Auftragsklärung?

4.2

Worauf sollte ich im Rahmen der Auftragsklärung schauen?

Mit dem Auftragsklärungskompass einen Überblick über das Anliegen erhalten

Fragen, um Hinweise zur Anschlussfähigkeit zu erhalten

4.3

Wann sollte ich einen Auftrag ablehnen?

5

Themen und Ziele der Teamentwicklung

5.1

Brauchen Teams Teamentwicklungsziele?

5.2

Wir haben zwar Teamentwicklungsziele, aber niemand orientiert sich daran. Wie kann das sein?

Ziele dürfen nicht zu allgemein formuliert sein

Ziele dürfen nicht zu konkret formuliert sein

5.3

Kann und sollte das Management Teamentwicklungsziele vorgeben?

5.4

Was tun, wenn ich nicht weiß, woran ich mit dem Team arbeiten soll?

6

Für Veränderung sorgen

6.1

Wie finden wir die wahre Ursache, um nicht nur an Symptomen herumzudoktern?

6.2

Unsere Maßnahmen versanden – Wie lassen sich neue Verhaltensweisen im Team verankern?

Phase 1: Wahl

Phase 2: Erprobung

Phase 3: Reflexion

6.3

Wie beeinflusse ich die weichen Faktoren?

6.4

Mein Team meckert über Dinge, die es ohnehin nicht ändern kann. Wie gehe ich damit um?

7

Das Zwischenmenschliche im Blick behalten

7.1

Was tun, wenn die Teammitglieder untereinander nicht auf Augenhöhe sind?

Teams bilden informelle Hierarchien aus

Ist die informelle Hierarchie ein Problem?

Wie beeinflusse ich die informelle Hierarchie eines Teams?

7.2

Sollen schwierige Themen immer offen angesprochen werden?

Teamreflexivität und Teamleistung

Teams reden nicht offen über alles …

… und das nicht ohne Grund

Wann wird die Art des Umgangs mit Konflikten ungesund?

Versuche ich als Teamentwickler, Tabus zu brechen?

7.3

Die psychologische Sicherheit im Team ist gering. Was kann ich tun?

Wie lässt sich psychologische Sicherheit gezielt fördern?

7.4

Was tun, wenn »schwierige« Kollegen das Klima belasten?

7.5

Braucht mein Team eine Mediation?

Mediation als Chance begreifen

8

Selbststeuerung fördern

8.1

Brauchen wir jemanden, der sagt, wo es langgeht?

8.2

Was tun, wenn mein Team die einfachsten Abstimmungen nicht hinbekommt?

8.3

Mein Team übernimmt keine Verantwortung. Was soll ich tun?

8.4

Sind gemeinsame Entscheidungen immer besser?

Gruppenentscheidungen sind sinnvoll, …

Werden Ideen ausgesprochen und Informationen geteilt?

8.5

Wie sollte in Teams entschieden werden?

Entscheidungsprozesskriterien

Wie entscheiden Teams darüber, wie entschieden wird?

8.6

Was tun, wenn mein Team keine Entscheidungen trifft?

Aushalten von Unsicherheit

Entscheidungsbefugnisse

9

Auf Umfeld und Rahmenbedingungen des Teams einwirken

9.1

Was tun, wenn die Zusammenarbeit mit umliegenden Teams oder Abteilungen hakt?

9.2

Soll ich mein Team gegen übergriffige Manager abschirmen?

Ein paar Gedanken zu Vertrauen und Kontrolle

9.3

Das Team ist orientierungslos: Was tun, wenn der Auftrag des Teams oder dessen Gestaltungsspielraum unklar ist?

9.4

Mein Team steht enorm unter Zeitdruck. Was soll ich tun?

9.5

Das Team wächst und wächst. Sind wir nicht langsam zu groß?

10

Das Ende in Sicht

10.1

Das Ende des Projekts ist in Sicht. Was bedeutet das für die letzten Wochen der Teamentwicklung?

10.2

Wann sollte der Teamentwickler das Team verlassen?

Anhang: Agile Grundbegriffe

Literatur

Über den Autor

Einleitung

Ist es meine Aufgabe als Teamentwickler,1 gezielt Einfluss auf ein Team, bestehend aus erwachsenen Menschen mit eigenem Willen, zu nehmen? Wie soll das gehen? Das Team soll sich entwickeln. Aber wohin eigentlich? Und wer bestimmt die Richtung? Was mache ich, wenn sich ein Team gar nicht weiterentwickeln will oder mir abwehrend gegenübersteht? Was, wenn Verbesserungsmaßnahmen ständig im Sande verlaufen? Oder das Team keine Verantwortung übernimmt? Wie gehe ich damit um, wenn schwierige Teammitglieder das Klima vergiften? Wann sollte im Team gemeinsam entschieden werden? Und wann nicht? … Sowohl temporäre Teamentwickler, die nur punktuell und anlassbezogen zum Team hinzustoßen, als auch dauerhafte Teamentwickler, wie zum Beispiel Scrum Master, sehen sich mit schwierigen Fragen konfrontiert. Um diese und viele weitere Herausforderungen geht es in diesem Buch.

Verteilt auf zehn thematisch gegliederte Kapitel, betrachten wir herausfordernde Fragestellungen, die jeweils im Rahmen eines Unterkapitels dargestellt werden. Jedes Unterkapitel beginnt damit, in die Gedankenwelt eines fiktiven Teamentwicklers einzutauchen, der mit einer ganz konkreten Fragestellung zu kämpfen hat. So ringt er an einer Stelle mit der Frage, ob er sich besser auf die Seite des Teams oder auf die Seite der Organisation stellt. An anderer Stelle verzweifelt er über die fehlende Verantwortungsübernahme seines Teams.

In Kapitel 1 erläutere ich einige zentrale Grundbegriffe (Team, Teamentwicklung, Teamentwickler), die für das weitere Verständnis wichtig sind. Danach steht es dem Leser frei, sich eine ihm spannend erscheinende Fragestellung aus dem Inhaltsverzeichnis herauszugreifen und direkt an die entsprechende Stelle zu springen. Die Hauptkapitel können unabhängig voneinander in beliebiger Reihenfolge gelesen werden. Wer direkt in ein Unterkapitel einsteigen will, sollte zuvor zumindest die kurze Einführung des zugehörigen Hauptkapitels lesen, in der relevante Begriffe eingeführt werden. Querverweise kennzeichnen inhaltliche Beziehungen zwischen den Kapiteln. Wer auf große inhaltliche Sprünge verzichten will, darf das Buch auch ganz gewöhnlich von vorne nach hinten durchlesen.

Wir beginnen in Kapitel 1 mit den Grundlagen und erläutern zentrale Begriffe. Danach behandeln wir die Rolle und Haltung des Teamentwicklers (Kapitel 2). Wenn Team und Teamentwickler aufeinandertreffen, stellen sich die Weichen der Zusammenarbeit. Teamentwickler, die in der Anfangsphase keinen Anschluss ans Team finden, bleiben oft wirkungslos. Dazu mehr in Kapitel 3. Um einen guten Start hinzulegen, bedarf es einer soliden Auftragsklärung (Kapitel 4). Kapitel 5 dreht sich um die Wahl und Formulierung von Themen und Zielen, die im Rahmen der Teamentwicklung bearbeitet beziehungsweise erreicht werden sollen. Wenn diese geklärt sind, geht es ans Eingemachte: Teamentwickler sollen für Veränderungen im Team sorgen. Wie sie das tun können, behandelt Kapitel 6. Wer als Teamentwickler arbeitet, muss immer auch die zwischenmenschliche Dynamik des Teams im Blick behalten (Kapitel 7). Kapitel 8 befasst sich unter dem Stichwort Selbststeuerung mit Fragen der Koordination, Verantwortungsübernahme und Entscheidungsfindung von Teams. Da Teams nicht frei in der Organisation herumschweben, betrachten wir auch den Rahmen, der das Team in der Organisation umgibt und, so viel sei schon hier angemerkt, der die Arbeit des Teams sowie die Möglichkeiten der Teamentwicklung erheblich beeinflusst (Kapitel 9). Abschließend schauen wir auf das Ende der gemeinsamen Reise von Team und Teamentwickler (Kapitel 10).

Ein kurzer Hinweis noch: Die gewählten Beispiele entspringen an vielen Stellen agilen Umfeldern. Der Bedarf agiler Teams an Teamentwicklung ist aufgrund ihrer hohen Anforderungen an die Selbststeuerung besonders groß. Entsprechend finden sich in agil arbeitenden Teams oft Rollenträger, die dauerhaft mit einem Teamentwicklungsauftrag ausgestattet sind (z. B. Scrum Master). Aber auch »klassische« Teamleiter, die ihr Team weiterentwickeln wollen, oder Coaches, die vorwiegend nicht in agilen Umfeldern tätig sind, sollten sich an dieser Stelle nicht abschrecken lassen. Die Stolperfallen sind in vielen Fällen die gleichen, und die hier dargestellten Gedanken lassen sich auf ganz unterschiedliche Kontexte übertragen. Um Außenstehenden oder »agilen Neulingen« einen guten Zugang zu ermöglichen, habe ich versucht, mich auf eine geringe Anzahl agil-spezifischer Begriffe zu beschränken. Wer Scrum in den theoretischen Grundzügen verstanden hat, wird sich problemlos durch das Buch bewegen. Für alle anderen habe ich notwendiges Wissen im »Anhang: Agile Grundbegriffe« kurz dargestellt.

1

Wegen der besseren Lesbarkeit verzichte ich in diesem Buch meist darauf, geschlechterspezifische Formulierungen zu verwenden. Personenbezogene Bezeichnungen in der männlichen grammatischen Form beziehen sich in der Regel auf alle Geschlechter.

1 Grundlagen: Das Team, der Teamentwickler und die Organisation

Wir beschäftigen uns zunächst mit grundsätzlichen Fragen:

Wann braucht es überhaupt Teamarbeit und wann nicht (

Kap. 1.1

)?

Was ist Teamentwicklung und was die Aufgabe eines Teamentwicklers (

Kap. 1.2

)?

Welche Rolle spielt die Organisation, die das Team umgibt (

Kap. 1.3

)?

1.1 Braucht es überhaupt Teamarbeit?

Gedanken eines Teamentwicklers: Jeden Morgen stehen wir mit dem ganzen Team im Daily Stand-up zusammen. Nacheinander berichten alle Teammitglieder, was sie seit gestern geschafft haben und was sie sich für heute vornehmen. Nur scheint es keinen zu interessieren. Nach 15 Minuten sind wir durch, und jeder geht wieder an seine Arbeit. Im Zweiwochentakt reflektiert das Team im Rahmen der Retrospektive die gemeinsame Zusammenarbeit. Auch das ist zäh. Es wird nach Themen gesucht, aber nur selten etwas gefunden, was für alle relevant ist. Die Beteiligung ist mau, und die Leute scheinen froh zu sein, wenn sie wieder an ihren Schreibtisch können. Dabei habe ich schon alles Mögliche ausprobiert, um die Meetings lebendiger zu gestalten. Langsam frage ich mich, wieso wir das eigentlich machen. Braucht es Teamarbeit mit den ganzen Meetings, wenn alle ihre Aufgaben unabhängig voneinander erledigen können?

Teams sind die Allzweckwaffe moderner Unternehmen. So scheint es zumindest. Wo der Begriff Agilität fällt, sind Teams die Grundpfeiler der Wertschöpfung, und auch sonst verzichtet kaum ein Unternehmen auf Teamarbeit. Aber ist das gerechtfertigt? Die kurze Antwort lautet: Nein, Teams sind nicht immer sinnvoll. Organisationen, die Teamarbeit an der falschen Stelle einsetzen, erzeugen Aufwände, für die es keinen Bedarf gibt. Teamentwickler sollten erkennen, wann Unternehmen besser auf Teamarbeit verzichten. Gehen wir einmal einen Schritt zurück und fragen uns, was ein Team überhaupt ist.

Was ist ein Team?

Alles beginnt mit einer Grenzziehung. Unternehmen, oft mit Tausenden von Mitarbeitern, ziehen einen Kreis um eine kleine Anzahl von Mitarbeitern und bezeichnen sie als Team. Wer innerhalb des Kreises steht, gehört zum Team, wer außerhalb steht, nicht. Die Grenze ist klar (Hackman 2012, p. 437). Teams erhalten darüber hinaus eine gemeinsame Ausrichtung. Sie sollen Hand in Hand auf dasselbe Ziel zusteuern oder sich denselben Verantwortungsbereich teilen. Die Idee dahinter: Alle innerhalb der nun gezogenen Teamgrenze sollen besonders eng miteinander im Austausch sein, um die gemeinsame Aufgabe zu erledigen beziehungsweise das geteilte Ziel anzustreben. Kein Teammitglied wäre in der Lage, das Ziel ohne die Kollegen zu erreichen. Die Teammitglieder sind in diesem Sinne abhängig voneinander (Salas et al. 1992, p. 4).

Wann sind Teams sinnvoll?

Teams sind (nur!) dann sinnvoll, wenn Abstimmungsbedarf zwischen den Beteiligten besteht: »Sagt Bescheid, wenn ihr die Texte geprüft habt. Dann setze ich mich ans Layout.« »Hast du einmal die Zahlen für die Präsentation für mich?« »Ich bin gleich in der Datenbank. Denkt dran, in der Zeit keine Anpassungen vorzunehmen!« … Wenn derartige Sätze immer wieder zu hören sind, scheint ein hoher Abstimmungsbedarf vorzuliegen.

Teams kommen häufig bei komplexen Aufgabenstellungen zum Einsatz, die ganz unterschiedliche Kompetenzen erfordern. Man denke an das Entwickeln einer Software: Wer ist der Nutzer der Software, und welches Problem will er damit lösen? Wie passt das Feature in die bestehenden Prozesse? Wie könnte die technische Implementierung aussehen? Woher bekommen wir die notwendigen Daten? Gibt es rechtliche Rahmenbedingungen? …

Eine Einzelperson wäre mit diesem Wust an Fragen überfordert. Ein Team hingegen kann auf die unterschiedlichen Erfahrungen, Qualifikationen und Fertigkeiten der Mitglieder zurückgreifen. Stehen komplexe Probleme auf der Tagesordnung, die nur dadurch gelöst werden können, dass dieselben Know-how-Träger regelmäßig ihre Köpfe zusammenstecken, spricht das für den Einsatz eines Teams. Mit der Zeit entwickeln die Teammitglieder eine gemeinsame Sprache und lernen, wer für welches Problem zusammenkommen muss, um eine Lösung zu (er)finden.

Wann sind Teams nicht sinnvoll?

Bei Weitem nicht jede Aufgabenstellung erfordert echte Teamarbeit. Viele Aufgaben können gut von kompetenten Einzelpersonen gelöst werden. So kann der Biochemiker die Arbeit in seinem Labor weitgehend autonom gestalten. In vielen Jobs steht auch die effiziente Abarbeitung von Routineaufgaben im Vordergrund. Bei der Bearbeitung von Standardanträgen oder der Zustellung von Paketen müssen nicht ständig komplexe Probleme gelöst werden, die das Know-how unterschiedlicher Personen erfordern. Hier sollte bestmöglich standardisiert werden, um hohe Effizienz zu erreichen. Teams, die ihre Arbeit gemeinsam hinterfragen und versuchen, innovative Ideen zu entwickeln, wären hier eher hinderlich. Auch wenn in Ausnahmefällen komplexe Probleme entstehen, bedarf es dafür noch kein dauerhaft angelegtes Team. Oft reicht es dann situationsspezifisch im jeweiligen Einzelfall, die richtigen Leute an einen Tisch zu setzen.

Zwischen isolierten Einzelarbeitsjobs einerseits und abstimmungsintensiver Teamarbeit andererseits gibt es einige Schattierungen. Stellen wir uns mehrere Recruiter vor, die gemeinsam für die Besetzung aller vom Unternehmen ausgeschriebenen Stellen verantwortlich sind. Zum einen haben alle Recruiter ihre eigenen Vakanzen, die sie vom Schreiben der Stellenanzeige bis zur Unterzeichnung des Arbeitsvertrags weitestgehend allein betreuen. Zum anderen gibt es dennoch regelmäßige Abstimmungsbedarfe: »Liest du mal über meine Stellenanzeige drüber? Die Position müssen wir dringend besetzen, kannst du hier mit auf die Suche gehen? Ich bin kommende Woche im Urlaub. Kannst du das Bewerbungsgespräch übernehmen?«

Wie hoch der Abstimmungsbedarf sein muss, um von einem echten Team zu sprechen, lässt sich nicht eindeutig festlegen. Dass in Unternehmen häufig von Teams gesprochen wird, obwohl diese die definitorischen Anforderungen an ein Team (gemeinsame Ausrichtung, Abstimmungsbedarf) streng genommen nicht erfüllen, ist nicht weiter schlimm. Kritisch wird es erst, wenn eine Organisationseinheit teamartige Kommunikationsstrukturen (Meetings) einführt, obwohl diese nicht notwendig sind. Wenn man sich als Teamentwickler also in einem Team wiederfindet, in dem die Meetings zäh sind und die Relevanz des gemeinsamen Austauschs vom Team infrage gestellt wird, kann das ein Signal dafür sein, dass Teamarbeit an der falschen Stelle eingesetzt wird. Teamentwickler können dann darauf hinwirken, die Kommunikationsaufwände (Meetings) zu reduzieren. Gibt es nichts abzusprechen, ist auch kein tägliches Stand-up-Meeting zur Synchronisation der Teammitglieder notwendig.

Es sei noch angemerkt, dass schleppende Meetings und ein fehlendes Wir-Gefühl, nicht zwangsläufig darauf zurückzuführen sind, dass der ans Team gerichtete Auftrag keine Zusammenarbeit erfordert. Möglicherweise werden die Termine nicht gut moderiert, oder ein schwelender Konflikt drückt die Stimmung. Teamentwickler sollten hier genau hinschauen, bevor sie ein Urteil fällen.

Fazit

Echte Teamarbeit zeichnet sich durch eine gemeinsame Ausrichtung und einen hohen Grad an erforderlicher Abstimmung aus. Erfordert der Auftrag, der ans Team gerichtet ist, gar keine Zusammenarbeit zwischen den Teammitgliedern, besteht keine Notwendigkeit für häufige Abstimmungsmeetings, wie sie typischerweise in agilen Umfeldern stattfinden.

1.2 Ich soll das Team entwickeln. Was bedeutet das?

Gedanken eines Teamentwicklers: Teamentwicklung klingt erst mal schön und gut. Aber was heißt das eigentlich? Bezieht sich das immer auf die weniger greifbaren weichen Faktoren wie Wertschätzung und Kommunikation? Oder stehen eigentlich wirtschaftliche Aspekte wie die Geschwindigkeit des Teams im Vordergrund? Schließlich werde ich vom Unternehmen bezahlt. Auch die Erwartungen an mich scheinen sich zu unterscheiden: Für die einen bin ich ein Experte für agile Arbeit. Demnach soll ich dem Team Praktiken beibringen und dafür sorgen, dass sie richtig angewendet werden. Andere betrachten mich als Coach, der die richtigen Fragen stellt, um das Team in die gemeinsame Reflexion zu bringen. Was ist denn nun meine Aufgabe als Teamentwickler?

Unter Teamentwicklung verstehe ich alle bewusst eingesetzten Maßnahmen, die darauf abzielen, durch eine bessere Zusammenarbeit der Teammitglieder die Leistungsfähigkeit eines Teams zu steigern. Die Leistungsfähigkeit eines Teams kann sehr unterschiedliche Aspekte umfassen und ist daher im jeweiligen Anwendungskontext zu definieren: Das Forschungsteam soll schneller zu gemeinsamen Entscheidungen gelangen, das Softwareentwicklungsteam soll ihren Kunden weniger Softwarefehler zumuten, und das Marketingteam möchte besser aus gegenseitigem Feedback lernen. Der gemeinsame Nenner besteht darin, dass die verbesserte Teamleistung immer auf die Zusammenarbeit der Teammitglieder zurückzuführen ist. Manchmal zielen Teamentwicklungsmaßnahmen direkt auf die kommunikativen und zwischenmenschlichen Aspekte besserer Zusammenarbeit (z. B. Feedbackkultur) ab, und manchmal stehen sachlichere Ziele (z. B. weniger Softwarefehler) im Vordergrund. Wenn Teams ein Vieraugenprinzip und gemeinsame Testpraktiken einführen, um die Anzahl der Fehler zu verringern, ist das eine Teamentwicklungsmaßnahme, weil sie die Zusammenarbeit der Teammitglieder betrifft.

Teamentwicklungsaufträge lassen sich in zwei Arten untergliedern (Abb. 1), die sich systematisch voneinander unterscheiden: temporäre und dauerhafte Teamentwicklungsaufträge. Unter temporärer Teamentwicklung verstehe ich zeitlich begrenzte Teamentwicklungsaufträge, die sich auf ein bestimmtes Anliegen beziehen. Ob ich dabei eher in einer moderierenden, reflexionsanregenden oder beratenden Rolle angefragt werde, ist hier zweitrangig. Beispiele für temporäre Teamentwicklungsanfragen:

»Wir haben immer wieder Reibungen im Team darüber, wer welche Aufgaben übernimmt. Wir brauchen dich da einmal als neutralen Moderator.«

»Wir sind, wie alle anderen Teams auch, neuerdings gezwungen im Dreiwochentakt zu planen. Aber bisher ist das Planungsmeeting wahnsinnig anstrengend. Kannst du den Termin mal eine Zeitlang begleiten und mit uns verbessern?«

»Unsere Fehlerquote hat sich in den letzten Jahren verdoppelt, und wir wissen nicht warum. Kannst du da einmal mit uns draufschauen? Du kennst ähnliche Situationen doch aus anderen Teams.«

Im Gegensatz zur temporären Teamentwicklung ist dauerhafte Teamentwicklung auf einen deutlich längeren Zeitraum angelegt. Zudem hat dauerhafte Teamentwicklung in der Regel keinen spezifischen Anlass. Ich spreche beispielsweise von dauerhafter Teamentwicklung, wenn ein Scrum Master oder eine Teamleiterin einen grundsätzlichen und damit zeitlich unbegrenzten Teamentwicklungsauftrag innehat. Worin sich das Team genau entwickeln soll, wird bei einem dauerhaften Teamentwicklungsauftrag in der Regel offengelassen oder sehr global formuliert (z. B.: »Das Team soll agil werden«). Der dauerhafte Teamentwickler identifiziert zusammen mit dem Team immer wieder neue Entwicklungspotenziale, an denen dann gemeinsam gearbeitet wird.

Dauerhafte Teamentwickler haben neben ihrem Teamentwicklungsauftrag oft noch andere Aufgaben im selben Team. So unterstützt die Scrum Masterin das Team beispielsweise bei der Beseitigung von Hindernissen, die von der Arbeit abhalten, und der klassische Teamleiter führt Gespräche mit Bewerbern, um offene Stellen zu besetzen.

Abb.

1

: Temporäre und dauerhafte Teamentwicklung

Die meisten Herausforderungen, die in diesem Buch beschrieben werden, sind sowohl für temporäre als auch für dauerhafte Teamentwickler relevant. Ist das nicht der Fall, verwende ich bewusst die begriffliche Unterscheidung. Dann spreche ich entweder vom temporären oder vom dauerhaften Teamentwickler.

Teamentwickler versuchen über die Gestaltung der Zusammenarbeit Einfluss auf die Leistungsfähigkeit eines Teams zu nehmen. Die konkreten Aufgaben können dabei sehr unterschiedlich aussehen. Typische Tätigkeiten eines Teamentwicklers sind:

Prozessbegleitung und Moderation:

Prozessbegleiter gehen davon aus, dass die Teammitglieder selbst die Experten für die Herausforderungen des Teams sind. Teamentwickler sind in der Rolle des Prozessbegleiters also nicht Experte für die Inhalte, sondern für die Gestaltung methodischer Prozesse, die die Teammitglieder in eine zielführende gemeinsame Reflexion bringen. Prozessbegleiter stellen zur richtigen Zeit die richtigen Fragen und wählen passende Vorgehensweisen und Methoden (Warm-ups, Kreativitätstechniken, Stimmungsbilder, Entscheidungsverfahren, …) aus. Sie wissen, wann es Einzelgespräche, wann es anonyme Abfragen, wann es kleinschrittige Termine und wann es ganztägige Workshops braucht. Moderatoren sorgen dann für einen strukturierten Ablauf einer Veranstaltung und eine reibungslose Anwendung der gewählten Methoden.

Beratung

(zu zusammenarbeitsrelevanten Themen): Teamentwickler sind dann beispielsweise Ansprechpartner für die Wahl des passenden Teamframeworks (Scrum? Kanban?) oder das Aufsetzen geeigneter Teamprozesse. Sie analysieren Situationen (z. B.: Inwieweit ist Scrum hier anwendbar?), weisen auf Vor- und Nachteile hin und geben Empfehlungen ab. Der beratende Teamentwickler kennt die Theorie und weiß, wie typische Probleme in anderen Teams gelöst wurden, und kann daher wertvolle Hinweise und Anregungen geben.

Konfliktklärung:

Manchmal ist man als Teamentwickler auch in der Rolle des Mediators gefragt. Wenn die Zusammenarbeit eines Teams gestört ist, gilt es die Wogen zu glätten. Konflikte belasten ein Team oft ungemein. Um die Arbeitsfähigkeit wiederherzustellen, können Teamentwickler eine Konfliktklärung moderieren. Wenn Teamentwickler sehr nah am Team sind, fehlt ihnen möglicherweise die notwendige Neutralität, um als Mediator zu agieren. Das bedeutet aber nicht, dass sie dann nichts tun können. Dauerhafte Teamentwickler, die das Team schon seit Monaten unterstützen, könnten in dem Fall die Aufgabe übernehmen, eine Konfliktklärung mit einem externen Mediator zu initiieren (

Kap. 7.5

).

Training:

Trainer vermitteln Inhalte ans Team und üben neue Praktiken (z. B. Feedbacktechniken) mit ihnen ein. Je nach Tätigkeitsfeld des Teams können auch spezifischere Inhalte vermittelt werden. So lassen sich im IT-Umfeld beispielsweise Praktiken wie Pair oder Mob Programming schulen. (Mehrere Softwareentwickler programmieren zusammen vor demselben Bildschirm.) Wer als Trainer auftritt, sollte natürlich die entsprechende Expertise mitbringen.

Beobachtung und Feedback:

Teamentwicklern fallen immer wieder Dinge im Team auf, die sie dem Team zurückmelden können. (»Wenn Marius nicht da ist, schaut niemand auf das Betriebsdashboard. Kann das sein?«) Wer Teams länger begleitet, wird viele Beobachtungen machen können und sollte in der Lage sein, auch kritische Dinge zurückzumelden. (»Ich erlebe euch im Umgang mit den anderen Teams als überheblich« oder »Die Daten zeigen, dass ihr euch in den letzten fünf Planungszyklen überschätzt habt. Wieso glaubt ihr, es diesmal zu schaffen?«)

Abhängig von den individuellen Fähigkeiten, Überzeugungen und Präferenzen wird die Rolle des Teamentwicklers sehr unterschiedlich gelebt. Während die Scrum-Expertin bevorzugt inhaltlich berät, nimmt der ausgebildete Mediator die zwischenmenschlichen Herausforderungen ins Visier. Im besten Fall passen die Kompetenzen des Teamentwicklers zur Situation des Teams.

Auch die hierarchische Position des Teamentwicklers beeinflusst die Handlungsmöglichkeiten. Disziplinarische Führungskräfte, die ihr Team weiterentwickeln wollen, haben es vermeintlich leichter, Reflexionsräume zu schaffen (»Wir überlegen heute mal, wie wir die Übergaben besser hinbekommen«) und können ggf. schneller Entscheidungen für konkrete Maßnahmen herbeiführen (»Ich finde Peters Idee gut; lasst uns das doch mal ausprobieren«). Gleichzeitig werden sie aber vermutlich nicht als neutraler Mediator wahrgenommen, wenn sie inhaltlich für das umstrittene Thema verantwortlich sind. Wer über Gehalt, Aufstiegschancen, Arbeitsbedingungen etc. entscheidet, muss zudem damit rechnen, durch die eigene Anwesenheit die Diskussion zu beeinflussen (Was will die Chefin wohl hören?).

Fazit

Wer als Teamentwickler arbeitet, wird damit leben müssen, dass ihm der Begriff »Teamentwicklung« nur wenig Klarheit darüber liefert, was er zu tun hat. Trotz des übergeordneten Ziels, die Leistungsfähigkeit des Teams durch eine verbesserte Zusammenarbeit zu erhöhen, können die spezifischen Tätigkeiten des Teamentwicklers abhängig von seinem Auftrag, seiner spezifischen Position (temporärer Coach, dauerhaft eingesetzter Scrum Master, disziplinarischer Teamleiter …), seinen Kompetenzen und der Situation des Teams sehr unterschiedlich sein.

1.3 Die Organisation als Umwelt des Teams: Freundin oder Feindin?

Gedanken eines Teamentwicklers: Der Zusammenhalt im Team ist stark, die teaminternen Absprachen laufen gut, und alle hängen sich rein. Aber eine Sache macht mir Sorgen: Das Team schottet sich zunehmend vom Rest der Organisation ab. Die Zusammenarbeit mit anderen Teams wird, wenn irgend möglich, vermieden. Vorgaben des Managements werden als übergriffig empfunden, und generell ist der Blick auf umliegende Teams und Abteilungen ziemlich kritisch. Ich bin unsicher: Soll ich das Team von außen abschirmen, damit es in Ruhe arbeiten kann? Oder wäre es mein Job, das Team milder und vor allem der Organisation gegenüber kooperativer zu stimmen?

Wenn sich Organisationseinheiten (Teams, Abteilungen, …) nach außen abschirmen, die übergreifende Kommunikation mit anderen Organisationseinheiten meiden und sich einseitig auf die eigenen Ziele fokussieren, steht schnell der Vorwurf des »Silodenkens« im Raum. Ein Punkt wird dabei allerdings oft vergessen: Ein zentraler Vorteil von Organisationen besteht genau darin, dass nicht jeder ständig mit jedem kommunizieren muss. Organisationen teilen Arbeit in verschiedene Teilaufgaben auf, die dann von unterschiedlichen Organisationseinheiten (z. B. Teams) möglichst autonom erledigt werden. Das Marketingteam kümmert sich ums Marketing und muss sich nicht auch noch mit der Produktion der zu vertreibenden Waren oder dem Rechnungswesen auseinandersetzen. Die Komplexität für die jeweiligen Einheiten bleibt dadurch handhabbar (Kieser u. Walgenbach 2010, S. 38), und diese können einigermaßen unabhängig agieren.

Wenn sich vor diesem Hintergrund ein Team ständig mit anderen Teams oder Abteilungen abstimmt, ist das nicht zwangsläufig ein Zeichen für Kooperationsfähigkeit. Bei hohen Abstimmungsaufwänden sollten Teamentwickler skeptisch werden. Möglicherweise bremst eine ungünstige Aufteilung der Teamverantwortlichkeiten unnötig aus (»Wenn wir selbst Stellenanzeigen schalten dürften, wären wir viel schneller …«). Vielleicht fehlen Kompetenzen im eigenen Team (»Wenn wir jemanden hätten, der sich mit Arbeitsverträgen auskennt, müssten wir uns nicht ständig mit der Rechtsabteilung abstimmen …«). Es kann also angebracht sein, als Teamentwickler nach Möglichkeiten zu suchen, die Abstimmungsbedarfe zu anderen Teams (oder Abteilungen) zu reduzieren, um damit die Abhängigkeit des Teams von der umgebenden Organisation bewusst zu verringern.

Gleichwohl lassen sich Organisationen nicht so strukturieren, dass die einzelnen Organisationseinheiten völlig autonom agieren können. Organisationen verfolgen Zwecke, die nur durch die Koordination mehrerer Organisationseinheiten erreichbar sind. Die Aktivitäten verschiedener Teams und Abteilungen müssen aufeinander abgestimmt sein. Um das sicherzustellen, schaffen Organisationen formale Strukturen. Mit anderen Worten: Sie treffen Entscheidungen, die dauerhafte Auswirkungen auf das Geschehen in der Organisation haben (Kühl u. Muster 2016, S. 10):

Sie benennen Ziele und Strategien

. Beispiel: Die Strategie, in Zukunft maßgeschneiderte Einzelanfertigungen zu produzieren, wird sich sowohl aufs Marketing als auch auf den Vertrieb auswirken.

Sie geben den Teams und Abteilungen Regeln vor

. Beispiel: Alle Softwareentwicklungsteams entwickeln mit denselben Programmiersprachen, damit die verschiedenen Softwarebestandteile am Ende gut aneinandergefügt werden können.

Sie bestimmen Kommunikationswege

. Beispiel: Es werden Meetings zur team- oder abteilungsübergreifenden Abstimmung anberaumt oder einzelnen Rollen Koordinationsaufgaben zugewiesen.

Natürlich könnte jede Vorgabe einer Organisation im Einzelfall hinterfragt werden (Hilft sie der Organisation wirklich? Ist das notwendig? …). Ein Zuviel an Vorgaben kann ein Team lähmen, und unpassende Regeln schaden am Ende mehr, als dass sie nützen. Mir geht es an dieser Stelle aber um einen anderen Punkt: Organisationen sind nicht einfach als Hülle für eine Vielzahl von unverbundenen Teams und Abteilungen zu betrachten. Als hierarchisch übergeordnete Ebene zeichnet sich die Organisation gerade durch die formalen Strukturen aus, die das Zusammenspiel der verschiedenen Organisationseinheiten maßgeblich beeinflussen. Eine geschickte Gestaltung ihrer formalen Strukturen ist entscheidend für den Erfolg einer Organisation und, wie sich im weiteren Verlauf des Buches an vielen Stellen zeigen wird, auch in hohem Maße bedeutend für die Arbeit im Team.

Teamentwickler sollten die formalen Strukturen der Organisation daher nicht grundsätzlich verteufeln, auch wenn sie die Autonomie des Teams einschränken. Das tun formale Strukturen nämlich: Ein Team, das mit Java programmieren muss, darf keine (vielleicht viel spannendere) andere Programmiersprache wählen. Und wer Entscheidungen immer mit anderen Organisationseinheiten abstimmen muss, ist in der eigenen Entscheidungshoheit eingeschränkt. Daher verwundert es nicht, dass Teams, die den Anspruch haben, möglichst eigenverantwortlich zu agieren, der umliegenden Organisation oft ablehnend gegenüberstehen. Das lässt sich nicht immer verhindern. Oft wirkt es aber mildernd, wenn Teams die Hintergründe und Funktionen organisationaler Vorgaben (Ziele, Regeln, Termine …) verstehen.

Fazit

Die Organisation mit ihren vorgegebenen Regeln, Zielen und Kommunikationswegen (= formale Strukturen) sollte vom Teamentwickler, und bestenfalls auch vom Team, nicht als Feindin betrachtet werden. Sondern als notwendige und in Hinblick auf die Abstimmung des Gesamtunternehmens sinnvolle Umwelt des Teams. Am Ende geht es stets um beides: Autonomie auf der einen Seite ermöglicht den Teams, fokussiert und eigenverantwortlich zu handeln. Auf der anderen Seite braucht es immer autonomiebegrenzende Vorgaben der Organisation, um die verschiedene Organisationseinheiten auf die gemeinsamen Zwecke der Organisation ausrichten.

2 Die passende Haltung des Teamentwicklers

Teamentwickler begegnen den Teams, mit denen sie arbeiten, aus einer bestimmten Haltung heraus. Die Haltung setzt sich aus Einstellungen und Grundannahmen über Teams, Menschen und der eigenen Rolle als Teamentwickler zusammen und beeinflusst das eigene Handeln maßgeblich: Wer beispielsweise bis ins Knochenmark davon überzeugt ist, dass Teams alles, was sie für eine gute Lösung brauchen, bereits in sich tragen, wird fragend und reflexionsanregend agieren. Wer davon ausgeht, dass die Leistung des Teams maßgeblich von den Mindsets der Teammitglieder abhängt, wird seinen Job als Teamentwickler möglicherweise darin sehen, Werte zu vermitteln. Und wer Mitarbeiter (oder Menschen generell) für träge und veränderungsresistent hält, wird Widerständen vermutlich mit Nachdruck begegnen.

In diesem Kapitel reflektieren wir Fragestellungen, die sich, je nachdem wie man sie für sich beantwortet, in hohem Maße auf die eigene Arbeit als Teamentwickler auswirken. Wir klären, inwieweit die Teammitglieder selbst (Kap. 2.1) oder andere Teamaspekte (Kap. 2.2) zu verändern sind. Wir fragen uns, wie direktiv Teamentwickler auftreten sollten (Kap. 2.3), und reflektieren, inwieweit das Team selbst gemäß dem Credo »Hilfe zur Selbsthilfe« nach Lösungen suchen sollte (Kap. 2.4). Abschließend beschäftigen wir uns mit der Frage, ob Teamentwickler bei Konflikten auf der Seite des Teams, auf der Seite der Organisation oder zwischen beiden stehen (Kap. 2.5).

2.1 Ist es mein Job, die Teammitglieder beziehungsweise deren Mindset zu verändern?

Gedanken eines Teamentwicklers: Puh, wenn die Leute doch nur ein bisschen offener für Veränderungen wären! Wann immer jemand eine Idee äußert, folgen drei Einwände. Anstatt nach Lösungen zu suchen, wird nach Gründen gesucht, warum etwas nicht geht. Die Leute brauchen das richtige Mindset, heißt es oft. Und auch ich wünschte mir, dass mein Team nur aus motivierten, veränderungsbegrüßenden Teammitgliedern bestünde. Aber das ist nicht so. Ist es nun mein Job als Teamentwickler, den Teammitgliedern ein anderes Mindset beizubringen? Wie soll das gehen?

Aus Sicht der Organisation macht sich Teamentwicklung am Ende dadurch bemerkbar, dass Dinge anders getan