Agile Leadership - Sandra Sieroux - E-Book

Agile Leadership E-Book

Sandra Sieroux

0,0
34,90 €

-100%
Sammeln Sie Punkte in unserem Gutscheinprogramm und kaufen Sie E-Books und Hörbücher mit bis zu 100% Rabatt.
Mehr erfahren.
Beschreibung

Das Handwerkszeug für die agile Führungskraft - Gestalten Sie den Wandel Ihrer Organisation aktiv mit Agile Leadership - Lernen Sie die Konzepte und Werkzeuge für eine effektive Agile Leadership kennen -  Mit zahlreichen Fallbeispielen aus der Praxis   Eine agile Organisation entsteht nicht allein durch eine Ansammlung agiler Teams. Genauso wenig entstehen erfolgreiche agile Teams nur durch das Befolgen der Scrum-Regeln. Unternehmen wollen sich strukturell und kulturell weiterentwickeln, um ihre Kunden und Mitarbeiter begeistern zu können. Dieses Buch gibt einen fundierten, praxisorientierten Überblick, wie dieser Wandel mittels Agile Leadership gestaltet werden kann. Dabei werden Konzepte aufgezeigt wie - Agile Descaling Cycle - The Responsibility Process™ - Power- oder Control-Modell - Leadership Circle Profile® - Mutual Learning Model - Collective Leadership Assessment - Teamstrukturen: statische vs. fluide - Engpass-Optimierung im Großen   Diese Konzepte stellen einen Werkzeugkasten an Methoden dar, aus dem sich der Agile Leader bedienen kann, um den individuellen Wandel seiner Organisation zu begleiten. Die 2. Auflage wurde in einigen Aspekten überarbeitet und um die Themen »übergreifende Flow-Optimierung« und »fluide Teams« sowie die Arbeit mit einzelnen Teammitgliedern (Coaching, Mentoring) ergänzt.

Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:

EPUB
MOBI

Seitenzahl: 383

Veröffentlichungsjahr: 2025

Bewertungen
0,0
0
0
0
0
0
Mehr Informationen
Mehr Informationen
Legimi prüft nicht, ob Rezensionen von Nutzern stammen, die den betreffenden Titel tatsächlich gekauft oder gelesen/gehört haben. Wir entfernen aber gefälschte Rezensionen.



Sandra Sieroux ist seit 2010 agile Beraterin bei it-agile. Ende der 90er wurde sie während ihres Mathematikstudiums mit dem »agilen Virus« infiziert. Seither hat sie begeistert in zahlreichen kleinen und großen Projekten agile Entwicklungspraktiken und -werte gelebt und weitergetragen. Heute liegt ihr Hauptaugenmerk auf agiler Organisationsentwicklung.

Stefan Roock ist Gründungsmitglied der it-agile GmbH. Ihm ist es in seiner Beratungstätigkeit wichtig, dass sich wirklich etwas ändert – hin zu erfolgreichen Unternehmen mit zufriedenen Mitarbeitern, die sich immer neuen Herausforderungen stellen. Stefan hat seit 1999 die Verbreitung agiler Ansätze in Deutschland maßgeblich mit beeinflusst. Er ist regelmäßiger Sprecher zu agilen Themen auf Konferenzen, schreibt Zeitschriftenartikel und hat mehrere Bücher veröffentlicht.

Dipl.-Inform. Henning Wolf ist Mitgründer der it-agile GmbH, für die er bis 2023 als Geschäftsführer, Berater, Trainer und Coach tätig war. 2019 hat er parallel dazu selbstfuehren.de mitgegründet, ein auf Selbstführung rund um The Responsbility Process® spezialisiertes Beratungsunternehmen. Er verfügt über mehr als 20 Jahre Erfahrung mit agilen Methoden und hat diese in diversen Artikeln, Büchern und Konferenzbeiträgen verarbeitet. Er versteht sich als Leadermacher, schult und berät zu agilen Methoden und vor allem der damit verbundenen (Selbst-)Leadership.

Copyright und Urheberrechte:Die durch die dpunkt.verlag GmbH vertriebenen digitalen Inhalte sind urheberrechtlich geschützt. Der Nutzer verpflichtet sich, die Urheberrechte anzuerkennen und einzuhalten. Es werden keine Urheber-, Nutzungs- und sonstigen Schutzrechte an den Inhalten auf den Nutzer übertragen. Der Nutzer ist nur berechtigt, den abgerufenen Inhalt zu eigenen Zwecken zu nutzen. Er ist nicht berechtigt, den Inhalt im Internet, in Intranets, in Extranets oder sonst wie Dritten zur Verwertung zur Verfügung zu stellen. Eine öffentliche Wiedergabe oder sonstige Weiterveröffentlichung und eine gewerbliche Vervielfältigung der Inhalte wird ausdrücklich ausgeschlossen. Der Nutzer darf Urheberrechtsvermerke, Markenzeichen und andere Rechtsvorbehalte im abgerufenen Inhalt nicht entfernen.

Sandra Sieroux · Stefan Roock · Henning Wolf

Agile Leadership

Führungsmodelle, Führungsstile und das richtige Handwerkszeug für die agile Arbeitswelt

2., überarbeitete und erweiterte Auflage

Sandra Sieroux

[email protected]

Stefan Roock

[email protected]

Henning Wolf

[email protected]

Lektorat: Christa Preisendanz

Buchmanagement: Julia Griebel

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz: III-satz, www.drei-satz.de

Herstellung: Stefanie Weidner, Frank Heidt

Umschlaggestaltung: Eva Hepper, Silke Braun

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.

ISBN:

 

Print

978-3-98889-029-0

PDF

978-3-98890-217-7

ePub

978-3-98890-218-4

2., überarbeitete und erweiterte Auflage

Copyright © 2025 dpunkt.verlag GmbH

Wieblinger Weg 17 · 69123 Heidelberg

E-Mail: [email protected]

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Weiter darf der Inhalt nicht zur Entwicklung, zum Training oder zur Anreicherung von KI-Systemen, insbesondere generativen KI-Systemen, verwendet werden. Die Nutzung für Text- und Data Mining ist untersagt.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor*innen noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

Inhaltsübersicht

1Agile Leadership – Motivation und Kontext

Teil ISelbst-Leadership

2Warum Selbst-Leadership so wichtig ist

3The Responsibility Process™

4Glaubenssätze

5Feedback, Fehler, Transparenz

6Vertrauen

7Problemlösungsstrategien: Power- oder Control-Modell

8Selbstentwicklung mit dem Leadership Circle Profile®

9Individuallernen

Teil IIAgile Leadership im Team

10Was ist ein Team?

11Kulturelle Interventionen

12Hochleistungsteams

13Perspektiven integrieren

14Gruppenlernen mit dem Power-Cycle

Teil IIIAgile Leadership in der Organisation

15Feedbackschleifen

16Hierarchische Unternehmensorganisation

17Unternehmenssteuerung und agile Vorgehensweisen

18Teams in der Hierarchie

19Unternehmen agil(er) organisieren

20Menschliches Verhalten im Unternehmen

Teil IVAgile Leadership für gemeinsames Lernen

21Organisationslernen

22Unschärfe als Lernmöglichkeit

23Iterative Organisationsentwicklung mit Experimenten

Anhang

Referenzen

Index

Inhalt

1Agile Leadership – Motivation und Kontext

1.1Für wen ist dieses Buch

1.2Warum wir dieses Buch geschrieben haben

1.3Änderungen zur vorigen Auflage

1.4Agile Leadership ist Leadership

1.5Was wir unter Agilität verstehen

1.6Kontext für Agilität

1.6.1Warum diese Unterscheidung so wichtig ist

1.6.2Wie agile Teams blaue und rote Arbeit adressieren

1.7Agile Organisationen

1.8Unser Modell: Kultur, Struktur, Leadership

1.9Überblick über das Buch

1.10Danksagung

Teil ISelbst-Leadership

2Warum Selbst-Leadership so wichtig ist

3The Responsibility Process™

3.1Die mentalen Zustände

3.2Führe dich selbst zuerst

3.3Die drei Schlüssel zur Verantwortung

3.4Das Mensch-erwisch-dich-früher-Spiel

3.5Den Responsibility Process nicht auf andere anwenden

