Zum ersten Mal in Kontakt mit Agilen Methoden bin ich 2015 gekommen. Es war ein einem Projekt zur Digitalen Kontoeröffnung in einer Schweizer Großbank. Dort war noch keine Vorgabe, nach Agilen Methoden zu arbeiten, aber wir hatten einen Scrum-Master in unserem Projekt. Darüber bin ich das erste Mal mit Scrum in Berührung zu kommen und war begeistert von den Grundprinzipien. Das bin ich bis heute, denn das Agile Manifest sprach auch mir aus der Seele.

Ich bekam die Gelegenheit, an den internen Schulungen mit teilzunehmen und wurde so als Scrum Master und Product Owner ausgebildet. Das meiste hat uns als Projektteam gut gefallen und wir haben einiges davon ausprobiert und übernommen, anderes nach kurzes Zeit weggelassen (zum Beispiel das Scrum Poker).

Bald darauf wurde Agiles Arbeiten in dem Unternehmen in den Projektbereichen eingeführt. Hier durfte ich die erste Transformation miterleben. Nun passierten zwei Dinge, die zu negativen Erfahrungen geführt haben. Zum einen kam eine kleine Heerschar von Scrum Master und missionierte uns. Ich wähle bewusst "missionierte", denn in deren Welt war Scrum die Antwort auf alle Mißstände, alle bisherigen Ansätze schlecht und es sie waren nicht an einer kritischen Auseinandersetzung interessiert. Dies habe ich später in anderen Unternehmen wiederholt so erlebt. Missionare vergleichen dabei gern Agiles Projektmanagement mit der Wasserfallmethode und meinen damit die ursprüngliche stark sequentille From aus den 60er Jahren. Dieser Vergleich ist aber unredlich, da alle Projektmangement-Ansätze, die ich in verschiedenen Unternehmen kennen gelernt habe, auch schon darauf ausgelegt waren, möglichst gut auf Veränderungen zu reagieren. Das Argument im Grundsatz bleibt richtig, Agiles Projektmanagement ist hier deutlich stärker, aber es ist kein schwarz-weiß.
zum anderen waren die neuen Scrum-Prozesse nicht im Unternehmen verankert, sondern nur in einem Tei davon. So war die Steuerung aus dem Management (wie zum Beispiel der Budgetierungsprozess) nach wie vor auf die alten Prozesse ausgelegt und Zuständigkeiten, Kontroll- und Steuerungsansätze blieben ebenfalls erhalten, wie sie waren. So funktionierte Scrum (nach natürlichen anfänglichen Schwierigkeiten) im kleinen Kosmos der Einheit recht gut, Schnittpunkte nach Außen waren chaotisch.

Ich hatte als freiberuflicher Projektleiter das Glück, die Einführung von Agilen Methoden in verschiedenen Unternehmen mitzuerleben. Neben der Erkenntnis, dass dies eine sehr große Transformation bedeutet (mit allen Phasen von Veränderungsprozessen (Starre, Ablehnung, Akzeptanz, Adaption und Optimierung) habe ich wiederholt erlebt, das die Betroffenen unzureichend mitgenommen werden, was zu langfristiger Ablehnung, Frust und Leistunsabfall bei Teilen der Mitarbeitenden führt. Zudem hatte ich in den mir bekannten Frameworks keine Antwort auf einige Fragen gefunden, die mir wichtig erschienen:

• Wie schafft man es in großen Unternehmen, nicht so viele Mitarbeitende auf der Strecke zu lassen?
  Fallbeispiel: Viele gute Programmierer haben die Transformation nicht gut geschafft und stark in Ihrer Leistung nachgelassen. Das führt für die Unternehmen zu deutlich spürbarem Leistungsabfall und die Betroffenen zu zum Teil großen persönlichen Krisen in ihrem beruflichen Selbstbild. Die gängige Antwort, erst mal mit einem kleinen Kreis von überzeugten Personen anzufangen und dadurch die anderen zu überzeugen und diejenigen, die diese Transformation nicht machen können, zu ersetzen, klappt nicht. Das kann vielleicht für eine kleines Start-Up funktionieren, für ein großes Unternehmen aus mehreren Gründen nicht. Zudem ist es oft nicht der fehlende Wille, sondern die Betroffenen können es schlichtweg nicht. Älteren Programmierern wurde 30 Jahre gesagt, dass sie genaue Vorgaben bekommen, die sie umzusetzten haben mit kleren Rollenverteilungen. Plötzlich finden sie sich in einem Team wieder, in der Aufgaben nicht mehr so klar sind (Pull Prinzip), ein Team sich selbst organisieren soll, eigenverantwortlich agiert und Probleme transparent gemacht und von allen gelöst werden. Die Lösung dazu ist sicher nicht, ein "Agiles Mindset" für einen halben Seminartag näherzubringen und danach zu erwarten, dass dieses danach gelebt wird.
• Wie vermeidet man die Bildung neuer Silos?
  Ganz oft höre ich als eins der positivsten Argumente, dass es jetzt kein Silodenken mehr gibt, weil IT- und Fachexperten nun in produktorientierten Teams zusammen arbeiten. Ich halte das für Unfug, wir bauen nur neue Silos auf.
  Kurzfristig ist dieser Effekt sicher da, aber langfristig wird es dazu führen, dass in Produktsilos gedacht wird. Schnittstellen zwischen Produkten oder eine effiziente IT-Architektur blieben dabei auf der Strecke, wenn nicht weitere Maßnahmen ergriffen werden.
• Wer übernimmt Führungsfunktionen, wenn das Middle-Management wegfällt?
  Konsequent umgesetzt, gibt es die klassischen Führungsfunktionen nach der Transformation nicht mehr. Das führt während der Transformation dazu, dass einige Aufgaben nicht mehr besetzt sind. Wer entscheidet über Beförderungen oder Urlaubsfreigaben im Konfliktfall? Häufig werden hier Lösungen gefunden, dass es weiter disziplinarische Führung gibt. Das wirft allerdings einige neue Fragen und mögliche Kompetenzunklarheite auf. Wiederholt erlebt habe ich, dass gerade die mittlere Führungsebene massiv gegen eine Agile Transformation arbeitet, weil es ihre bisherige berufliche Stellung massiv verändert.

Das war der Grund für mich, warum ich mich 2021 entschieden haben, eine umfangreiche Ausbildung zum zertifizierten Agile Coach ausbilden zu lassen. die Ausbildung war gut (außer das fast alle meine Vorurteile zu Bildungszertifikaten bestärkt wurden) und seit dem 28. September 2022 bin ich Agile Coach nach dem IFAAI-Standard, unterzeichnet von einem der 17 Autoren des Agilen Manifest.

Ich bin nach wie vor Fan von Agilen Methoden und sehe viele gute Gründe, diese einzuführen. Bei der Einführung brauchen wir aber Zeit, um dies mit einem breit aufgestellten Change Management zu begleiten. Hybride Ansätze halte ich für die Transformation für sehr geeignet. Agiles Projektmanagment hat aber nicht nur Vorteile und es gibt nach wie vor Projekte, die ich lieber klassisch durchführe, als agil.