„Lass mal was agiles machen!“. Zu diesem simplen Satz kann ich viele Diskussionen mit meinen Kunden über Projektmethodik in den letzten 15 Jahren zusammenfassen. Anfangs war ich noch diejenige, die diese Idee ins Spiel brachte. Mittlerweile ist agiles Vorgehen – zumindest in Projekten – in den meisten Unternehmen gesetzt.
Agile Transformation ist inzwischen das neue große Thema. Und dafür werden in vielen Unternehmen sogar eigene Organisationseinheiten aufgebaut. Finde ich prima! Grundsätzlich. Und wenn ich dann die einfache Frage stelle „Wozu genau macht Ihr das?“, ist die Fülle der Antworten wahrlich reich und bunt:
„Das machen doch jetzt alle!“
„Wir müssen schneller werden!“
„Es hilft uns beim Recruiting junger Talente – die erwarten das.“
„Das macht einfach mehr Spaß, als Fachkonzepte zu schreiben.“
Das sind echte Zitate. Und in meiner Welt nachvollziehbare Gründe.
Nur: was hat das eigentlich mit der originären Idee und Zielsetzung agiler Methoden zu tun? Richtig: Nix.
Und wenn mich jemand fragt: „Ist das denn schlimm?“, dann finde ich: Nö. Solange die Erwartungen an die Ergebnisse genauso agnostisch sind, wie die Zielsetzung. Also: wozu eigentlich agile Transformation?
AGILE TRANSFORMATION
Agile Transformation bezeichnet einen Veränderungsprozess, den Organisationen auf verschiedenen Ebenen (Prozess-, Struktur- und Kulturebene) durchlaufen. Mit dem Ziel, durch agiles Vorgehen in einer Welt wettbewerbsfähig zu bleiben, die zunehmend von plötzlichen Veränderungen und nur mittelfristiger Planbarkeit geprägt ist.
Die Idee hinter agilen Methoden ist es, durch Fokus auf den Kundennutzen und kurze iterative Produktentwicklung kontinuierlich und bereits früh im Entwicklungsprozess funktionsfähige Resultate an den Kunden auszuliefern. Um flexibel und mit überschaubarem Aufwand auf Kundenfeedback im Sinne von Änderungen und Anforderungen reagieren zu können. Zudem zielen agile Methoden darauf ab, durch Selbstorganisation die Zusammenarbeit und Kommunikation innerhalb des (Entwicklungs-)Teams zu verbessern.
Das iterative Einholen des Feedbacks von Kunden und Nutzern und die regelmäßige Reflexion des Entwicklerteams hinsichtlich der eigenen Zusammenarbeit helfen dabei, das Produkt kontinuierlich zu verbessern und so die Kundenzufriedenheit zu erhöhen und gehören zu den wesentlichen Erfolgskriterien agiler Vorgehensweisen.
Betriebswirtschaftlich betrachtet steht über diesen Anpassungen und Entwicklungen die Frage: Würde mein Kunde für mein Produkt ausreichend viel Geld bezahlen und kann ich seine Loyalität damit an mich binden? Quasi modernes Customer Relationship Management.
Klingt doch eigentlich ganz logisch und einfach, oder? Nur: Weshalb kacheln dann immer noch so viele Transformationsprojekte vor die Wand?
Einige der häufigsten Probleme, die Unternehmen bei der agilen Transformation erleben, sind:
- Unklare, unrealistische Zielsetzung und Erwartungen und oft nicht messbare Ergebnisse bei der Einführung und Umsetzung agiler Methoden
- Mangelhafte Einbindung des Kunden
- Eine eher willkürliche Zusammenstellung der Teams
- Unzureichende Kommunikation und Zusammenarbeit zwischen (und häufig auch innerhalb) der Teams
- Unzureichende Schulung und Unterstützung durch das Management für agile Teams
- Unzureichende Unterstützung der Führungskräfte bei agiler Transformation durch ungenügendes oder fehlendes Changemanagement
- Schwierigkeiten bei der Integration bereits agiler Bereiche ins Gesamtsystem (Organisation)
- Und: keine Ahnung, was „agiles Mindset“ eigentlich bedeutet
AGILER METHODEN-BATTLE
Während die meisten Unternehmen, mit denen ich in den vergangenen Jahren zusammenarbeiten durfte, mittlerweile in ihren IT-Abteilungen mindestens Scrum(-ish) eingeführt haben, wird in Marketing und Produktmanagement gelegentlich Design Thinking oder Lego Serious Play verprobt. Einige mutige Organisationsabteilungen haben sich an Lean Six Sigma herangetraut (leider selten mit dem erhofften Erfolg) und in vielen Linien-Teams wird mittlerweile schon recht erfolgreich nach Kanban-Prinzipien gearbeitet.
Leider ist in vielen Fällen die Idee der Umsetzung einer dieser Methoden oder Frameworks nach „reine Le(e)hre“ gescheitert. Und was fehlt ist die Nachhaltigkeit, die eigentlich erreicht werden sollte. Stattdessen bleibt oftmals der Effekt irritierter und frustrierter Mitarbeitenden und der nicht selten verlauteten Überzeugung: das ist doch Quatsch.
Kurzum: Menschen und Methode wurden emotional verbrannt.
Zurückzuführen ist das meist auf das Fehlen einer Gesamtstrategie für eine tragfähige Umsetzung, ohne dabei die Organisation zu überfordern. Nicht selten auch auf mangelnde praktische Erfahrung in der Anwendung der ausgewählten Methodologie.
Seit Jahren diskutiere ich in Kundenprojekten die eine Frage: Ist es wirklich notwendig, eine Methodik oder ein Framework 1:1 so einzusetzen, wie sie erdacht wurde?
Und auch dazu habe ich mittlerweile eine klare Meinung:
HELL, NO!
Zunächst mal: (agile) Methoden und Frameworks sind keine gesetzlichen Regelungen, sondern Vorgehens-Angebote, die dazu dienen sollen, kundenorientiert gute Ergebnisse zu liefern, Arbeitsabläufe kontinuierlich zu verbessern und die Zusammenarbeit der beteiligten Menschen zu erleichtern.
Jede der 23 Methodologien, die ich den vergangenen 20 Jahren kennengelernt habe, wurde in einem sehr speziellen Kontext entwickelt, viele davon in produzierenden Branchen. Das Wasserfall-Modell basiert auf der Idee des Informatik-Professors Winston W. Royce, der 1970 ein iterativ-inkrementelles Vorgehen als Alternative zur linearen Entwicklung beschrieb. Lean Management entstand im Zuge der Prozessoptimierung am Fließband der Automobilindustrie bereits in den 1950er Jahren bei Toyota. Die Six-Sigma-Methode wurde zur Qualitätsverbesserung in den 1980er Jahren bei Motorola erarbeitet (basierend auf einer Therorie aus den 1920ern) und später bei General Electrics und Toyota eingesetzt. Die Idee hinter Scrum aus dem Jahr 1995 ist die kundennähere, flexible Entwicklung von Software in IT-Unternehmen und greift die Idee von Lean Development auf. Und so weiter und so fort.
Jede dieser Methoden ist in irgendeiner Weise zumindest ideologisch mit den anderen Theorien verknüpft oder baut darauf auf. Und: Alle diese Methoden sind super effektiv und effizient – wenn alle Rahmenbedingungen dafür vorhanden sind und jede*r Beteiligte sich an die Spielregeln hält. Also in einem für die Methodik idealen Umfeld. Und eben genau in dem Kontext, in dem sie erdacht wurden.
Über die Jahre wurden fast alle dieser Methoden von Dienstleistungsunternehmen adaptiert – mit anderen Rahmenbedingungen, anderen Prozesslandschaften und abweichenden Organisationsstrukturen. Dass es dabei knirscht, erscheint mir plausibel.
Und deshalb zurück zu meiner Lieblingsfrage: was genau wollen wir mit der Einführung einer bestimmten Methodik erreichen?
MUT ZUM MIXEN
Ich gebe es zu: ich bin überzeugter Methoden-Junkie. Allerdings sind für mich die verschiedenen Tools und Formate aus den unterschiedlichen (agilen und nicht agilen) Methoden und Frameworks das wirklich wertvolle für meine Arbeit mit Teams in Organisationen. Und diese kombiniere ich nach Bedarf und situativer Zielsetzung, ohne direkt die gesamte Methodik zu implementieren:
Wir haben einen konkreten Handlungsanlass (zu Beginn oder auch bereits mitten im Projektverlauf), noch keine konkrete Lösung dafür und wollen schnell einige Ideen sammeln und ausprobieren? Hier nutze ich gerne das Effectuation-Format „Markplatz der Macher*innen“.
Wir haben schon eine ungefähre Vorstellung davon, was unser Kunde wünscht, nur fehlt uns noch eine konkretere Umsetzungs-Idee? Gut funktioniert haben hierbei in mehreren Projekten einzelne Schritte aus Strategic Design Thinking.
Uns ist zu Beginn der Anforderungsaufnahme (Anforderungskatalog oder Product Backlog) weder der aktuelle End-to-End-Prozess vollends klar, noch was genau mit unserer Veränderung verbessert werden sollte? Da hilft eine Wertstromanalyse (Value-Stream-Mapping) mit Erarbeitung der Kaizens (Verbesserungspotenziale), Ableitung des Soll-Prozesses und Erstellen einer Informationsstrukturanalyse (Lean Management Techniken).
Wir wollen das Produkt iterativ entwickeln, sind aber innerhalb (und oft auch außerhalb) der Organisation mit dem Projekt abhängig von zusätzlichen Test-Vorgaben und Release-Planungen anzubindender Schnittstellen? Dann orientieren wir uns im Team an Scrum (also: Entwicklung in Sprints unter Nutzung der hilfreichen Events, wie Daily, Sprint Review und Retrospective Meeting) und passen dabei die Länge der Sprints und das tatsächliche Deployment unserer Inkremente an diese Vorgaben an.
Wir haben keinen Changemanager im Projekt und wollen sicher gehen, dass wir dennoch unsere Nutzer richtig einbinden? Hierbei unterstützen uns die fünf Elemente des ADKAR-Modells nach Prosci.
Mit anderen Worten: ich baue in jedem Projekt ein individuelles hybrides Vorgehen basierend auf einem Werkzeugkasten, der stetig wächst.
WAS BRAUCHT ES DAFÜR?
Nach meiner Erfahrung sind insbesondere die folgenden 4 Aspekte hilfreich:
EIN KLARES ZIELBILD
Hinter jeder Veränderung steht die Frage nach dem „wofür?“. Welche strategische Ambition verfolgen wir? Was ist unser Handlungsanlass? Ist die aktuelle Situation nicht mehr tragfähig (weg von)? Haben wir eine für uns innovative Idee (hinzu)? Dies gilt es – so genau wie möglich – zu beschreiben. Dazu bedarf es keines umfassenden Fachkonzeptes. Vielmehr sind es Intention und Vision, die hier beschrieben werden dürfen – und zwar so genau, dass sie auch jeder versteht. Große hypnotische Worte, wie „Erfolg“, „Marktführerschaft“ oder „Nachhaltigkeit“ dürfen dabei genau erklärt werden. Was ist nachher für uns anders? Und: woran genau werden wir merken, dass wir unser Zielbild erreicht haben (oder auch nicht)?
Eine genaue Beschreibung dieser Veränderung hilft dabei, dass alle Beteiligten wissen, worum es wirklich geht, um in dem Zielbild einen persönlichen Sinn zu erkennen und sich darauf zu committen. Denn das persönliche Committment ist eine der wichtigsten Voraussetzungen für erfolgreiche Selbstorganisation von Teams.
INSIGHTS
Hilfreich für agile Transformation ist ein fundiertes „Insider-Wissen“ dazu, was genau die aktuelle Organisation ausmacht. Worin sind wir heute schon stark? Was läuft bereits besonders gut? Und was wird heute so gemacht, wie es eben gemacht wird, weil das schon immer so war und darf mal kritisch hinterfragt werden?
Diese Informationen können auf unterschiedliche Arten – und je nach Größe der Organisation – ermittelt werden: beispielsweise durch ein Retrospektiv-Meeting mit den Stakeholdern, Einzelinterviews mit Management und Mitarbeitenden, facilitierten Workshops in größeren Gruppen. Hierbei werden bereits wertvolle Hinweise auf Verbesserungspotenziale sichtbar, auf die in der Planung der Maßnahmen aufgesetzt werden kann.
METHODEN-VERSTÄNDNIS
Zum Mixen verschiedener Formate und Tools sind zwei Dinge sehr hilfreich: ein umfangreiches Methoden-Know How und ein systemisches Verständnis für Organisationen. Und dazu gehört vor allem Erfahrung: Was genau erreiche ich womit und welche Auswirkungen hat das auf die Organisation?
Bei leichtem Halskratzen ist es vermutlich ausreichend, im Internet eigenständig nach einem Hausmittel zu recherchieren. Bei anhaltenden Schmerzen in der Herzregion würde ich eher einen Kardiologen aufsuchen. Also einen Profi.
Ähnlich verhält es sich auch bei agiler Transformation: ein Profi als Sparringspartner, Trainer und Berater ist eine gute Sache. Und dabei ist es wichtig, dass dieser Profi auch bereit ist, sein Wissen und seine Erfahrung mit den Menschen in der Organisation zu teilen – im Sinne von Hilfe zur Selbsthilfe. Denn: meinen Job als externer Agile Coach habe ich dann gut gemacht, wenn mich mein Kunde nicht mehr braucht.
MUT ZU KLEINEN SCHRITTEN
Lao Tzu wird der Satz zugeschrieben: „Eine Reise von tausend Meilen beginnt mit einem einzigen Schritt.“ Auch bei agiler Transformation bietet es sich an, in kleinen Schritten zu starten und die Roadmap iterativ zu entwickeln.
In einem Unternehmen, das bis heute noch Projekte im strikten Wasserfall-Modell durchgeführt hat und stark geprägt ist durch Standardprozesse mag es für die Organisation sinnhafter sein, mit einem individuell abgestimmten hybriden Modell zu starten, statt direkt alle Projekte auf Scrum umzustellen.
Hybrides Projektmanagement ist eine Kombination aus agilen und traditionellen Ansätzen. Es ist eine Lösung, die auf die spezifischen Anforderungen eines Projekts zugeschnitten ist und die Vorteile beider Ansätze nutzt.
Das gibt den Menschen in der Organisation die Chance, in die Veränderung rein zulernen und das Vorgehen und fachliche Schnittstellen kontinuierlich und iterativ – also agil – zu transformieren.