3.6Aber die anderen übernehmen einfach keine Verantwortung

4Glaubenssätze

4.1Weniger nützliche Glaubenssätze entdecken

4.2Glaubenssätze überschreiben

4.3Spezialfall Zuschreibung

5Feedback, Fehler, Transparenz

5.1Feedback annehmen

5.2Feedback geben

5.3Fehler machen, zu ihnen stehen und aus ihnen lernen

5.4Transparenz

5.5Authentizität

6Vertrauen

6.1Die Vertrauensgleichung

6.1.1Glaubwürdigkeit

6.1.2Zuverlässigkeit

6.1.3Nähe/Vertrautheit

6.1.4Eigennutz/Selbstsucht

6.2Individuelle Anwendung der Vertrauensgleichung

6.3Anwendung der Vertrauensgleichung gemeinsam mit anderen

7Problemlösungsstrategien: Power- oder Control-Modell

8Selbstentwicklung mit dem Leadership Circle Profile®

8.1Führung zwischen Aufgaben und Beziehungen

8.1.1Klarheit schaffen: Aufgaben (Tasks)

8.1.2Zusammenarbeit fördern: Beziehungen (Relationship)

8.2Persönlichkeitsentwicklung

8.2.1Egozentrisch: »Ich bin, was ich will und brauche.«

8.2.2Reaktiv: »Ich bin, was ich tue, um wertvoll und sicher zu sein.«

8.2.3Kreativ: »Ich bin, wie ich meine Werte und Vision bewusst in die Welt bringe.«

8.2.4Integral: »Ich bin, was wir in Verbindung gemeinsam bewirken.«

8.2.5Unitive: »Ich bin alles und formlos – untrennbar mit allem verbunden.«

8.3Von reaktiv zu kreativ: eine Entwicklungsreise

8.3.1Die drei Strategien reaktiver Führung

8.3.2Die Falle der Übertreibung: Wie Stärken uns limitieren

8.3.3Die Transformation: von reaktiv zu kreativ

8.3.4Praxisübungen zur Transformation: von reaktiv zu kreativ

8.3.5Balance zwischen Aufgabe und Beziehung

8.3.6Leadership Circle Profile®: ein Werkzeug für vertiefte Leadership-Reflexion

9Individuallernen

9.1Leadership-Entwicklung und Organisationslernen

9.2Leadership-Entwicklung bedeutet Arbeit an Glaubenssätzen

9.3Der Weg zur Verhaltensänderung

9.4Personal Coaching für Leadership-Entwicklung

Teil IIAgile Leadership im Team

10Was ist ein Team?

10.1Gemeinsames Ziel

10.2Gegenseitige Abhängigkeit

11Kulturelle Interventionen

11.1Gezielte Interventionen

12Hochleistungsteams

12.1Flow

12.1.1In den Flow kommen

12.1.2Flow und Motivation/Meisterschaft

12.2Motivation

12.2.1Autonomie

12.2.2Meisterschaft

12.2.3Zweck

12.3Resonanz

12.3.1Resonanz als Schlüssel für Tiefe

12.3.2Resonanz und Führung: Raum für echte Zusammenarbeit schaffen

12.3.3Resonanz durch individuelle Gespräche fördern: das Resonanzgespräch

12.4Wirkungsvolle Agilität im Team

12.4.1Gruppendruck nutzen und fördern

12.4.2Ergebnis-Accountability herstellen

12.4.3Einfache Regeln etablieren

12.4.4Coaching/Mentoring etablieren

13Perspektiven integrieren

13.1Voneinander lernen, statt recht haben

13.1.1Hilfreiche Grundannahmen

13.1.2Hilfreiche Verhaltensweisen und Grundregeln

13.2Entscheidungen treffen

13.2.1Konsent

13.2.2Systemisches Konsensieren

13.2.3Fist of Five

13.2.4Advice-Prozess (konsultativer Einzelentscheid)

13.3Psychologische Sicherheit

13.3.1Die Bühne bereiten

13.3.2Produktiv auf Äußerungen reagieren

14Gruppenlernen mit dem Power-Cycle

14.1Häufige Missverständnisse zum Power- oder Control-Modell

14.1.1Missverständnis: Erforschen ist passiv

14.1.2Missverständnis: Control-Cycle ist Zwang, Power-Cycle ist Harmonie

14.1.3Missverständnis: Power-Cycle oder Control-Cycle werden in Stunden oder Tagen durchlaufen

14.2Power-Cycle braucht Leadership

14.2.1Gruppentechniken für den Power-Cycle

14.3Leadership braucht Power-Cycle

Teil IIIAgile Leadership in der Organisation

15Feedbackschleifen

15.1Feedbackschleifen bei Command & Control-Strukturen

15.2Feedbackschleifen bewerten

15.3Feedbackschleifen installieren

16Hierarchische Unternehmensorganisation

16.1Hierarchische Zielsysteme

16.2Typische Dysfunktionen

16.3Verbreitete hierarchische Zielsysteme

16.3.1Management by Objectives (MbO)

16.3.2Objectives and Key Results (OKR)

16.3.3Hoshin Kanri

16.3.4Theorie und Praxis der Führung durch Ziele

17Unternehmenssteuerung und agile Vorgehensweisen

17.1Marktdialog

17.2Fokus

17.3Ziele und Strukturen

17.4Handeln aus Verantwortung

17.5Globale Optimierung

17.6Kooperation

17.7Kreative Führung mit Zielen

17.8(Disziplinarische) Führung in hierarchischen Systemen

17.8.1Ziele und Rahmen setzen

17.8.2Skill-Manager

17.8.3Arbeiten am System

18Teams in der Hierarchie

18.1Führungsteams

18.2Kanban für Führungsteams

18.3Arbeiten am System (vs. Arbeiten im System)

18.3.1Leadership im und am System

19Unternehmen agil(er) organisieren

19.1Agile Descaling Cycle

19.2Koordinieren: Umgang mit Abhängigkeiten

19.2.1Probleme der Etappenplanung

19.2.2Etappen verkürzen

19.2.3Etappen abschaffen

19.2.4Technische Fähigkeiten der Teams

19.3Minimierung von Abhängigkeiten

19.3.1Statische Teams

19.3.2Mobile Teams

19.3.3Mission Teams

19.3.4Floating Teams

19.4Zellorganisation nach BetaCodex

19.5Reverse Accountability

19.6Soziokratie

19.6.1S3 für existierende Unternehmensstrukturen

19.7Purpose: Führen ohne hierarchische Zielsysteme

19.8Leadership in agilen Organisationen

19.9Organisationsstrukturen und Leadership

20Menschliches Verhalten im Unternehmen

20.1Unternehmen als Maschinen

20.2Unternehmen als Organismen

20.3Unternehmen als soziale Systeme

20.4Unternehmenskultur

20.5Einfluss von Führung

20.6Collective Leadership Assessment

20.6.1Das Profil im Detail

20.6.2Konkrete Maßnahmen

20.7Kultur verändern

Teil IVAgile Leadership für gemeinsames Lernen

21Organisationslernen

21.1Individuelles Lernen

21.2Relevantes Wissen

21.3Die Haltung beim Unternehmenslernen

21.4Leadership-Reife begrenzt Organisationslernen

22Unschärfe als Lernmöglichkeit

22.1Beispiel: Die Scrum-Verantwortlichkeiten

22.2Not My Job

22.3Anreize für dysfunktionales Verhalten

22.4Überlappende Verantwortlichkeiten

22.5Eine neue Perspektive auf Verantwortung

22.6Verantwortung über einzelne Teams hinaus

22.7Leadership und Rollenabgrenzungen

23Iterative Organisationsentwicklung mit Experimenten

23.1Organische Strukturanpassungen

23.1.1Der PDCA-Zyklus

23.1.2PDCA und Unternehmenslernen

23.1.3PDCA in der Praxis

23.1.4Organisationslernen als Abfolge von Experimenten

23.1.5Safe-to-Fail-Experimente

23.1.6Fail-Fast

23.1.7Experimente erleichtern die Veränderung

23.1.8Die A3-Technik

23.2Systemintelligenz: Wie sehr Organisationen das Verhalten ihrer Mitarbeiter beeinflussen

23.2.1Systemintelligentes Verhalten und Leadership

Anhang

Referenzen

Index

