Mitarbeiterführung: Fünf Faktoren für agile Hochleistungen
(Bild: VALERY HACHE/AFP/Getty Images)
Ein Erfahrungsbericht von Marvin Engel veröffentlicht am
Viele Entscheider denken, dass ihr Unternehmen mit Agilität plötzlich schnell und beweglich wie ein Leichtathlet wird, dazu effizient und kostengünstig. Oft scheitern sie genau deshalb. In der Praxis helfen fünf Faktoren, gängige Fehler zu vermeiden.
Früher war die Welt einfacher, sagen meine Eltern, die mittlerweile im Rentenalter angekommen sind. Selbst sie kennen den Begriff "agil" - allerdings nicht für Unternehmen. Für sie ist ein Leichtathlet agil, der im Zehnkampf in allen Disziplinen durch Schnelligkeit, Beweglichkeit und Spitzenklasse glänzt. Eben einer, der besser ist als die anderen.
So eine Vorstellung von Agilität haben nicht nur meine Eltern. Auch viele Entscheider in Unternehmen stellen sich die Umstellung auf agile Prozesse so vor - darunter auch Führungskräfte, die noch nicht kurz vor der Rente stehen. Nach aktuellen Umfragen herrscht nämlich der Glaube vor, die Entscheidung, agil zu sein, mache das Unternehmen oder die Abteilung sofort besser als alle anderen.
Schneller, effizienter und günstiger - das sind Effekte, die sich Unternehmen von einer Umstellung auf agile Arbeitsweisen versprechen. Und zwar unmittelbar. Das ist aber ein gängiges Missverständnis. Denn diese Denkweise geht zu sehr vom Unternehmen aus. Was Agilität eigentlich will, ist, dass der Kunde im Mittelpunkt steht.
Die Anspruchshaltung des Höher - Schneller - Weiter kommt aber nicht von ungefähr: Liest man einige der entsprechenden Unternehmenspräsentationen aus der Rubrik "Wer wir sind und was wir machen", sieht man nicht selten die Überschrift "Wir sind agil". Darunter folgen Buzzwörter wie Schnelligkeit, Flexibilität und bessere Ergebnisse. Mein Job als beratender Projekt- und Prozessmanager besteht dann oftmals darin, die angeblich gelebte Agilität kritisch zu hinterfragen und Verbesserungspotenziale ausfindig zu machen.
Im agilen Manifest von Jeff Sutherland und Ken Schwaber steht der Kunde im Mittelpunkt. Die agile Transformation beginnt also im Unternehmen, sollte aber vor allem demjenigen etwas bringen, der am Ende die Produkte oder das Ergebnis des Unternehmens erhält. Am Anfang steht daher bei meiner Arbeit stets eine Bestandsaufnahme, um sich an die Probleme mit der Agilität langsam heranzutasten. Typische Fragen sind dabei: Bestimmen die Arbeitnehmer ihre Arbeitszeit und den Ort selbst? Werden Ziele im Team definiert? Und am wichtigsten: Wie genau wird hier im Sinne des Kunden gedacht?
Die letzte Frage lässt sich mit zwei einfachen Anschlussfragen überprüfen: Nutzen die Mitarbeiter die entwickelte Software (oder das Produkt) zumindest zu Testzwecken selbst? Haben sie je mit einem Kunden persönlich darüber gesprochen? Wenn eine oder beide der Fragen mit Nein beantwortet werden, sind wir noch sehr weit von einem agilen Mindset entfernt.
Keine Sorge, ich bin kein Freund agiler Buzzwörter wie Mindset, Standups oder Spirit. Trotzdem gehören diese Dinge zu einer agilen Arbeitsumgebung und müssen von allen Instanzen im Unternehmen gelebt, respektiert und akzeptiert werden - wie auch immer man sie nennen möchte (dazu später mehr). Mein erster Aufklärungspunkt lautet daher: Agilität startet nicht mit dem Wunsch, agil zu sein, sondern mit den konkreten Maßnahmen der agilen Transformation und deren konsequenter Anwendung in Bezug auf die Kundenbedürfnisse. Kennen das Unternehmen und die Mitarbeiter diese Maßnahmen nicht, können sie auch nicht agil sein.
Die Umstellung bereitet Schmerzen
Die Transformation ist ein schwieriges Unterfangen. Häufig ist sie an der einen oder anderen Stelle schmerzhaft, einiges funktioniert am Anfang nicht richtig. In einem Fall, den ich erlebt habe, wollte der Abteilungsleiter gleich nach einem Monat alles wieder rückgängig machen. Denn im ersten Sprint wurde das Sprintziel nicht erreicht und viele geplante Aufgaben blieben liegen. Für ihn war das ein GAU, hatte er doch dem Vorstand Agilität als Heilmittel für Verzögerungen versprochen.
In meinem Team haben wir ihm dann erklärt, dass zur Umsetzung auch Fehler gehörten und dass diese gut seien, denn sie zeigten Potenziale für Verbesserungen auf. So simpel diese Erkenntnis klingt, so schwer war sie für ihn zu internalisieren. Aber wenn beim Fußball der erste Schuss danebengeht, fängt der Stürmer ja auch nicht plötzlich an, in der Abwehr zu spielen, oder hängt die Karriere gleich ganz an den Nagel.
In einigen Unternehmen, in denen ich arbeiten durfte, wurde Agilität zwar grundsätzlich gelebt, trotzdem fehlte es an agiler Führung. In einem meiner Projekte waren die Vorgesetzten der Abteilung gar in einem ganz anderen Gebäudetrakt untergebracht. Es sei ja schließlich nun ein agiles Team, hieß es. Deshalb müssten sich die Teammitglieder komplett selbst organisieren und motivieren. Und: Man sitze eben lieber in der Nähe des Vorstands als beim Team.
Das waren nur einige der Begründungen für fehlende Präsenz der Führung. Es ist ein weit verbreitetes Missverständnis, dass Agilität ohne Führungskräfte funktioniere, diese sich selbst abschaffen sollten und dies das erklärte Ziel von Agilität sei. Das ist mitnichten der Fall. Führung in agilen Projekten ist von essenzieller Bedeutung, nur eben nicht mit dem klassischen Top-Down-Prinzip - oben wird entschieden, unten wird gemacht. In agilen Unternehmensrealitäten verschwimmt die Hierarchie und Mitarbeiter aus allen Positionen können Entscheidungen treffen und Ideen anleiten.
In besagtem Unternehmen hatten sich die Führungskräfte so weit zurückgezogen, dass der Kontakt zum Team komplett abgerissen war. Es gab nur noch wenige Schnittstellen und es schien mir fast so, als ob sich keiner der Beteiligten wirklich wohl damit fühlte. Entscheidungen wurden entweder nur im agilen Team oder über dieses hinweg getroffen.
Richtig ist, dass die Führung sich nicht abkoppeln darf, sie muss sich vielmehr ändern. Zum Beispiel durch ein anderes, nicht mehr so strikt hierarchisches Verständnis den Mitarbeitern gegenüber. Das bedeutet im Umkehrschluss nicht, dass alles aus der Hand gegeben wird, was jemals Führungsaufgabe gewesen ist, zu allerletzt die Verantwortung. Ich erkläre oft, dass die Führungskräfte sich eher zu Mentoren entwickeln müssen, die ihre Mitarbeiter befähigen, ihre Ziele zu erreichen. Und dass sie diese Ziele womöglich überhaupt erst einmal gemeinsam mit ihnen definieren müssen.
Wie soll das mit mehr Distanz der Führungskraft funktionieren? Die Führungskräfte aus dem anderen Gebäudetrakt waren überzeugt davon, dass agile Teams gar keine Führung mehr benötigten. Ein Fehler, der zumindest mir ein neues Projekt sicherte. In Schulungen, Workshops und Vorträgen haben wir den Irrtum der nicht mehr benötigten Führungskraft in agilen Organisationen ausgeräumt.
Können Vorgesetzte und Mitarbeiter nicht die gleichen Ziele haben?
In einem anderen Fall sollte eine Entwicklungsabteilung mit 75 Mitarbeitern agil werden. Für sie alle gab es zu diesem Zeitpunkt einen einzigen Vorgesetzten. Unsere agile Transformation bestand aus mehreren Sprints, die wir gemeinsam definierten. Im ersten begannen wir, die 75 Mitarbeiter in neue, interdisziplinäre Teams à acht bis zehn Personen einzuteilen. Menschen, die einander nie zuvor gesprochen hatten, gehörten plötzlich einer Gruppe an.
Dann definierte jedes Team einen Teamleiter, der an den Vorgesetzten berichtete. Dies war unser erster Sprint im Projekt der agilen Transformation dieser Abteilung. Später folgte ein zweiter Sprint, in dem die Teams Reporting-Protokolle entwickelten, die einfach zu verfassen waren. Der einsame Vorgesetzte wurde in diesen Prozess mit einbezogen und so ergab sich ein neues kleines Reporting-Tool, mit dem die Teams einmal im Monat an den Vorgesetzten verschiedene Status versenden konnten: Wo steht welches Projekt? Welche kommenden Milestones sind zu erwarten? Und so weiter.
Die Teamleiter wurden in diesem Sprint zu Scrum Mastern, die für flüssige Arbeitsabläufe und die Problembehebung innerhalb der Teams verantwortlich waren. Scrum Master sind in dem agilen Framework Scrum diejenigen Teammitglieder, die dafür sorgen, dass alle anderen im Team ohne Hindernisse arbeiten können. Jeden Tag leiten die Scrum Master das kurze Daily Standup, den 15-minütigen Austausch des Teams.
Außerdem achtet der Scrum Master auf die Einhaltung der agilen Prinzipien im Team. In meinem Projekt wurde die Hierarchiestufe des Teamleiters aus dem ersten Sprint aufgelöst und zum Scrum Master konvertiert. Dadurch wurde der Vorgesetzte von vorher zu einem Partner im Team, der maßgeblich für den Erfolg durch Problemlösungen verantwortlich war. So folgten weitere Sprints und die Agilität im Unternehmen nahm allmählich Form an.
Führung in agilen Projekten ist meiner Meinung nach der nötige Treibstoff für die Mitarbeiter. In Workshops zum grundsätzlichen Verständnis zur Agilität bitten wir die Arbeitnehmer gerne, ihre eigenen beruflichen Ziele aufzuschreiben. Wir fragen sie dann, ob sie glauben, dass ihr Vorgesetzter diese für realistisch hält und sie bei der Erreichung dieser Ziele unterstützen wird. In vielen Fällen wird das verneint - mit der Begründung, dass die Vorgesetzten andere Ziele (Profit, Effizienzsteigerung, Kostensparen) hätten als die Mitarbeiter (persönliche Weiterentwicklung, Karriereaufstieg, mehr Verantwortung).
Ein weiterer weit verbreiteter Mythos, dem ich in meiner täglichen Arbeit begegne, ist, dass Agilität einfach jeder sofort können müsse. Es heißt, wir nennen es Scrum, arbeiten in Sprints, klicken ein paar grob definierte Tickets für die Entwickler zusammen und schon sind alle agil.
Das kann nicht funktionieren. In meiner wissenschaftlichen Ausarbeitung mit dem Titel Agile-Emotional-Leadership - Erfolgsfaktoren zum Führen in agilen Projekten wird deutlich, dass neben dem Wunsch, dem Willen und dem Wortschatzwissen vor allem fachliches Wissen Voraussetzung für eine erfolgreiche agile Transformation ist.
Ein gutes Beispiel hierfür ist die Definition einer Aufgabe für einen Entwickler. Ich möchte meiner eigenen Gattung der Projektmanager natürlich keine grundsätzliche Unfähigkeit unterstellen, erlebe aber immer wieder zum Beispiel Product Owner oder Projektmanager (je nachdem, wie sie im Unternehmen genannt werden), die überhaupt kein Wissen über die Tätigkeiten eines Entwicklers haben. Die richtige Einschätzung "Ich bin kein Entwickler" bedeutet nicht, dass man die Verfahren und Vorgehensweisen nicht kennen sollte.
Als Autofahrer sollte man zum Beispiel wissen, wie eine Bremse bedient wird, auch wenn man sie nicht herstellt. Zu wissen, was ein Entwickler tut, heißt nicht, dass man für die Definition einer Aufgabe den Entwickler zu sich zitiert, um dann mit ihm gemeinsam die Arbeit zu machen. Die Person, die eine Aufgabe definiert, sollte aber zum Beispiel wissen, wie man eine typische User Story schreibt. Eine User Story ist eine Anforderung an eine Softwareanwendung, die nahezu in Alltagssprache verfasst ist und selten länger als fünf Sätze ist. Es hilft Entwicklern ungemein, wenn Screenshots oder Zeichnungen solche User Storys illustrieren und diese dadurch besser visualisiert werden.
Einige Kollegen benutzen für Design-Dummys gerne Tools wie Anima App und bauen Prototypen, auf deren Grundlage die Entwickler Storys besser verstehen können. Umgekehrt sind Entwickler hilfreich, die ein grobes Kosten-Nutzen-Verständnis haben. Verantwortlich dafür ist zwar der Projektmanager/Product Owner. Wenn man gemeinsam Lösungen erarbeitet, sollte ein Entwickler diese Thematik jedoch schon einmal gehört und verinnerlicht haben. So vermeidet man Ansätze, die von Beginn an unrealistisch sind, weil sie zu teuer werden.
Mit meinen Kunden diskutiere ich immer wieder Timelines, Deadlines und Timing Charts - also die Festlegungen, wann etwas fertig sein soll. Immer wieder trete ich dabei für mehr Zeit ein. Mehr Zeit für Mitarbeiter, mehr Zeit für Entwicklungen, mehr Zeit für Prozesse. Wer in einem großen Konzern mit jahrelang gewachsenen hierarchischen Strukturen Agilität in vier Wochen einführen möchte, hat meiner Meinung nach eine falsche Vorstellung davon, was Agilität schaffen kann.
Deutlich mache ich das am Beispiel Sicherheit: Für mehr Sicherheit warten wir gerne länger am Flughafen, aber für bessere Qualität planen wir - vielleicht abgesehen von der Weinreife - ungern mehr Zeit ein. Dabei bringt ein qualitativ hochwertiges Produkt viel mehr Erfolg und Gewinn als ein schnelles, schlecht gemachtes Produkt, egal, ob es sich um ein Auto oder eine Software handelt.
Zeit kann man nicht kaufen, deshalb ist sie auch in Projekten von unschätzbarem Wert. Besser als eine Pufferplanung finde ich eine ehrliche Kommunikation über den verfügbaren und den nötigen Zeitrahmen. Diese Entscheidung ist individuell und von vielen Faktoren abhängig. Auch wenn es dafür keine Faustformel gibt, sollte man auf jeden Fall darüber sprechen.
Mein letzter Punkt ist abstrakt, aber nicht weniger wichtig. Unter meinen vielen Projekten, die ich begleiten durfte, waren die großartigen meistens jene, an denen Menschen mit einer inneren Überzeugung arbeiteten: Mitarbeiter wie Führungskräfte, die an etwas glaubten und ihre Zweifel nicht als Gegner, sondern als Ansporn betrachteten.
Wenn ein Unternehmen oder eine Abteilung den Schritt gehen möchte, agil zu werden, wird es immer Zweifel und Zweifler geben. Es werden immer wieder Fehler passieren, und wenn diese Gesetzmäßigkeit auf eine Kultur trifft, in der das alles verpönt ist, ist die Transformation von Anfang an zum Scheitern verurteilt.
Im besten Fall werden in hierarchisch organisierten Unternehmen agile Rituale übernommen. Dann werden zum Beispiel agile Prinzipien wie eine Sprintplanung durchgeführt, die Mitarbeiter sind aber weiterhin hierarchisch organisiert und darauf angewiesen, was die Vorgesetzten ihnen an Arbeitspaketen zuteilen. Im schlechtesten Fall funktioniert die Umstellung gar nicht und Agilität wird als Mythos verspottet, der keine Vorteile bringe und nur in tollen Online-Artikeln auf IT-Webseiten hochgepriesen werde.
Auch ich konnte ein paar meiner Projekte nicht zu dem gewünschten Erfolg führen. Einige aufgrund von eigenem Unwissen und Fehlern, andere aufgrund von äußeren Umständen. Entscheidend ist die schonungslose und ehrliche Analyse dieser Fehler. Denn nur so kann man sie meiner Meinung nach beim nächsten Mal vermeiden und sich verbessern.
Kulturwandel bedeutet nicht, einen x-beliebigen CEO auszutauschen, es ist viel mehr als das. Meine Überzeugung ist: Ändert sich die Kultur, ändert sich die Mentalität und erst dann ändern sich die Ergebnisse. Agilität muss also in die DNA von Unternehmen hineinwachsen - was Zeit braucht - und von dort aus neue Pfade entdecken dürfen. Wer in diesen Prozessen nur an Geld, Profit und die eigene Gier denkt, hat heute schon den Weg zur vorteilsbringenden Agilität verloren.
Individuelle Unterstützung zu Themen rund um Job & Karriere gibt Shifoo, der Service von Golem.de - in 1:1-Videosessions für IT-Profis von IT-erfahrenen Coaches und Beratern.