Foto: insta_photos - shutterstock.com
Eine Frage bereitet diversen IT-Beratern, IT-Führungskräften und praktizierenden Informatikern Kopfschmerzen: Wie lassen sich die Wörter "agil" und "führen" sinnvoll in einem Satz verwenden? Die Aufregung resultiert aus der Angst vieler Manager vor einer bisher unbekannten und weitestgehend unverstandenen agilen Welt. Sind es moderne Teufel? Hype oder eine substanzielle Veränderung in der Führungskultur und der Arbeitsweise bis hin in die Chefetagen?
Manch einer plädiert gänzlich für die Abschaffung des Managements (Holakratie). Andere reden von autarken, selbst-organisierten Teams. Wir fragen uns: Wie lassen sich überhaupt die Selbstorganisation, Kontroll- und Planbarkeitsillusion miteinander vereinbaren? Kann überhaupt eine gestandene Führungskraft Macht abgeben und freiwillig agil werden?
Was Agilität bedeutet
Zunächst zum Begriff der Agilität. Eine Definition aus dem Lexikon oder Wikipedia wäre an dieser Stelle wenig hilfreich. Schauen wir lieber, woher dieser Begriff kommt und wofür er steht. Agile Methoden sind in der Softwareentwicklung als Alternative für konventionelle, Wasserfall-orientierte Lösungsentwicklungsmethoden entstanden. Heute steht agil für kurze Auslieferungszyklen der Software, direkte Beteiligung der Fachseite am Entwicklungsprozess, Adaptivität durch Feedback nach jeder Auslieferung. Agil wird oft definiert als iterativ und inkrementell. Iterativ, weil man sich schrittweise in wiederholten Gängen der Lösung nähert. Inkrementell, weil der Umfang der Software - wie beim inkrementellen Erhöhen der Variable - nach jeder Iteration wächst.
Was Führung bedeutet
Nun zum Begriff der Führung. Führung ist vor allem Orientierung schaffen: Mitarbeitende müssen wissen, warum sie tun was sie tun. Führungskräfte erklären den Sinn der Aufgabe, setzen das Setting auf, kontrollieren üblicherweise die Resultate. Führen heißt entscheiden: Ziele definieren, Konflikte auflösen, Prioritäten setzen, Ressourcen zuteilen.
Was agiles Führen bedeuten soll
Nun zum agilen Führen. Viele Agilisten verwenden diesen Begriff, um Auswirkungen agiler Trends auf Führung als solches zu beschreiben. Dies sorgt für Verwirrung. Partizipative Führung (z.B. kollektiver Einzelentscheid, Konsens etc.) sind bereits seit Jahrzehnten bekannt. Situative Führung und Reifegrad des Geführten werden oft im Kontext von Selbstorganisation angesprochen und seit langer Zeit an deutschen Universitäten in der Vorlesung Entscheidungstheorie gelehrt. Kontinuierliche Verbesserung setzte Toyota bereits in den 1950ern ein. Dass die Führungskräfte mehr loslassen müssen - alleine sich selbst zuliebe - wussten wir auch schon. Was ist nun grundliegend anders gegenüber früher?
Der Begriff des agilen Führens ist insofern unglücklich gewählt, weil im engeren Sinne "agil" keine Eigenschaft des Führens ist. Kann man überhaupt iterativ und inkrementell (= agil) führen? Viel korrekter wäre die Bezeichnung "Führen im agilen Umfeld", welche die geänderten Anforderungen an die Führungskräfte, die im agilen Umfeld tätig sind, beschreibt und die beiden Begriffe nicht vermischt. In diesem Beitrag werden wir mit ein paar Beispielen zeigen, wo sich die beiden Begriffe berühren und wieso agiles Führen als eigenständiger Führungsstil nicht existiert.
Brauchen wir noch Manager?
Bei diesem Gedanken erscheint unweigerlich das Bild von Che Guevara vor dem geistigen Auge. Es wäre jedoch zu früh für eine Revolution. Nehmen wir uns ein Beispiel. Es handelt sich dabei um ein Entwicklungsteam bei einer führenden deutschen Versicherung. Das Team ist cross-funktional besetzt und arbeitet nach Kanban. Das Team entscheidet selber, welche Aufgaben es als Nächstes umsetzt, und leitet eigenständig Verbesserungsmaßnahmen für seine Arbeit ein.
Neben dem Kanban-Team gibt es indirekt beteiligte Fachkräfte, z.B. Test Manager oder Lösungsarchitekten. Für das Team sind es externe Dienstleister. Das Team entscheidet in Eigenregie, wann und wie oft diese Fachkräfte konsultiert werden. Beteiligte Gruppenleiter sorgen für Räume, Arbeitsmittel, Zuteilung von Ressourcen und Staffing. Beteiligte Abteilungs- und Bereichsleiter können aus Sicht des Kanban-Teams als Stakeholder gesehen werden. Sie setzen "Spielregeln" und übergeordnete Rahmenbedingungen, koordinieren das Zusammenspiel mehrerer Teams und managen Lieferanten sowie Sourcing-Partner.
Das beschriebene Kanban-Team erfüllt eine bestimmte Rolle mit Rahmen eines größeren Projekts. Projekt- und Teilprojektleiter sind hier ebenfalls Stakeholder aus Sicht des Kanban-Teams. Sie koordinieren die Gesamterreichung der Projektziele und brechen sie auf einzelne Teams herunter.
Führungsaufgaben werden atomisiert und umverteilt
Die Führungsaufgaben bleiben also im System, werden jedoch atomisiert und umverteilt. Die Frage ist daher nicht, ob wir Manager brauchen, sondern was für welche? Eine geänderte Aufgabenteilung erfordert das Umdenken bei der Besetzung von Führungspositionen.
Schauen Sie sich die Lebensläufe der Führungskräfte in Ihrem Unternehmen an: Wo sind da die Studienabbrecher und Non-Konformisten? Sind Sie sich da sicher, dass aktuelle Besetzungen alleine die richtigen Personen sind, die den radikalen Wandel meistern und die Unternehmen ins digitale Zeitalter führen?
Führung und Selbstorganisation
Alle sozialen Systeme organisieren sich grundsätzlich von selbst: Schwarm-Intelligenz oder Kinder im Sandkasten. Viele Agilisten setzen nun auf Selbstorganisation und empfehlen autarke, selbst-organisierende Teams. Es wäre jedoch leichtsinnig anzunehmen, dass solche Teams von sich aus loslaufen und ohne jegliche Steuerung operieren. Schauen wir genau hin, welche Führungsarbeit ist notwendig, um ein solches Team aufzustellen und zu betreiben.
Ein Team ist üblicherweise mit einer gemeinsamen Mission ausgestattet: einem Grund seiner Existenz, einer zu erfüllenden Aufgabe. Im Rahmen dieser Mission hat das Team seine Entscheidungsfreiheit und kann sich selbst organisieren. Die Führungskräfte sind dafür zuständig, solche Missionen zu definieren und dem Team zu kommunizieren.
Führungskräfte "schirmen" Teams vor negativen Einflüssen ab und schaffen Freiraum
Das Team soll die Entscheidungs- und Fachkompetenz haben, um die Mission zu erreichen. Die Führungskräfte stellen die notwendigen Ressourcen zur Verfügung und akquirieren geeignete Mitarbeiter. Denn Selbstorganisation setzt bekanntlich bestimmte persönliche Reife voraus. Darüber hinaus wird häufig die Arbeitsmethode, z.B. Scrum oder Kanban, auch durch die Führungskraft vorgegeben. Das Team hat lediglich die Freiheit in der Anwendung dieser Methode. Ein laufendes Team soll lediglich den Freiraum zur Entwicklung und Eigendynamik haben. Die Führungskräfte "schirmen" das Team von den negativen Einflüssen ab und wahren diesen Freiraum.
Auch mit Umfang mit den selbstorganisierten Teams ist klassische Führungsarbeit gefragt: Ziele formulieren und kommunizieren, Zielerreichung tracken, das Team gegen äußere negative Einflüsse schützen, den Flow managen. Es ist unumstritten, dass die Führungskraft im Umgang mit selbstorganisierten Teams mehr loslassen muss: weg von Kontrolle zu mehr Gestaltung. Das hat jedoch nicht unbedingt mit agilen Methoden zu tun und was ist hier substanziell anders gegenüber dem bereits seit geraumer Zeit bekannten Ansatz des partizipativen Führens?
Versicherung beschränkt Dauer aller IT-Projekte auf 6 Monate
Ein führendes deutsches Versicherungsunternehmen beschränkte die Dauer aller IT-Projekte auf maximal sechs Monate. Spätestens nach einem halben Jahr sollte jedes IT-Projekt eine lauffähige Software mit einem zusätzlichen greifbaren Business-Nutzen liefern. Diese Beschränkung bewirkte einen signifikanten Richtungswechsel in der IT. Die Organisation lernte in kürzeren Zyklen zu denken und sah sich gezwungen, die erste Erfolgsbilanz jedes Vorhabens bereits nach sechs Monaten zu ziehen. Auch längere Migrationsprojekte wurden in kleinere Scheiben geschnitten. Es wurde halbjährlich überprüft, ob ein Migrationsprojekt weiterläuft oder beendet wird.
Es liegt auf der Hand, dass kürzere Planungszyklen der IT-Organisation mehr Handlungsfreiheit und Flexibilität verliehen haben. Viel interessanter ist die Tatsache, dass bereits nach sechs Monaten die Entscheidung getroffen werden muss, ob das lancierte Vorhaben Erfolgsaussichten hat und weiterverfolgt werden soll oder ersatzlos gestrichen wird.
Fail-Fast
In der agilen Welt ist dieses Prinzip unter dem Namen Fail-Fast bekannt. Fail-Fast ist die Eigenschaft einer Organisation, frühzeitig Fehler zu erkennen und zu behandeln. Wird dieses Prinzip gelebt, so bekommt die Organisation eine sehr charmante Fähigkeit: Sie kann sich schnell von dem unnötigen, erfolglosen Ballast trennen.
Welche Herausforderungen haben Führungskräfte in diesem Zusammenhang? Zunächst kann eine Führungskraft etwas schlecht "wegwerfen". Führungskräfte beschäftigen sich einen Großteil ihrer Zeit damit, ihnen zugeteilte, in der Regel sehr knappe Ressourcen effizient zu verwalten und wenn möglich zu mehren.
Umdenken im Umgang mit Unsicherheit erforderlich
Die Geschäftsführung und Vorstände verlangen bei IT-Projekten Investitionssicherheit. Wegwerfen passt da nicht rein. Daher ist der Gedanke, ganze MVPs (Minimal Viable Product) wegwerfen zu können, einer Führungskraft fremd. Das Fail-Faster-Prinzip steht darüber hinaus in einem Konflikt zur Null-Fehler-Toleranz. Viele Führungskräfte sind darauf trainiert, auf Nummer sicher vorzugehen. Dazu gibt es genügend Veröffentlichungen unter den Begriffen Planbarkeits- und Kontrollillusion. Ein Try-and-Error-Vorgehen wirkt auf viele Führungskräfte einfach unseriös. Können diese Probleme nun mit einem geänderten Führungsstil alleine gelöst werden? Eher nein. Vielmehr ist ein Umdenken im Umgang mit Unsicherheit erforderlich.
Grenzen der agilen Führung
Können Sie sich Feuerwehr, Polizei, Militär oder Notaufnahme als autarke, selbstorganisierende Teams vorstellen, die eigenverantwortlich agieren und sich selber Ziele setzen? Viele würden an dieser Stelle nein sagen. Was haben all diese Beispiele gemeinsam? In allen genannten Fällen müssen Menschen mit äußert kritischen, ungünstigen Situationen umgehen. Mögliche Fehler können hierbei dramatische Auswirkungen haben. Für solche Situationen sind laut diverser Studien strikte Aufgabenorientierung und konventionelle Führungsansätze am besten geeignet.
Übertragen wir nun diesen Gedanken auf die IT-Welt. Wie oft hat man erlebt, dass Führungskräfte in Krisensituationen auf den Command-and-Control-Führungsstil zurückgreifen? Wie oft wurde es als Zeichen der Schwäche oder fehlenden Commitments zu agilen Werten empfunden? Wieso ist es negativ? Es gibt derzeit keine hinreichend große Menge an empirischen Belegen dafür, dass Selbstorganisation und Holakratie im Falle eines dauerhaften Nichterreichens der Unternehmensziele besser abschneiden als konventionelle Führungsansätze.
Nicht zuletzt bauen zahlreiche agile Methoden auf Gruppenentscheidungen. Es sind jedoch auch zahlreiche Beispiele bekannt, wo Gruppen bei Kollektiventscheiden versagen: Lagerbindung innerhalb der Gruppe, starke Meinungsmacher, strategisches Verhalten bei der Abstimmung durch Einzelpersonen oder Koalitionen.
Fazit
Es liegt auf der Hand, dass der Einsatz agiler Methoden neue Anforderungen an die Führungskräfte stellt. Zukünftige Manager werden wohl mit anderen Aufgaben und Herausforderungen zu tun haben und sie werden sich anders verhalten. Wir werden darüber hinaus die Führungspositionen auch mit anderen Personen besetzen.
Beleuchtet man jedoch die aktuellen Diskussionen rund um das agile Führen, so scheinen zahlreiche, bereits bekannte Konzepte ihr Revival zu erleben. An dieser Stelle ist höchste Aufmerksamkeit geboten: Was ist wirklich neu und gut, und was ist nur alter Wein in neuen Schläuchen?