1Agile Leadership – Motivation und Kontext

Wann hat sich Ihr Unternehmen zuletzt merklich verändert? Wurde die gewünschte Wirkung erzielt? Müsste sich Ihr Unternehmen, wenn man sich die Marktdynamik ansieht, schneller verändern?

Um dauerhaft am Markt erfolgreich zu sein, muss das Unternehmen den aktuellen Markt bedienen und sich mit Innovationen für die Zukunft vorsorgen (siehe [Drucker 2006]). Gary Hamel differenziert Innovation weiter in Produktinnovation und Managementinnovation. Unternehmen müssen ständig neue, bessere Produkte und Services entwickeln, um die Kundenbedürfnisse immer besser zu adressieren. Darüber hinaus müssen Unternehmen auch Innovationen ins Management bringen, um insgesamt flexiblere Unternehmen zu schaffen (siehe [Hamel 2007]). Das Thema Produktinnovation, eingebettet in einen agilen Unternehmenskontext, adressieren Jürgen Hoffmann und Stefan Roock in [Hoffmann & Roock 2018]. Das vorliegende Buch fokussiert auf die Managementinnovationen.

Wir Autoren arbeiten seit mehr als 25 Jahren mit agilen Arbeitsweisen. Wir haben damit begonnen, in einzelnen Teams agil Software zu entwickeln. Später haben wir Produkte mit mehreren Teams entwickelt und schließlich kleine wie große Unternehmen in eine agile Welt geführt. Nicht zuletzt haben wir die it-agile GmbH zu einem agilen Unternehmen entwickelt.

Bei all dieser Arbeit haben wir festgestellt, dass agile Teamarbeit für Wissensarbeit sehr effektiv ist. Wir haben aber auch beobachtet, dass agiles Arbeiten zu sehr auf Entwicklungsteams eingeschränkt wird. In einem unserer Projekte haben wir von Managern dieses Zitat aufgeschnappt: »Wir beginnen in 2 Monaten mit Scrum. Bis dahin müssen wir noch die wichtigen Dinge ins Team pushen.« Darin zeigt sich wahlweise völliges Unverständnis über Agilität oder Ignoranz. Mit dieser Haltung wird es schon auf Teamebene sehr schwierig, irgendwelche Vorteile aus agilen Teams zu ziehen. Tatsächlich ist die Scrum-Einführung in dem Unternehmen relativ schnell gescheitert. Wir hatten seinerzeit den Fokus zu wenig auf die Führungskräfte gelegt. Agile Teams sind auch für Bereiche außerhalb der Entwicklung sinnvoll, insbesondere für die Führungsarbeit.

Damit Teamarbeit nicht zu »toll, ein anderer macht’s« verkommt, braucht es Leadership innerhalb des Teams. Damit einzelne Teams nicht nur sich selbst optimieren, sondern übergreifende Synergien gesehen und gehoben werden, braucht es Leadership für die Organisation. Damit die Teams nicht nur an eigenen Zielen arbeiten, sondern gemeinsam an den Zielen der Organisation, braucht es ebenfalls Leadership. Je mehr Teile einer Organisation agiler gestaltet werden, umso mehr bedarf es Leadership auf weiteren Ebenen als nur der Teamebene. Agile Leadership ist im Grunde moderne Leadership – Führungsarbeit, die in dynamischen Kontexten die Potenziale der Mitarbeitenden zur Entfaltung bringt und so zu begeisternden Produkten und Services und damit auch zu erfolgreichen Unternehmen beiträgt.

1.1Für wen ist dieses Buch

Wir haben dieses Buch für verschiedene Zielgruppen geschrieben:

Führungskräfte aus nicht agilen Organisationen können lernen, was es für das Unternehmen und die Rolle von Führungskräften bedeutet, wenn sich die Organisation auf den Weg in eine agilere Zukunft macht. So können Führungskräfte besser entscheiden, ob, wann und wie sie den Wandel angehen und gestalten wollen.

Führungskräfte aus Organisationen in der agilen Transition bekommen Anregungen, wie der Wandel besser gestaltet werden kann. Sie erhalten eine breite Perspektive auf das Themengebiet und bekommen dadurch mehr Handlungsoptionen. Sie können außerdem lernen, wie sie den Wandel mitgestalten können, auch wenn dieser von anderen gestartet wurde oder vermeintlich von anderen kontrolliert wird.

Führungskräfte aus bereits agilen Organisationen können lernen, wie sie ihr Unternehmen noch agiler gestalten können. Durch die reichhaltige Darstellung des Themenbereichs bekommen sie Anregungen und werden dadurch handlungsfähiger.

Agile Coaches (und Scrum Master) finden sich meist in einer unterstützenden und beratenden Rolle wieder. Die Konzepte in diesem Buch bereichern den Schatz an Modellen und Methoden, aus denen Agile Coaches sich während der Beratung bedienen können. Außerdem sind auch Agile Coaches Führungskräfte – in einem nicht klassischen Sinne. Die Ansätze zu Leadership und Leadership-Entwicklung sind auch in der Rolle des Agile Coach nützlich.

Die meisten Mitarbeiterinnen und Mitarbeiter verstehen sich nicht als Führungskräfte. In agilen Kontexten ist dieses (Selbst-)Verständnis toxisch. Nur wenn Führung auf allen Ebenen gelebt wird, stellt sich die Flexibilität ein, die Agilität verspricht. Mitarbeiter lernen in diesem Buch, wie auch sie ihre Leadership-Fähigkeiten erweitern und einsetzen können und wie sie insbesondere auch in ihrem Kontext den Wandel hin zu Agilität gestalten können.

Wir gliedern das Buch in vier Teile zu Selbst-Leadership, Agile Leadership im Team, Agile Leadership in der Organisation und Agile Leadership für gemeinsames Lernen. Gruppenleitern mag Leadership in der Organisation zunächst wie ein Fremdkörper erscheinen; über die Organisationsstrukturen entscheiden schließlich »die da oben«. Andersherum mag Leadership im Team auf den ersten Blick für Topmanager wenig relevant zu sein; wie konkret gearbeitet wird, entscheiden »die da unten«. Diese Sichtweise verkennt allerdings wichtige Eigenschaften agiler Organisationen.

Wenn Unternehmensagilität angestrebt wird, ist das Minimum, dass auch die Führungskräfte (bis hin zum Topmanagement) als Teamplayer agieren. Damit wird Leadership im Team auch für das Topmanagement relevant. Teamarbeit ist nicht mehr das, was »die da unten« machen, sondern etwas, was überall praktiziert wird.

Auf der anderen Seite brauchen agile Unternehmen ein Mindestmaß an struktureller Autonomie in den einzelnen Bereichen. Damit wird Leadership in der Organisation auch für Abteilungsleiterinnen bzw. Abteilungsleiter relevant, wenn diese entscheiden, wie sie ihre Abteilung intern strukturieren wollen.

Außerdem brauchen Entscheidungen über Organisationsstrukturen sowohl den strategischen Blick (in klassischen Unternehmen beim Topmanagement angesiedelt) wie auch den Blick auf die Arbeitsweise der Mitarbeiter. Fehlt der strategische Blick bei der Festlegung der Organisationsstrukturen, werden strategische Ziele schwer erreichbar. Fehlt der Blick aus der konkreten Arbeitsebene, besteht die Gefahr, eine Organisationsstruktur zu schaffen, die zwar theoretisch zur Strategie passt, in der die Mitarbeiter aber ihre Arbeit nicht erledigen können.

Gemeinsames Lernen ist ein Grundpfeiler von Agilität. Besonders relevant ist das Lernen, wenn die Umstände schwierig sind. Und gerade dann fällt uns das Lernen schwer. Wer unter totalem Stress steht, ist selten offen für neue Perspektiven und Einsichten. Es braucht Leadership, damit Lernen trotz schwieriger Umstände möglich wird. Nur dann können Unternehmen wirklich gestärkt aus Krisen hervorgehen.

Daher sind die vier genannten Teile dieses Buches relevant für alle, die im Unternehmen Leadership übernehmen.

