Diese Frage möchte ich gerne beantworten, indem ich einen Einblick in meine Aufgaben als externe Beraterin in einem Lebensmittelkonzern gebe.
Zunächst noch eine kurze Erläuterung über den Ursprung des Begriffs „agil“, der häufig inflationär gebraucht wird. Er wurde als Gegensatz zu wasserfallartigen, also linear geplanten IT Projekten verwendet. Die uns allen wohlbekannte Methode von anfänglicher Planung und anschließender Umsetzung im Wasserfallmodell geht davon aus, dass die Zukunft planbar ist. Agile Methoden dagegen akzeptieren, dass die Zukunft unklar ist und viele “Unbekannte” bereithält. Nur unmittelbar Bevorstehendes ist klar, verständlich und kann bearbeitet werden. Unter dem Schlagwort „responding to change“ gehen agile Methoden davon aus, dass Veränderung die einzige Konstante ist. Diese Grundidee findet sich auch im wohlbekannten agilen Manifest aus dem Jahr 2001 wieder. Über die Jahre formten sich Arbeitsweisen, die Veränderungen – Change – als Teil des Arbeitsprozesses verankerten, wie etwa Scrum, Kanban, DevOps und viele andere. Inzwischen hat sich der Begriff weit über eine methodische Definition aufgeladen. Mehr Informationen über die rasante Entwicklung des Begriffs finden Sie hier.
Was sind nun die Aufgaben eines Agilen Coaches und wer coacht denn da eigentlich wen?
Dieser kleine Praxisbericht stammt aus einer Zeit, in der ich mich selbst noch nicht als Agile Coach bezeichnet habe. Mein Auftrag war, den damaligen Director of Architecture in der Konzern IT einerseits in seiner Arbeit zu unterstützen, ihn aber auch zu bremsen, wenn seine Pläne zur Einführung eines agilen Framework zu dogmatisch werden.
Ziel war es, das stationäre Geschäft auch Online anbieten zu können. Ein anfangs überschaubares B2B eCommerce Shop Projekt wuchs mit inzwischen acht Teams zu einem business-relevanten Programm, das – um so schnell wie möglich voranzukommen – an externe Dienstleister vergeben wurde. Losgelöst von den internen Konzernstrukturen sollte das Projekt so effizient wie möglich umgesetzt werden. Nun galt es herauszufinden, ob die Arbeitsweise dieses ausgelagerten Programms Vorbild für den Rest der IT-Organisation wird und die Organisation sich danach ausrichtet oder umgekehrt, das Programm nach und nach eingegliedert wird mit unbekannten Folgen. Wir befanden uns in einer Phase, in der mein Kunde die Transformation des Konzerns mit hohem Tempo vorantrieb. Er wollte agiles Arbeiten in die anderen Units ausweiten.
In diesem Spannungsfeld hatte ich einen erfüllten Tag:
8:00: Vorbereitung auf die anstehenden Termine. Priorisierung von dringenden “Feuerlöscher”-Tätigkeiten in Delivery-Teams und langfristigen Transformationsabstimmungen, wie z.B. interne Risk-Assessments für agile Teams
9:00: Stand-Up Meeting im Transformations-Kernteam. Themen im Backlog waren z.B. Lean Lego Game für 50 Mitarbeiter in der Supply Chain, Vorbereitung eines Offsites für Führungskräfte, Erweiterungen des internen agilen Frameworks
9:30: Begleitung des Director of Architecture zu einem Meeting der BU Leiter. Sie sollten dafür gewonnen werden, erste agile Ansätze, die eher schauartigen Charakter hatten, wie z.B. den Einsatz von Product Ownern, weiter voranzutreiben. Dafür bot ich meine Unterstützung an, um Teams bzgl. Produktfokus, Scope und Arbeitsflow zu coachen. Auch die Verbesserung der Kommunikation über Teamgrenzen hinweg wurde thematisiert und die Einführung entsprechender Kanban-Boards angedacht.
10:30: Vorbereitung des Offsites für 30 Führungskräfte im Transformations-Kernteam. In diesem eintägigen Workshop sollte das interne agile Framework vorgestellt und Aufgaben einer neuen Rolle – Agile Coach – erarbeitet werden.
12:30: Lunch mit einem Product Owner aus dem Infrastructure Team. Das neu geformte Team zum Aufsetzen einer initialen Deployment Pipeline kam aus Perspektive des POs nur schleppend voran. Er fragte mich nach Optimierungsideen, die ich ihm in Form von verschiedenen Workshops gab. Denkbar wären z.B. Sessions zur Klärung von Rollen und Verantwortlichkeiten, Erarbeitung des Produktfokus und die Vorbereitung eines priorisierten Backlogs. Wir verabredeten uns zu einem weiteren Termin, um Details zu planen.
13:30: Stand-Up Meeting im IAM-Team. Das Team arbeitete zu 50% in Düsseldorf und zu 50% in Indien. Da der Product Owner mehrere Teams betreute, unterstützte ich dort vorübergehend, um das Team anzuleiten, eine Produktroadmap zu erstellen. Ziel war es, zukünftig den internen Kunden einen Planungshorizont zu geben, wann welche Feature der neuen Applikation verfügbar werden.
15:00 – 17:00: Vorbereitung Discovery-Workshop in der Supply Chain. In diesem Workshop sollte die Customer-Journey gemeinsam mit den internationalen, konzern-internen Kunden des Einkaufs erarbeitet werden. Im Anschluss könnte dann entschieden werden, an welchen Stellen in der Wertschöpfungskette große Informationsverluste vorliegen und dafür spezielle Lösungsansätze entwickelt werden. Zwei Konzernmitarbeiter übernahmen in diesem Workshop die für sie neue Rolle des Product Owners. Ich machte sie mit der Workshop-Methodik vertraut und bereitete sie als Co-Moderatoren vor.
17:30: Abstimmung des Transformations-Kernteams mit dem Director of Architecture, der treibenden Kraft der Transformation. Wir besprachen mit ihm die Agenda des geplanten Off-sites. Über 30 Führungskräfte wurden eingeladen, um Näheres über agiles Arbeiten, das agile Framework und eine möglichen neuen Rolle – Agile Coach – zu erfahren. Unklar war kurz vor dem Workshop noch, in wie vielen Teams das neue Framework angewendet werden sollte. Der Director of Architecture plante dies für alle 40 Teams, hatte aber keine Freigabe des CEOs. Wir konnten also die Leute nur informieren und idealerweise für die Idee gewinnen, auf freiwilliger Basis. Das Kernteam überlegte, ob es wirklich schon genügend Erfahrungen aus der Praxis gab, um das Framework auf weitere Teams auszuweiten.
18:30: Ich rief meinen Kollegen an, der für die Personalplanung für diesen Account zuständig war. Da die Fülle der Themen unendlich erschien, wünschte ich mir Verstärkung von Kollegen, so dass die zahlreichen Coaching Aufgaben und Workshop Moderationen auf mehreren Schultern verteilt würden und wir auch eine größere Wirkung in der Organisation erzielen könnten. Je mehr Personen aus meinem Unternehmen unterstützten, also das Zielbild einer agilen Organisation kannten, umso geringer wäre die Gefahr in bestehenden Arbeitsmustern und Strukturen des Konzerns verhaftet zu bleiben.
So ähnlich sah mein täglicher Terminkalender über sechs Monate lang aus. Dann wurde die Position des CEOs neu besetzt und die Transformation wurde mit reduzierter Geschwindigkeit auf niedrigerem Aktivitätslevel fortgesetzt. Andere Konzernthemen wurden höher priorisiert, da der vielleicht überlebenswichtige Online-Shop ja nun am Start war.
Für mich war diese Phase einer der intensivsten Beratungsaufträge meiner Karriere, aus der ich noch heute Erkenntnisse für aktuelle Transformationsprojekte gewinne.
Da dieser Beratungsauftrag bereits vier Jahre zurückliegt, möchte ich aus heutiger Perspektive noch ein paar Erkenntnisse hinzufügen. Damals erschien mir meine Arbeit wie ein Tropfen auf den heißen Stein. Es wurden zu viele Themen punktuell angegangen, ohne eine nachhaltige Begleitung der Teams. Ein Kick-Off-Workshop allein reicht nicht, um dauerhafte Veränderungen im Team zu verankern. Nach dieser Phase war ich einer Domäne zugeordnet und unterstützte dort den Aufbau eines neuen Produktbereiches, während ich fest in einem Team verankert war. Auch hier wurde es mir nicht langweilig!
Trotzdem erhielt ich weiterhin Anfragen für die Begleitung und Moderation von Workshops in anderen Domänen des Konzerns, da sich einige Führungskräfte und Teams eine Fortführung wünschten.
Als externe Beraterin hatte ich eine Aufgabe übernommen, für die es intern keine unabhängigen Berater oder Coaches gab. Meinungsverschiedenheiten, die unter anderem strukturell verankert waren, wie z.B. stationäres Geschäft versus online hatten sich über Monate oder sogar Jahre aufgebaut. Durch die Moderation eines unabhängigen Dritten konnten die Vor- und Nachteilen der jeweiligen Lösungsvorschläge erfragt werden. Die Notwendigkeit, mich über das ein oder andere Thema aufzuklären, war sicher auch für andere Workshop-Teilnehmer hilfreich. So übernahm ich „die dummen Fragen“. Alle konnten sich die Argumente anhören, um letztlich darüber abzustimmen.
Aus heutiger Sicht halte ich derartige Workshops für eine gute Intervention, wenn mehrere Führungskräfte strategische Entscheidungen treffen. Sie können dann die Ergebnisse in die Teams tragen. Die Begleitung von Teams erfordert meiner Meinung nach allerdings immer ein zeitintensiveres Coaching auf täglicher Basis um Veränderungen zu verankern.
Über die Rolle des Agile Coaches möchte ich festhalten, dass er oder sie sich weniger als ein Business Coach um einzelne Personen kümmert, sondern vielmehr ganze Teams und deren Bedürfnisse im Blick hat. Idealerweise kennt ein Agile Coach gruppendynamische Prozesse und weiß, welche Interventionen dem Team helfen.
Nicht selten treten an den Schnittstellen von selbstorganisierten Teams zum Rest der Organisation strukturell bedingte Konflikte auf, bei denen der Agile Coach vermitteln kann. Im Spannungsfeld von Ausweitung oder Reduzierung neuer Arbeitsmethoden tritt er oder sie als Vermittler:in auf. Einerseits werden Teams abgeschirmt, andererseits auch Interessen der relevanten Umwelt der Teams vertreten. Mit diesen Aufgaben hat ein Agile Coach täglich alle Hände voll zu tun – häufig aufgrund der schlechten Erreichbarkeit von Schlüsselpersonen bis in die späten Abendstunden hinein und über einen sehr langen Zeitraum hinweg.
#becomebetter
