In einer Serie von Blogbeiträgen wird die Frage untersucht: Was ging schief mit Agile? Wer den einleitenden Beitrag (Was ging schief mit Agile?) noch nicht gelesen hat, sollte dort zuerst weiterlesen.

Als 2006 begonnen wurde, Agile-Methodiken anzuwenden, gab es ein dominantes Framework. Es war Scrum, und ehrlich gesagt wurde anfangs gedacht, Agile sei Scrum und Scrum sei Agile. Wie falsch das war. Damals gab es einen dominanten Spruch: "Scrum ist einfach, aber schwer umzusetzen." Vermutlich hatten sie recht. Aber bei Fragen dazu, wie die schwierigen Teile erleichtert werden könnten, schien die Antwort Variationen von Folgendem zu sein: "Mach es nach Lehrbuch! Wiederhole es immer wieder, bis es richtig ist, denn wenn der Scrum Guide nicht buchstabengetreu befolgt wird, macht man kein Scrum, sondern Scrum-but!"

Damit gab es echte Schwierigkeiten, denn zu diesem Zeitpunkt wurde gemeinsam mit einigen großartigen Kolleg:innen versucht, Scrum in der Full-Stack-Entwicklung verschiedener Audioprodukte einzuführen, ganz wie Nonaka und Takeuchi vorschlugen (ihre Arbeit war zu diesem Zeitpunkt noch nicht bekannt). Es war wirklich schwer, alle drei Wochen ein potenziell veröffentlichbares Gitarrenpedal, einen Bassverstärker oder ein Computer-Recording-Interface zu haben. Es musste Scrum-but gemacht werden. Die Wende des Unternehmens gelang, und viele Arbeitsplätze wurden gerettet. Von da an war es egal, ob es Scrum-but war oder nicht, solange es Sinn ergab und funktionierte.

Die Lehre daraus war nicht, Frameworks zu ignorieren und zu denken, alles sei erlaubt. Absolut nicht! Es war eher, dass Frameworks Orientierung geben können. Diejenigen, die das Framework definiert haben, wissen jedoch nicht alles (auch wenn manche das fast behaupten). Sie kennen besonders nicht die Details des jeweiligen Kontexts, nur die eigenen Kolleg:innen tun das, weshalb Anpassung nötig ist, und manchmal bedeutet das sogar, die Regeln des Frameworks zu biegen oder zu brechen. "Individuen und Interaktionen über Prozesse und Werkzeuge", wie der erste Wert des Agile Manifest besagt.

Über die Zeit wurden verschiedene Agile-Frameworks eingeführt. Die meisten davon betreffen Arbeit, die über ein Team hinausgeht: LeSS, Nexus, Scrum @ Scale, SAFe und zuletzt unFIX. Manche waren sogar überzeugt, es gäbe etwas namens das Spotify-Modell. Das gibt es nicht.

Marketingmäßig war SAFe am erfolgreichsten, aber wenn es um Ergebnisse geht, gibt es keinen Beweis, dass eines davon besonders besser oder schlechter ist als die anderen. Es besteht auch keine besondere Vorliebe für oder gegen eines davon.

Es gab eine Tendenz, dass besonders SAFe Gegenstand von Nach-Lehrbuch-Einführungen wurde, bei denen alle Rollen, Artefakte und Events blind nach einem Handbuch implementiert wurden. Das war vermutlich nicht die ursprüngliche Absicht von SAFe, wie kam es also dazu?

Nun, manche Beratungsunternehmen verkaufen Agile von der Stange, der Illusion folgend, dass die Transformation einer Organisation zu Agile nach einem vorhersehbaren Plan erfolgen kann. Ihre Kund:innen mögen diese Idee, weil sie ein Gefühl von Kontrolle vermittelt. Für die Umsetzung folgen sie einem Ansatz mit klaren Lieferungen, und stellen entsprechend Rechnungen. Ironischerweise nutzen sie damit einen Wasserfall-Ansatz, um Agile einzuführen, basierend auf Output statt Outcome.

Agile einzuführen ist nichts, was an andere ausgelagert werden kann. Es ist etwas, das selbst verantwortet werden muss. Warum? Weil für nachhaltigen Wandel Dinge für die Menschen Sinn ergeben müssen, sowohl für die, die die Arbeit leisten, als auch für die, die die Wandelinitiative leiten. Für Letztere ist das Verständnis organisatorischer Dynamik und Kultur essenziell für den Erfolg.

Neben der Eigenverantwortung muss die eigene Agile-Einführung auch zum eigenen Kontext passen. Es braucht eine Balance zwischen dem Herausfordern des eigenen Kontexts und der Anpassung an ihn. Es gibt keine Blaupause, der gefolgt werden kann. Der eigene Weg muss selbst gefunden werden. Beratung durch Menschen mit umfangreicher Erfahrung im Transformationsprozess von Organisationen kann natürlich unterstützen, aber es lohnt sich, jene zu meiden, die mit enormem Selbstbewusstsein behaupten, genau zu wissen, was zu tun ist. Gesucht werden sollten stattdessen jene, deren Fähigkeiten größer sind als ihr Ego, jene, die wissen, dass eine solche Aufgabe zuallererst mit Demut angegangen werden muss.

Im kommenden Beitrag geht es um eine weitere Agile-Panne, verwandt mit dem heutigen Thema: Alle Frameworks sind falsch, außer meinem. Dort wird die wachsende Zahl an Frameworks behandelt, die Gründe für ihre Verbreitung, und ob sie tatsächlich relevant sind.