Nicht alles in diesem Buch ist neu. Wir stehen auf den Schultern von Giganten, deren Konzepte wir in unser Gesamtkonzept von Agile Leadership integriert haben. Es ist daher gut möglich, dass Sie, liebe Leserin, lieber Leser, einzelne Konzepte dieses Buches bereits kennen. Sie können diese überspringen. Sie profitieren aber vermutlich mehr, wenn Sie die Ihnen bekannten Konzepte noch mal durch die Perspektive von Agile Leadership betrachten. So entdecken Sie vielleicht neue Aspekte der Konzepte.

1.2Warum wir dieses Buch geschrieben haben

Nun, uns liegen diese oben beschriebenen Zielgruppen am Herzen. Wir haben zudem auf unserer eigenen agilen Reise bemerkt, dass gerade das Thema Leadership mit all seinen Aspekten lange Zeit unterschätzt wurde – auch von uns. Trotzdem ist Leadership nicht alles, aber alle brauchen Leadership. Daher ist es wichtig, Leadership-Fähigkeiten zu entwickeln und Leadership zu zeigen.

Seit einigen Jahren geben wir Agile Leadership-Kurse. Dadurch waren wir gezwungen, unsere vielfältigen Erfahrungen und Konzept-/Modellkenntnisse so weit zu konsolidieren, dass sie in Kursen vermittelbar wurden. Die Gestaltung und die Optimierung des Kurses waren also eine wichtige Vorarbeit für dieses Buch. Gleichzeitig dient dieses Buch auch als Begleitmaterial für unsere Kurse.

Im Rahmen dieser Kurse ist auch das unten beschriebene Leadership-Konzept entstanden, in das verschiedene Modelle und Konzepte anderer Autoren und unsere Erfahrungen eingeflossen sind.

Wir teilen mit diesem Buch große Teile unseres aktuellen Standes zum Thema Agile Leadership, weil wir mehr Agile Leadership in der Welt sehen wollen. Agile Leader gestalten ihr Unternehmen marktorientiert. So entstehen erfolgreichere Unternehmen mit besseren Produkten und Services, die ihre Endkunden und Mitarbeiter begeistern.

1.3Änderungen zur vorigen Auflage

Neben der Überarbeitung vieler Einzelaspekte haben wir in der 2. Auflage die folgenden Themenschwerpunkte erweitert bzw. neu aufgenommen:

Wir haben den Abschnitt über das von Gerhard Wohland beschriebene Konzept für agiles Arbeiten (blaue & rote Arbeit) deutlich überarbeitet (

Abschnitt 1.6

).

Dem Thema Vertrauen haben wir ein eigenes Kapitel gewidmet (

Kapitel 6

). Es erläutert die Vertrauensformel und gibt Hinweise, wie sie eingesetzt werden kann, um das Vertrauen im Team, aber auch zwischen Mitarbeitern und Führungskräften zu stärken.

Das Kapitel zur Leadership-Entwicklung haben wir komplett überarbeitet (

Kapitel 8

).

Die Diskussion zu Hochleistungsteams haben wir um größere Teile zur Führung solcher Teams erweitert (

Abschnitt 12.3

).

Bei den Zielsystemen haben wir eine Erörterung zum Thema Fokus (

Abschnitt 17.2

) sowie zum Zusammenhang zwischen Zielen und Teamstrukturen (

Abschnitt 17.3

) hinzugefügt.

Wir haben das Agile Fluency Model™ durch eine Diskussion der Zusammenarbeit mehrerer Teams ersetzt. Wir stellen den Agile Descaling Cycle (

Abschnitt 19.1

), die leichtgewichtige Koordination zwischen Teams (

Abschnitt 19.2

) sowie neue Perspektiven auf Teamkonzepte und Teamschnitte (

Abschnitt 19.3

) vor.

Den Abschnitt über Soziokratie haben wir komplett neu geschrieben. Der aktualisierte Ansatz zur Beschreibung fokussiert stärker auf Soziokratie 3.0. Wir haben die Beschreibung exemplarischer gestaltet, weil sich in den letzten Jahren gezeigt hat, dass das Thema auf diese Weise zugänglicher wird (

Abschnitt 19.6

).

Damit das Buch nicht aus allen Nähten platzt, haben wir die Kapitel zum Unternehmenslernen (

Teil IV

»

Agile Leadership für gemeinsames Lernen

«) verschlankt.

1.4Agile Leadership ist Leadership

Wir verwenden die Leadership-Definition des Coaches Training Institute (CTI): »Leader entscheiden sich dafür, Verantwortung für ihre Welt zu übernehmen« [Kimsey-House & Kimsey-House 2015]. Diese Definition beinhaltet drei relevante Aspekte:

Ein Leader übernimmt

Verantwortung

. Unter Verantwortung verstehen wir, Probleme in Besitz zu nehmen und sich ihnen mit allen ihren Aspekten zu stellen

1

.

Ein Leader

entscheidet

sich dafür, Verantwortung zu übernehmen. Er ist nicht Opfer der Umstände. Er handelt nicht, weil er

muss

, sondern weil er

will

.

Ein Leader definiert bewusst die

Grenzen seiner Welt

. Akzeptiert er ein Problem als Teil seiner Welt, lotet er Optionen aus und handelt aus Verantwortung heraus.

Das bedeutet insbesondere, dass Leadership nicht an einen Auftrag oder eine formelle Führungsposition gebunden ist:

»Everyone has the capacity to contribute and to choose responsibility. Everyone has the capacity to lead. Leadership is a choice, and it begins with one’s willingness to be responsible for what is happening in one’s world« [Kimsey-House & Kimsey-House 2015].

1.5Was wir unter Agilität verstehen

Agile Leadership bedeutet, mit agilen Prinzipien und Werkzeugen Leadership zu praktizieren und damit seine Welt in Richtung größerer Agilität zu entwickeln. Was Agilität für die Softwareentwicklung bedeutet, ist im Agilen Manifest mit seinen Wertaussagen und den Prinzipien beschrieben (siehe [Agile Manifesto 2001]).

Das Agile Manifest lässt sich leicht auf jede Form der Produktentwicklung übertragen. Eine breitere generelle Anwendung ist mit der griffigen Formel von Alistair Cockburn (siehe [Cockburn 2019]) leicht möglich: »Collaborate, deliver, reflect, and improve, in tight cycles. If you can find something better, use it.«

Wir nutzen zur Visualisierung den agilen Kernzyklus (siehe Abbildung 1.1). Der Zyklus beginnt und endet mit den Endkunden. Diese haben Probleme, die ein agiles Team in Lösungen umwandelt. Letztlich geht es also darum, dass agile Teams kundenrelevante Probleme lösen.

Abb. 1.1Der agile Kernzyklus

Ein Gradmesser für Agilität ist damit die Direktheit der Kundeninteraktion. Idealerweise spricht das Team direkt mit den Endkunden (und nicht vermittelt über Front-Office-Mitarbeiter, Anforderungsmanager, Product Owner o. Ä.). Außerdem liefert das Team direkt die Lösung an Kunden und muss dabei nicht über Dritte gehen, wie z.B. Account Manager oder Qualitätssicherung.

Hohe Marktdynamik erfordert schnelle Reaktion. Daher sollte der beschriebene Problemlösungszyklus möglichst schnell und häufig durchlaufen werden. Der Kunde sollte nicht Monate auf seine Lösung warten, sondern diese so schnell wie möglich erhalten. Wenn z.B. eine größere Software entwickelt werden muss, die nicht nach wenigen Wochen für den operativen Einsatz an den Kunden ausgeliefert werden kann, sollten dem Kunden zumindest Zwischenstände gezeigt und Feedback eingeholt werden.

Durch die kurzen Zyklen wird das Lernen über Kundenprobleme, mögliche Lösungen sowie das beste Vorgehen beschleunigt. Wir inspizieren und adaptieren sowohl auf der Ebene der Lösungen wie auch des Prozesses/Vorgehens zur Entwicklung der Lösung. Inspect & Adapt lautet das Motto.

Das agile Team agiert dabei autonom und selbstorganisiert (siehe Abbildung 1.2). Dies betrifft eingehende und ausgehende Beziehungen zu Dritten. Es erhält keine Anweisungen von außen, wie es sich zu organisieren hat. Außerdem ist es nicht von anderen Teams abhängig. Es kann die Kundenprobleme lösen, ohne auf andere Teams oder Abteilungen warten zu müssen.

Abb. 1.2Selbstorganisiertes, autonomes Team

