Agile Projekte haben ihre eigenen Gesetzmäßigkeiten. Besonders in der Softwareentwicklung. Wer sie kennt und zu nutzen versteht, kann Entwicklungsprozesse im Turboverfahren vorantreiben und hoch komplexe Produkte schaffen, die außergewöhnlich eng an den Anforderungen des Anwenders liegen. Aber volles Tempo und freie Hand für das Team sind nur eine Seite des agilen Vorgehens. Wer nicht bestimmte Voraussetzungen beherzigt und Agilität als eigene Haltung und Denkweise kultiviert, wird schnell mal aus der Kurve getragen.
Entscheidend für erfolgreiches agiles Vorgehen ist die Fähigkeit eines Leaders, Verantwortung abzugeben und wirklich loszulassen. Das ist schnell mal gesagt. Doch nur, wer dieses Wechselspiel beherrscht, bringt ein agiles Projekt besser über die Ziellinie als auf konventionellem Weg. Man kann es wie einen Spiegel sehen, in dem sich – je nach Perspektive – Product Owner und Teammitglieder auf Augenhöhe begegnen. Der Spiegel teilt die Situation in zwei Seiten, aber er verbindet, stellt ein Miteinander her. Für Selbstüberhöhung bzw. Unterordnung oder Konkurrenzgehabe ist da kein Platz.
Worauf es dabei für eine Führungskraft ankommt, möchte ich aus eigener Erfahrung als Projektmanagerin von agilen IT-Projekten der BMW Group berichten. Mir ist dabei bewusst, dass ich als Working-Out-Loud-Initiatorin bei BMW hier auf WOL-Werte, wie das Aufbauen von Beziehungen oder Großzügigkeit, zurückgreifen kann. – und diese Tatsache freut mich besonders.
Vorgeben – ja. Kommandieren – nein.
In die Verantwortung eines Product Owners fällt das Sammeln von Anforderungen, deren Formulierung und Priorisierung. Und ja, er soll und muss endgültige Entscheidungen über das gewünschte Produkt fällen. Aber das war es dann auch. Denn jetzt übernimmt das Entwicklungsteam und setzt die definierten Anforderungen eigenverantwortlich um. Und hier wird es schwierig. Mir selbst ist es anfangs schwergefallen, Verantwortung ans Team nicht nur abzugeben, sondern sie ihm sogar gezielt zu übertragen. Denn agiles Führen soll Vertrauen herstellen und Coaching-Prozesse lediglich begleiten. Das Team organisiert sich selbst.
Deshalb müssen sich Entwicklungsteam und Product Owners hundertprozentig aufeinander verlassen können. Im Klartext: Wenn es mir nicht gelingt, Verantwortung abzugeben und eine Basis der Verlässlichkeit zu schaffen, ist agiles Vorgehen zum Scheitern verurteilt. Von Agilität kann man dann auch nicht mehr sprechen. Führungskräfte, die agil unterwegs sein wollen, sollten deshalb unbedingt mit sich selbst zu Rate gehen: Wenn ich nämlich alle Fäden permanent in der Hand haben will und jeder Entscheidung „weiter unten“ chronisch misstraue, bin ich zumindest für agile Projekte einfach die falsche Besetzung.
Selbstbeschränkung beim Daily
In der Praxis kann das so aussehen: Das Team einigt sich im Sprintplanungsmeeting für einen Zeitraum von zwei Wochen gemeinsam mit dem Product Owner auf abzuarbeitende Themen. In einem 15-minütigen täglichen Meeting (Daily) bringt das Team die aktuelle Entwicklung und Herausforderungen zur Sprache, auch Probleme, bei denen Hilfe von außen benötigt wird. Der Product Owner darf am Sprintplanning teilnehmen, sollte beim Daily jedoch stiller Zuhörer sein. Oder – aber nur, wenn das Team dies wünscht – zu den besprochen Themen beitragen, Fragen beantworten, etwas klarstellen oder über fachliche Tests sprechen. Das ist der Idealfall.
Doch ich erlebe immer wieder, wie ein Product Owner die Besprechung an sich reißt und Teammitglieder kritisiert und dirigiert. Im letzten Herbst war ich Zeugin, wie ein Product Owner unter Druck sehr nervös wurde. Alle Security-Maßnahmen sollten noch bis Jahresende umgesetzt sein, was in einen regelrechten Wettkampf unter den Projektverantwortlichen gipfelte. Als ihm die Zeit immer schneller davonlief, priorisierte er das Thema kurzerhand und überraschend für den laufenden Sprint. Das ist unüblich und sorgte natürlich für Verstimmung. Entweder muss ein solcher Schritt gleich am Start erfolgen oder später zumindest diskutiert werden – so kam einfach nur eine Anweisung. Und das Team? Zieht den Kopf ein und tut, was man ihm sagt.
In der Vergangenheit kam viel zu oft nur derjenige weiter, der nicht groß nachgefragt, sondern Anweisungen „von oben“ möglichst effizient umgesetzt hat. Und so haben viele von uns diese Verhaltensweisen ins tägliche Leben übernommen. Oder sie haben resigniert und sich damit abgefunden, dass immer ein Chef da ist, der sagt, wo es lang geht.
Vertrauen-schenken kann man lernen
Ich weiß selbst genau, wie das ist. Nach klassischem Verständnis müssen Führungskräfte Voraussagen und Entscheidungen für ihre Mitarbeiter treffen. Daran werden sie gemessen. Dass nun im agilen Führen das Umdenken keine leichte Übung ist, verstehe ich allzu gut. Doch wie wir erst lernen mussten, zu entscheiden und Verantwortung zu übernehmen, müssen wir jetzt beim agilen Führen lernen loszulassen, Verantwortung abzugeben, zu unterstützen, zu fördern und vor allem zu vertrauen. Im agilen Manifest steht nicht umsonst: „Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen.“
So geht „Führen mit Auftrag“
Und jetzt wird’s gefährlich! Ich las kürzlich ein Interview mit Jérôme Fuchs, dem Chef der Spezialeinheit GSG 9. Diese Elitepolizisten sind militärisch organisiert, ausgebildet und geführt. Als Laie denkt man da natürlich an Kategorien wie Befehl und Gehorsam. Erstaunt erfuhr ich, wie diese hochtrainierten und hochgerüsteten Profis ihre oft lebensgefährlichen Einsätze so reibungslos und ergebnisorientiert durchführen, dass man ihnen großen Respekt zollen muss. Ihre Geheimwaffe ist die Auftragstaktik – auch als „Führen mit Auftrag“ bekannt. Das geht so – Zitat: „Ich gebe meinem Team ein Ziel vor und überlasse die Art der Umsetzung den Männern vor Ort. Das hat viel mit Vertrauen und der Übertragung von Verantwortung zu tun.“
Hoppla, dachte ich, das ist doch genau mein Thema. Aber wie lässt es sich auf die Teammitglieder in einem Wirtschaftsunternehmen übertragen? Anders als beim konventionellen „Führen mit Befehl“, bei dem Zielsetzung und Verantwortung bei der höchsten Stelle liegen, die den Beauftragten keinen großen Entscheidungs- und Handlungsspielraum einräumt, erlaubt, fördert und fordert die Auftragstaktik Eigeninitiative. Konkret sagt Fuchs: „Ich werde einem Einheitsführer nicht vorgeben, welchen Weg er in einem Gebäude nimmt, um den Geiselnehmer zu finden. Das würde nicht funktionieren. Er bekommt den Auftrag, dieses Haus zu stürmen und die Geiseln zu befreien. Wie er das macht, das ist seine Aufgabe. Bei uns müssen auch junge Teammitglieder schon Entscheidungen treffen, wenn sich Situationen anders entwickeln als geplant. Denn möglicherweise gibt es keine Zeit nachzufragen.“
Kreativität darf keine Fesseln haben
Damit ist dieses Taktikmodell ein interessantes Pendant und ein, wie ich finde, wertvoller Denkansatz für agiles Vorgehen. Eine Interviewfrage an Jérôme Fuchs lautete noch, was Unternehmen daraus lernen können. Klare Antwort: das Ziel benennen, nicht zu viele Vorgaben machen und den Mitarbeiter das Wie und Womit überlassen. Ich selbst habe immer wieder erlebt, wie Mitarbeiter zur Hochform auflaufen, wenn man sie von bestimmten Fesseln befreit. Das gilt besonders in der Softwarentwicklung, in der wir es häufig mit selbstbewussten, aber auch sensiblen Individualisten zu tun haben, deren eigenständiges Denken geradezu die Voraussetzung für kreative Prozesse ist.
Fazit: Loslassen kann man trainieren!
Für eine Führungskraft ist es alles andere als selbstverständlich, die Kontrolle abzugeben. Wer 30 Jahre klassische Führungshierarchien gewohnt ist, wird sicher ein Unbehagen, vielleicht sogar ein schlechtes Gewissen haben. Das ist völlig normal. Es gibt viele Möglichkeiten, sich diese Fähigkeiten durch gezieltes Training anzueignen. Zum Beispiel in einer virtuellen Trainingssession. Auch mir lag das Überlassen von Verantwortung nicht gerade im Blut. Umso mehr haben mir seit 2016 verschiedene WOL-Circle geholfen, diesen Teil meines Entscheidungs- und Handlungsprofils nach dem agilen Führungsstil auszurichten.