Damit das Team kundenrelevante Probleme schnell und autonom umsetzen kann, muss es eine große Bandbreite an Fähigkeiten besitzen: Das agile Team ist interdisziplinär besetzt. Welche Spezialisierungen im Team konkret notwendig sind, hängt von den Kunden und ihren Problemen ab. Ein Softwareentwicklungsteam könnte z.B. aus einem User-Experience-Designer, einem programmierenden Architekten, Frontend-Entwicklern, Backend-Entwicklern und Testern bestehen. In einem Übersetzerteam könnten beispielsweise Experten für die Zielsprachen, wie Englisch, Französisch, Spanisch, arbeiten. Und in beiden Fällen könnte man auch auf die Idee kommen, Key Account Manager oder Vertriebler ins Team zu integrieren.

Das agile Team weicht von der klassischen sequenziellen Phasenorganisation ab (siehe Abbildung 1.3). Stattdessen organisiert es seine Arbeit so, dass sich die klassischen Phasen überlappen: Analyse, Design, Engineering und Qualitätssicherung (QS) werden nicht strikt nacheinander durchgeführt, sondern gleichzeitig.

Wie stark sich die Phasen überlappen, hängt vom Kontext ab. Generell gilt: Je dynamischer das Umfeld, desto stärker sollten sich die Phasen überlappen: Im Extremfall führt das Team alle Phasen gleichzeitig aus. In Kontexten, die nicht ganz so dynamisch sind, reicht mitunter eine eingeschränkte Überlappung aus: Eine Phase beginnt, bevor die vorhergehende Phase komplett abgeschlossen ist.

Abb. 1.3Überlappende »Phasen« bei agiler Entwicklung

Für das agile Team können wir zusammengefasst festhalten:

Es ist autonom und arbeitet selbstorganisiert.

Es ist interdisziplinär besetzt.

Es verbessert Ergebnis und Prozess über Inspect & Adapt.

Agilität lässt sich damit in einem Satz beschreiben:

Autonome Teams mit Business-Fokus, die ihren Prozess in Besitz und Verantwortung nehmen und kontinuierlich verbessern.

1.6Kontext für Agilität

Agile Teams liefern bessere Ergebnisse als klassisch organisierte Projekte – wenn sie im richtigen Kontext eingesetzt werden. Denn Agilität ist kein Allheilmittel, sondern ein Werkzeug, das in spezifischen Umgebungen seine Stärken entfaltet. Stabilität und Routine erfordern andere Ansätze als Dynamik und Innovation.

Um diese Unterschiede besser zu verstehen, lohnt sich der Blick auf das von Gerhard Wohland beschriebene Konzept der blauen und roten Arbeit (siehe [Wohland 2016]). Der zentrale Faktor, der diese beiden Arten von Arbeit unterscheidet, ist die Anzahl der unvermeidbaren Überraschungen:

Blaue Arbeit

ist Routinearbeit. Überraschungen sind hier selten oder vollständig vermeidbar. Die beste Strategie ist daher, Prozesse so zu gestalten, dass sie möglichst effizient und fehlerfrei ablaufen. Der Fokus liegt darauf, Kosten zu senken und Stabilität zu gewährleisten. Viele Unternehmen haben genau diesen Typ Arbeit über Jahrzehnte optimiert. Typische Beispiele sind standardisierte Abläufe in der Produktion, Buchhaltung oder Logistik.

Rote Arbeit

hingegen ist dynamisch, geprägt von vielen Überraschungen, die nicht vorhergesehen werden können – und die auch durch langes Nachdenken im Vorfeld nicht verschwinden. Hier liegt der Fokus auf Flexibilität, Kreativität und Anpassungsfähigkeit. Erfolgreiche Strategien zielen darauf ab, auf Überraschungen zu reagieren und diese sogar gezielt am Markt zu erzeugen, z.B. durch Innovationen oder bahnbrechende Geschäftsmodelle.

1.6.1Warum diese Unterscheidung so wichtig ist

Die Art der Arbeit – ob blau oder rot – erfordert vollkommen unterschiedliche Strategien und Organisationsprinzipien:

Bei der Routinearbeit (blau) liegt der entscheidende Wettbewerbsvorteil darin, möglichst kostengünstig und effizient zu sein. Hier greifen Regeln, Prozesse, Automatisierung und straffe Steuerung, um Ressourcen zu sparen und gleichbleibend hohe Qualität zu liefern.

Bei der dynamischen Arbeit (rot) liegt der Schlüssel zum Erfolg darin, flexibel, kreativ und anpassungsfähig zu sein. Überraschungen sind hier nicht vermeidbar, sondern Teil des Spiels. Eine Organisation muss daher so gestaltet werden, dass diese Überraschungen nicht als Störung empfunden werden, sondern als Chance, die genutzt werden kann.

Weil sich diese beiden Arten von Arbeit so fundamental unterscheiden, sollten sie auch entsprechend unterschiedlich organisiert werden. Das gilt sowohl für die Strukturen als auch für die Arbeitsweisen. Diese klare Differenzierung wird in vielen Unternehmen jedoch nicht ausreichend berücksichtigt – mit der Folge, dass weder die blaue noch die rote Arbeit ihr volles Potenzial entfalten. Abbildung 1.4 stellt ein paar der Prinzipien gegenüber, nach denen wir blaue und rote Herausforderungen erfolgreich bearbeiten (Abbildung nach [Wohland 2016]).

Abb. 1.4Blaue vs. rote Arbeit

1.6.2Wie agile Teams blaue und rote Arbeit adressieren

In der Praxis gibt es eigentlich keine »reine« blaue oder rote Arbeit. Die meisten Aufgaben und Rollen beinhalten Elemente von beiden. Mitarbeitende müssen oft zwischen Routineaufgaben und dynamischen Anforderungen wechseln. Ein Entwickler, der sicherstellt, dass sein Code den definierten Code Guidelines entspricht (blau), wird vielleicht plötzlich ein unerwartetes Problem lösen müssen, das durch eine neue technische Anforderung oder einen Bug auftritt (rot). Ähnlich wird ein Vertriebsmitarbeiter einerseits standardisierte Angebote erstellen (blau) und andererseits bei einem neuen Kunden mit besonderen Anforderungen kreative Lösungen entwickeln (rot).

Hier kommt die Stärke agiler Arbeitsweisen ins Spiel. Agile Teams nutzen regelmäßige Feedback- und Anpassungsschleifen (Inspect & Adapt), um den blauen und roten Charakter ihrer Aufgaben immer besser zu verstehen und die passende Herangehensweise zu wählen. Ein agiles Unternehmen schafft eine Umgebung, in der Teams kontinuierlich lernen können, zwischen Routine und Dynamik zu unterscheiden und ihre Arbeitsweise flexibel anzupassen.

Wichtig ist jedoch: Agiles Arbeiten ist darauf ausgerichtet, rote Arbeit zu erledigen. Es basiert auf Prinzipien wie Flexibilität, iterative Anpassung und Selbstorganisation, die besonders in dynamischen Kontexten ihre volle Wirkung entfalten. Routineaufgaben lassen sich zwar in agilen Rahmenwerken organisieren, aber hier stoßen agile Methoden an ihre Grenzen. Sie sind schlicht nicht darauf optimiert, maximale Effizienz in stabilen Kontexten zu erzielen – klassische Ansätze sind hier oft besser.

Gleichzeitig bewegt sich Agilität innerhalb des roten Spektrums eher im mittleren Bereich. Methoden wie Design Thinking oder Lean Startup sind deutlich dynamischer ausgerichtet. Während agiles Arbeiten darauf abzielt, kontinuierlich Verbesserungen und Lösungen zu liefern, zielen Design Thinking und Lean Startup darauf ab, in kürzester Zeit völlig neue Erkenntnisse und Innovationen zu schaffen – mit einer noch stärkeren Fokussierung auf Überraschungen und unvorhergesehene Wendungen. Ein agiles Team ist also ideal, wenn der Fokus auf iterativer Anpassung liegt.

1.7Agile Organisationen

Agilität steht für Anpassungsfähigkeit. Eine agile Organisation zeichnet sich also dadurch aus, dass sie sich schnell und flexibel an ihre Umwelt anpassen kann. Wie genau eine agile Organisation dafür intern strukturiert sein soll, ist nicht festgelegt. Die Strukturen dürfen nur der Anpassungsfähigkeit nicht im Weg stehen.

Agile Entwicklung fokussierte ursprünglich auf das einzelne Team und machte keine Aussage darüber, was Agilität bedeutet, wenn es über einzelne Teams hinausgeht, geschweige denn, was eine agile Organisation ist. Ziemlich sicher entsteht eine agile Organisation nicht durch eine Menge agiler Teams. Besonders relevant sind die Interaktionen zwischen den Teams sowie zwischen Teams und anderen Organisationseinheiten. In Teil IV »Agile Leadership für gemeinsames Lernen« behandeln wir diese Frage ausführlich.

Die Interaktionen zwischen den einzelnen Organisationseinheiten müssen transparent und offen erfolgen. Das ist leicht hingeschrieben, stellt in der Praxis aber eine riesige Herausforderung dar. Schließlich braucht es eine durchgängige Vertrauenskultur im ganzen Unternehmen.

1.8Unser Modell: Kultur, Struktur, Leadership

Effektive Agile Leadership deckt folgende Bereiche ab:

Strukturen und Prozesse

Kultur

Persönliche Weiterentwicklung als Leader

Zu den Strukturen und Prozessen gehören neben dem formellen Organigramm auch die formellen und informellen Prozesse, Rollen und Besprechungen. Wir fordern für agile Organisationen nicht einen Verzicht auf Hierarchien. Wir beobachten aber, dass es Leadership auf allen Ebenen der Organisation braucht, um erfolgreich zu sein. Wir beschreiben in diesem Buch, wie agilere Organisationsstrukturen aussehen können und – viel wichtiger – wie der Weg dorthin gestaltet werden kann.

Damit eine agile Organisation entstehen kann, muss eine klare (agile) Richtung bei der schrittweisen Organisationsentwicklung verfolgt werden.

Außerdem ist es wichtig, seine Entwicklungsschritte mit Feedback zu überprüfen und anzupassen. Immer wieder planen, handeln, planen, handeln, … führt ohne eine Überprüfung der Wirkung zu einer Irrfahrt. Abhilfe schafft hier eine Vision bzw. ein Nordstern, in dem wir uns auf die wesentlichen Prinzipien verständigen, an denen wir unsere Organisationsverbesserung ausrichten wollen (siehe Abbildung 1.5).

Wir verwenden die Leadership Cycles als Modell für agile Organisationsentwicklung. Wir beginnen damit, agil(er) zu arbeiten. Das hat viel mit Teamautonomie und dezentralen Entscheidungen zu tun. Entsprechend weisen viele Hindernisse, die wir in der Arbeit identifizieren, auf Abhängigkeiten hin, die direkt oder indirekt behindern. Es gilt also, diese Abhängigkeiten zu erkennen und geeignet zu koordinieren. Passend zu den agilen Prinzipien bevorzugen wir Koordinationsansätze, die die Teams selbst anwenden, gegenüber solchen, mit denen Teams von außen koordiniert werden. Damit stärken wir die Selbstorganisation und Handlungsfähigkeit der Teams.

Abb. 1.5Vision/Nordstern zur Organisationsentwicklung

Bei der Arbeit und Koordination der Teams werden Hindernisse auftreten. Diese sind der Ausgangspunkt für die weitere Entwicklung der Organisation. Es gilt, die Voraussetzungen zu schaffen und das Unternehmen so aufzustellen, dass die Teams agiler arbeiten können. Oft bedeutet dies in Unternehmen, bereits bestehende Strukturen aufzulösen: Damit verfolgen wir eher den gegenteiligen Ansatz zur klassischen Herangehensweise, bei der auftretenden Problemen mit zusätzlichen Strukturen begegnet wird. Wir suchen nach Lösungen, die keine zusätzlichen, idealerweise sogar weniger Strukturen benötigen.

Zur Veranschaulichung eignet sich der englische Begriff »Descaling« sehr schön. Zum einen kann man ihn als Gegenteil von »Scaling« (vergrößern) verstehen. Zum anderen bedeutet er aber auch »entkalken«.

Wir unterstützen das Vereinfachen der Organisationsstrukturen (blauer Zyklus) durch die Arbeit an der Unternehmenskultur (grüner Zyklus in Abbildung 1.6). Hierzu arbeiten wir insbesondere daran, das Vertrauen im Unternehmen zu stärken. Auf dieser Basis kann dann (Eigen-)Verantwortung gefördert und auch eingefordert werden. Und in einem Unternehmen, in dem es viel Vertrauen und echte Verantwortung gibt, braucht es wenig Strukturen, um gemeinsames Handeln im Sinne des Unternehmens sicherzustellen2.

Abb. 1.6Kultur und Struktur bedingen sich gegenseitig.

Das ist in der Praxis nicht so einfach, wie es sich vielleicht anhören mag. Problemlösungen über zusätzliche Strukturen fallen uns viel schneller ein. Und wenn wir uns schnell für eine solche Lösung entscheiden, fühlen wir uns sicher, weil wir ins Handeln kommen. Es ist Leadership notwendig, um diesem Drang nach der schnellen Lösung zu widerstehen, hinter die Kulissen zu schauen und das zu finden, was uns nachhaltig weiterhilft. Außerdem braucht das Ausbilden von Leadership-Fähigkeiten auf allen Ebenen Energie und Mentoring, für das sich viele Unternehmen nicht die nötige Zeit nehmen.

Entsprechend vervollständigen wir unsere Abbildung durch den Leadership-Zyklus (oranger Zyklus in Abbildung 1.7). Führungskräfte führen sich selbst und andere. Passend zu den agilen Prinzipien, suchen sie nach Feedback, um ihre Wirkung wahrzunehmen. Auf dieser Basis setzen sie sich ihre Absichten und passen ihre Handlungsweisen an, um die beabsichtigte Wirkung effektiver zu erzielen.

Abb. 1.7Veränderung braucht Leadership.

»Kultur ist, was wir immer tun und was wir nie tun« (Esther Derby auf einer Konferenz). Somit beeinflussen wir tagtäglich die Kultur unseres Unternehmens durch das, was wir tun, nicht tun oder dulden. Im Gegensatz zu Prozessen betrachtet die Kulturebene auf anderer Ebene das Miteinander: Welche Gespräche finden auf welche Art und Weise statt? Welche werden eher vermieden? Mit dem Power-Cycle beschreiben wir in Kapitel 7 ein Werkzeug, wie Kulturentwicklung in einem agilen System betrieben werden kann.

Das richtige Handwerkszeug als Führungskraft zu beherrschen, ist nur die eine Seite der Medaille, wenn es um effektive Leadership geht. Anderson und Adams bringen es mit »The inner game runs the outer game« auf den Punkt (siehe [Anderson & Adams 2015]). Wenn wir selbst gestresst sind, von Angst oder anderen Gefühlen getrieben, agieren wir nicht mit unserem vollen kreativen Potenzial. Daher ist es wichtig, dass wir an unserem inneren Spiel und somit auch unseren Begrenzungen arbeiten, wenn wir unsere Leadership weiterentwickeln wollen. Ein Mittel für diese Arbeit können The Responsibility Process™ und The Leadership Circle Profile® sein, die wir im weiteren Verlauf des Buches beschreiben.

1.9Überblick über das Buch

Das Buch ist in vier Teile organisiert:

Teil I

»

Selbst-Leadership

«

Teil II

»

Agile Leadership im Team

«

Teil III

»

Agile Leadership in der Organisation

«

Teil IV

»

Agile Leadership für gemeinsames Lernen

«

Selbst-Leadership

Effektive Leadership basiert auf Selbstführung. Wer unreflektiert handelt und selbst nicht weiß, was ihm wichtig ist, kann andere nicht führen. Wir beschäftigen uns in diesem Teil mit The Responsibility Process™ zur Selbstführung.

Selbstführung funktioniert nur bis zu einem gewissen Maß unter Stress. Irgendwann kommt der Punkt, an dem wir nicht mehr mit klaren Intentionen agieren, sondern im Autopilot-Modus unterwegs sind. Das ist immer dann der Fall, wenn wir hinterher feststellen, dass ein anderes Verhalten sinnvoller gewesen wäre.

Leadership-Entwicklung hilft dabei, das Maß akzeptablen Stresses zu erhöhen. Dazu finden wir heraus, warum wir uns von bestimmten Situationen bedroht fühlen, und arbeiten an den Ursachen. Wir führen mit dem Leadership Circle Profile® ein 360-Grad-Feedback-Instrument ein, das uns hilft, unsere eigenen Entwicklungspotenziale klarer zu sehen und unsere Leadership gezielt weiter zu entwickeln.

Agile Leadership im Team

Auch wenn agile Teams allein noch keine agile Organisation machen, sind agile Teams wichtige Bestandteile agiler Organisationen. In diesem Teil des Buches beschäftigen wir uns mit hochperformanten agilen Teams. Diese zu schaffen, ist eine anspruchsvolle Aufgabe. Hochperformante Teams entstehen (leider) nicht von selbst, sondern brauchen Führung.

Dabei muss Führung klarmachen, welche Ziele warum erreicht werden sollen. Gleichzeitig braucht es einen Fokus auf die Teammitglieder. Die passende Umgebung und Führung bewirken, dass die Teammitglieder über sich hinauswachsen können und das Team tatsächlich mehr wird als die Summe seiner Teile.

Agile Leadership in der Organisation

Schließlich müssen agile Teams und andere Arbeitsformen in einen organisatorischen Kontext eingebettet werden. Dieser Teil spannt das ganze Feld von den vorherrschenden hierarchischen Zielsystemen (Management by Objectives (MbO), Objectives and Key Results (OKR), Hoshin Kanri) bis hin zu konsequent marktorientierten Organisationsformen (BetaCodex) auf. Dabei beleuchten wir insbesondere auch die Abhängigkeit der Organisationsstruktur und -kultur von Leadership. Die weit fortgeschrittenen Organisationsstrukturen sind dauerhaft nur dann erfolgreich, wenn auch die wesentliche Leadership im Unternehmen eine gewisse Reife aufweist.

Agile Leadership für gemeinsames Lernen

Die meisten Probleme im Unternehmen sind Probleme »in between« – also in den Zwischenräumen. Wenn das Team nur unzureichende Ergebnisse erzielt, liegt das meistens nicht an einzelnen Teammitgliedern, sondern an der Interaktion im Team. Wenn die Organisation schlechte Ergebnisse produziert, liegt das selten an einer einzelnen Abteilung, sondern viel häufiger an Interaktionsdefiziten zwischen den Abteilungen. Der Umgang mit diesen Problemen erfordert gemeinsames Lernen (sonst verharren wir im mentalen Zustand »Beschuldigen«, siehe Kapitel 3). Im letzten Teil des Buches fokussieren wir daher auf Organisationslernen. Das Unternehmen ist nur dann anpassungsfähig, wenn es ein lernendes Unternehmen ist. Eine agile Organisation ist immer eine lernende Organisation.

Damit Organisationslernen wirklich stattfinden kann, braucht es offene Kommunikation auch in sehr schwierigen Situationen. Dafür braucht es Leadership: Nur wenn alle Beteiligten sich offen einbringen und sich allen Aspekten des Problems wertfrei aussetzen, ist die Voraussetzung für Organisationslernen gegeben.

1.10Danksagung

Auch dieses Buch wäre ohne die direkte oder indirekte Mitwirkung vieler anderer Menschen nicht entstanden. Wir verwenden viele Modelle und Konzepte anderer Autoren. Zum Teil sind diese Ideen durch viele Hände bzw. Köpfe gegangen und dabei immer weiterentwickelt worden. Es ist nicht immer einfach, herauszufinden, wo Konzepte ihren Ursprung haben. Wir haben unser Bestes getan, die Urheber zu nennen. Wenn uns das nicht immer vollständig gelungen ist, entschuldigen wir uns dafür und sind dankbar für entsprechende Hinweise.

Alle in diesem Buch beschriebenen Konzepte kennen wir aus der Anwendung in der Praxis. Viele unserer Kolleginnen und Kollegen bei it-agile, befreundete Berater wie auch unsere Beratungskunden und Schulungsteilnehmer haben uns dabei geholfen. Für ihr Engagement und ihren Mut möchten wir ihnen danken; es sind zu viele, als dass wir sie alle namentlich nennen könnten. Aus der Anwendung sind z.T. Anpassungen der Konzepte entstanden, die insbesondere die Adaption auf den agilen Kontext vereinfachen.

Nicht zuletzt bedanken wir uns bei unserer Lektorin Christa Preisendanz sowie dem dpunkt.verlag für die erneut liebevolle und professionelle Unterstützung bei diesem Buchvorhaben.

Teil I

Selbst-Leadership

Wir arbeiten uns im Buch von Selbst-Leadership über Agile Leadership im Team bis zur Organisationsebene hoch. In diesem Teil beschäftigen wir uns mit Selbst-Leadership. Wir machen klar, warum Selbst-Leadership so wichtig ist für effektive Führungsarbeit (siehe Kapitel 2).

Anschließend stellen wir mit The Responsibility Process™ ein leicht verständliches und gleichzeitig mächtiges Werkzeug für Selbst-Leadership vor. Es hilft uns dabei, bei Problemen ins verantwortungsvolle Handeln zu kommen (siehe Kapitel 3).

Danach beschäftigen wir uns damit, welche Wirkung unsere Glaubenssätze auf unsere Emotionen, unser Denken und Handeln haben. Das langfristige Arbeiten an unseren Glaubenssätzen macht uns dauerhaft zu effektiveren Führungskräften (siehe Kapitel 4).

Anschließend betrachten wir agile Kernelemente wie Feedback und Transparenz für Leadership (siehe Kapitel 5).

Vertrauen ist für eine enge Kooperation und effektive Teamarbeit essenziell. Wir betrachten die Vertrauensformel und diskutieren, wie Vertrauen gestärkt werden kann (siehe Kapitel 6).

Mit dem Power- oder Control-Modell stellen wir ein Modell vor, das hilft, die eigenen Verhaltensweisen, Annahmen und Glaubenssätze zu reflektieren und in kraftvolleres Handeln zu kommen (siehe Kapitel 7).

Ein reichhaltiges Instrument zur Leadership-Entwicklung stellen wir mit dem Leadership Circle Profile® vor. Es basiert auf 360-Grad-Feedback (siehe Kapitel 8).

Schließlich beschreiben wir einige Aspekte des individuellen Lernens, die für Leadership wichtig sind (siehe Kapitel 9).

2Warum Selbst-Leadership so wichtig ist

Leadership beginnt beim Einzelnen und Leadership ist mehr als nur eine Richtung vorgeben. Wenn wir Menschen führen wollen, sollten wir mit dem Menschen anfangen, den wir am besten kennen sollten: uns selbst.

»Alle wollen die Welt verändern, aber keiner sich selbst.«

Tolstoi

Wir glauben, dass die agile Bereitschaft zur Selbstreflexion, zum kontinuierlichen Verbessern, neu Ausrichten ihren Anfang beim Einzelnen nehmen muss. Erst recht dann, wenn er oder sie Leadership mit und für andere übernehmen will. Denn ob wir es wollen oder nicht, wir führen immer auch als Vorbild. Andere spüren, merken und beobachten, wenn wir nicht authentisch sind und von ihnen fordern, was wir selbst nicht leben.

Deshalb wollen wir uns in diesem Teil mit Themen wie persönlicher Verantwortung, unseren Glaubenssätzen, unserem Verhalten unter Druck, unserem Umgang mit Feedback und Transparenz, dem Umgang mit eigenen Fehlern und Schwächen und unseren Weiterentwicklungsmöglichkeiten in diesen Bereichen beschäftigen.

Unser Motto dazu:

Führe dich selbst zuerst.

Als Beispiele zur Erklärung, worauf wir hinauswollen, mögen die folgenden Geschichten der Autoren helfen.

Henning: Kein Geschäftsführer mehr

Bevor wir mit den ersten elf Mitarbeiterinnen und Mitarbeitern Ende 2004 die it-agile GmbH gegründet haben, hatten wir miteinander ausgemacht, wer die Geschäftsführung übernimmt. Es gab so etwas wie einen inneren Gründerkreis von drei Personen, von denen ich einer war. Die beiden anderen waren Stefan und Martin, die beide nicht unbedingt Geschäftsführer werden wollten. Ich habe die Aufgabe gerne übernommen und schon in den Gründungswirren die meisten der Vorgespräche mit unserem Gründungspartner und unseren Anwälten übernommen. Ich war stolz auf den Titel Geschäftsführer und habe ihn natürlich auf meine Visitenkarte gedruckt. Neben der Anerkennung, die ich aus dem Titel gezogen habe, kam schließlich nach einem wirtschaftlich starken ersten Jahr auch noch ein Firmenwagen dazu, den sonst keiner zusätzlich hatte. Es handelte sich quasi um so etwas wie einen GF-Bonus auf das ansonsten gleiche Gehalt, das bei uns in der damaligen Gehaltsstufe Senior-Berater gezahlt wurde. Ich führte alle sechs Monate mit den Kolleginnen und Kollegen Personalgespräche, entschied über ihre Hochstufung und meine Erwartungen an sie. Ich habe Vorstellungsgespräche geführt und neue Leute eingestellt. Und mich natürlich mit unserem Assistenten der Geschäftsführung um die ganze Orga und große Teile des Vertriebs gekümmert.

Über die Jahre haben wir immer mehr der ursprünglichen Aufgaben der Geschäftsführung in die Selbstorganisation gegeben. Es fing nach meiner Erinnerung mit dem Vertrieb und der Besetzung an, es folgten Gehaltsfindung und Personalführung sowie Personaleinstellungen. Das habe ich alles mitgestaltet und halte es alles für sehr sinnvoll, weil zum einen die Entscheidungen meist besser werden, wenn sie dezentral von denen getroffen werden, die es am besten entscheiden können. Ich hatte aber auch ein persönliches Motiv: Ich wollte kein Vollzeitmanager werden und weiterhin selbst als Berater und Trainer tätig sein. Die coolste Erleichterung für die Führungsaufgaben als Geschäftsführer war die Einführung von Company-Coaches, die mit den Kollegen gemeinsam herausfinden, welche Regeln es braucht und wie wir damit umgehen, wenn sich jemand nicht an die Regeln hält.

Im Jahr 2018 schließlich lautete unser wesentlicher Auftrag an die Rolle Geschäftsführung: »Stellt die Selbstorganisation von it-agile sicher.« Und ja, es gibt noch etwas Formalkram zu tun. Trotzdem habe ich meine Rolle Geschäftsführer in 2018 mit einem Aufwand von ca. vier bis sechs Stunden pro Monat ausgeführt.

In 2017 haben wir ein Geschäftsführer-Azubi-Programm gestartet und zwei Kollegen – Sandra und Wolfgang – gewählt, die in die (formale) Arbeit der Geschäftsführung eingeführt werden sollten. Damals war schon klar, dass es letztlich darauf hinauslaufen würde, dass wir uns ab und zu neue Geschäftsführer wählen werden und ich meinen Posten würde aufgeben müssen.

Ich halte das für eine selbstorganisierte Firma für einen konsequenten und richtigen Schritt; persönlich fiel er mir aber schwer. Ich war über zehn Jahre nicht mehr Mitarbeiter gewesen, hatte keinen Chef gehabt (außer den Mitarbeitern als Mitgesellschaftern). Mir gefiel die besondere Rolle, das gesellschaftliche Ansehen, das mit dem Titel Geschäftsführer einhergeht. Würde ich mich damit abfinden können? Zuerst dachte ich, dass es bedeuten müsste, dass ich das Unternehmen verlasse: Keine schöne Vorstellung, es steckt viel Herzblut von mir in it-agile.

Schließlich habe ich mich mit der Idee anfreunden können, nicht mehr Geschäftsführer zu sein. Ich bin dazu in mich gegangen und habe genau erforscht, was ich eigentlich möchte, was mich antreibt und was ich vorantreiben will. Dabei ist nichts herausgekommen, für das ich Geschäftsführer sein müsste. Manches könnte sogar als Mitarbeiter einfacher und leichter werden. Dazu musste nichts von außen her oder in der Organisation verändert werden, sondern ich habe meine Einstellung geändert.

Als wir zum 1. März 2019 den Staffelstab an die neuen Geschäftsführer übergeben haben, ging für mich schon eine Ära zu Ende. Aber es begann auch freudig eine neue. Ich übernehme immer noch gerne und an einigen Stellen Leadership im Unternehmen. Leicht gemacht hat es der Umstand, dass wir am Gehalt nichts geändert haben und ein sanfter Übergang über die Ausbildung der neuen Geschäftsführer über mehr als ein Jahr erfolgte. So konnte ich mich mit der Zeit an den anstehenden Wechsel gewöhnen.

Stefan: Die andere Keynote

Ich hatte mit einem Kunden vereinbart, dass ich auf einer internen Konferenz einen bezahlten Keynote-Vortrag halte. Der Vortrag sollte zwei Tage nach Ende meines Sommerurlaubs stattfinden und ich habe die lange Bahnfahrt zum Kunden genutzt, um den Vortrag vorzubereiten.

Es gab wegen eines neuen Computersystems am Empfang des Kunden Verzögerungen bei der Registrierung, sodass ich nur wenige Minuten vor dem vereinbarten Vortrag in den Raum kam. Zu meinem Erschrecken stellte ich fest, dass die Begrüßung auf Englisch stattfand und erinnerte mich voller Scham, dass wir genau das bei der Auftragsklärung besprochen hatten: Mein Vortrag sollte auf Englisch stattfinden. Allerdings waren meine Folien komplett auf Deutsch und noch viel schlimmer: Mental hatte ich mich auf einen deutschen Vortrag eingestellt. Ich muss mich immer erst ins Englische reindenken und meine englischen Vorträge sind auch lange nicht so unterhaltsam wie meine deutschen.

Der Schreck saß mir also entsprechend tief in den Knochen und ich war kurz davor, die Flucht zu ergreifen. Mir wurde allerdings schnell klar, dass meine Emotionen gerade dabei waren, mich in Besitz zu nehmen, und ich entschied mich für einen anderen Weg. Ich wollte im Besitz meiner Emotionen bleiben und stellte mich meiner Scham. Ich sagte dem Veranstalter, dass ich die Folien nur auf Deutsch dabei hätte und dass ich etwas Zeit bräuchte, um sie umzuschreiben. Der Veranstalter zog daraufhin spontan einen anderen Vortrag vor und ich habe während dieses Vortrags meine Folien übersetzt. Mit zitternden Händen übersetzte ich die letzte Folie, als der vorgezogene Vortrag zu Ende war. Und dann gab es auch noch Schwierigkeiten mit der Technik. Der Beamer wollte nicht mit meinem Notebook und das Übertragen der Datei per USB-Stick auf den Präsentationsrechner funktionierte auch nicht. Um Zeit zu gewinnen, gab es eine außerplanmäßige Kaffeepause, in der wir es doch noch schafften, den Vortrag auf den Präsentationsrechner zu bekommen. In der Zeit der Restpause kam ich etwas zur Ruhe. Ich dachte mir »Pleiten, Pech und Pannen. Soll das jetzt immer so weiter gehen?« und war versucht, mich diesem Schicksal zu ergeben. Dann wurde mir aber klar, was ich will: einen unterhaltsamen Vortrag halten, der die Teilnehmer mit provokanten Thesen zum Nachdenken bringt. Mit dieser klaren Absicht habe ich dann den wahrscheinlich besten englischsprachigen Vortrag meiner Karriere gehalten.

3The Responsibility Process™

Mit The Responsibility Process™ beschreibt Christopher Avery ein Selbstführungsmodell, das die mentalen Zustände thematisiert, die wir bei Problemen durchlaufen (siehe Abbildung 3.1). Im besten Fall kommen wir bei vollständiger Verantwortung an.

Ein Problem ist im Sinne dieses Modells etwas, das uns im Wege steht, das zu bekommen, was wir wollen. Wir verwenden hier als Beispiel, dass eine Besprechung A länger gedauert hat, weswegen wir unpünktlich zu Besprechung B kommen.

Abb. 3.1The Responsibility Process™

3.1Die mentalen Zustände

Beschuldigen

Wenn wir auf ein Problem stoßen, dann beginnen wir im mentalen Zustand »Beschuldigen