In einer Reihe von Blogbeiträgen gehe ich auf die Frage ein: Was ist bei Agile schief gelaufen? Falls Sie den einleitenden Blogbeitrag noch nicht gelesen haben (Was ist bei Agile schief gelaufen?) Ich schlage vor, dass Sie zuerst dorthin gehen, bevor Sie hier weiter lesen.
Als ich 2006 mit der Anwendung von Agile-Methoden begann, gab es einen dominierenden Rahmen. Es war Scrum und um ehrlich zu sein, dachte ich anfangs, dass Agile Scrum sei und Scrum Agile. Wie falsch ich doch lag. Damals gab es einen dominanten Spruch: "Scrum ist einfach, aber schwer zu machen." Ich glaube, sie hatten Recht. Aber auf die Frage, wie man die schwierigen Teile erleichtern kann, schien die Antwort zu lauten: "Mach es nach dem Buch! Wiederhole es immer und immer wieder, bis du es richtig machst, denn wenn du den Scrum-Leitfaden nicht buchstabengetreu befolgst, machst du kein Scrum, sondern ein Scrum-aber!"
Ich hatte damit wirklich zu kämpfen, denn zu diesem Zeitpunkt versuchte ich zusammen mit einer Reihe großartiger Kollegen, Scrum in der Full-Stack-Entwicklung verschiedener Audioprodukte zu implementieren - genau wie Nonaka und Takeuchi schlugen vor (wir kannten ihre Arbeit zu diesem Zeitpunkt einfach noch nicht). Es war wirklich schwer für uns, jede dritte Woche ein potenziell veröffentlichungsfähiges Gitarrenpedal, einen Bassverstärker oder eine Computerschnittstelle zu haben. Wir mussten nach Scrum vorgehen, aber. Wir schafften den Turnaround des Unternehmens und viele Arbeitsplätze wurden gerettet. Von da an war es mir egal, ob ich Scrum-but mache oder nicht, solange es sinnvoll ist und funktioniert.
Ich habe daraus gelernt, dass man Rahmenbedingungen nicht ignorieren und denken sollte, dass alles möglich ist. Ganz und gar nicht! Es war vielmehr so, dass Rahmenwerke einem Orientierung geben können. Allerdings wissen diejenigen, die den Rahmen definiert haben, nicht alles (auch wenn einige von ihnen das fast behaupten). Sie kennen vor allem nicht die Details Ihres Kontexts - das wissen nur Sie und Ihre Kollegen -, so dass Sie sich anpassen müssen, und manchmal bedeutet das sogar, die Regeln des Rahmens zu biegen oder zu brechen. "Individuen und Interaktion vor Prozessen und Werkzeugen" als erster Wert in der Agile Manifest Staaten.
Im Laufe der Zeit wurden verschiedene Agile-Rahmenwerke eingeführt. Die meisten von ihnen beziehen sich darauf, wenn die Arbeit über ein Team hinausgeht: LeSS, Nexus, Scrum @ Scale, SAFe und das neueste unFIX. Einige waren sogar davon überzeugt, dass es etwas gibt, das Spotify-Modell genannt wird. Das gibt es aber nicht.
In Bezug auf das Marketing war SAFe am erfolgreichsten, aber wenn es um die Ergebnisse geht, habe ich keine Beweise dafür gesehen, dass eine von ihnen besonders besser oder schlechter ist als die anderen. Ich bin auch nicht besonders für oder gegen eine von ihnen.
Es gab die Tendenz, dass insbesondere SAFe ein Thema für Do-it-by-the-book-Implementierungen war, bei denen alle Rollen, Artefakte und Ereignisse blind nach einem Handbuch implementiert wurden. Ich bin mir nicht sicher, ob dies die ursprüngliche Absicht von SAFe war, also warum ist es dazu gekommen?
Nun, einige Beratungsunternehmen verkaufen Agile von der Stange, indem sie der Illusion folgen, dass die Umwandlung einer Organisation in agile nach einem vorhersehbaren Plan erfolgen kann. Ihren Kunden gefällt diese Vorstellung, denn sie vermittelt ihnen ein Gefühl der Kontrolle. Für die Umsetzung verfolgen sie einen Ansatz mit klaren Lieferterminen und stellen ihre Rechnungen entsprechend aus. Ironischerweise verwenden sie für die Umsetzung von Agile einen Wasserfall-Ansatz, der eher auf dem Output als auf dem Ergebnis basiert.
Die Implementierung von Agile ist nichts, was Sie an jemand anderen auslagern können. Es ist etwas, das Sie selbst in die Hand nehmen müssen. Und warum? Weil eine dauerhafte Veränderung nur dann möglich ist, wenn die Dinge für die Menschen Sinn machen, für diejenigen, die die Arbeit machen, und für diejenigen, die die Veränderungsinitiative leiten. Für letztere ist ihr Verständnis der Organisationsdynamik und -kultur entscheidend für den Erfolg. Siehe einen meiner frühere Blogbeiträge für eine Diskussion über dieses Thema.
Ihre agile-Implementierung muss nicht nur Ihnen selbst gehören, sondern auch Ihrem Kontext entsprechen. Es muss ein Gleichgewicht zwischen der Herausforderung Ihres Kontextes und der Anpassung an ihn bestehen. Es gibt keine Blaupause, der Sie folgen können. Sie müssen den Weg selbst finden. Natürlich können Sie sich von Beratern leiten lassen, die über umfangreiche Erfahrungen mit dem Prozess der Umgestaltung von Organisationen verfügen, aber halten Sie sich von denen fern, die mit großem Selbstvertrauen behaupten, sie wüssten genau, was zu tun ist. Suchen Sie stattdessen diejenigen, deren Fähigkeiten größer sind als ihr Ego - diejenigen, die wissen, dass eine Aufgabe wie diese zuallererst mit Bescheidenheit angegangen werden muss.
In meinem nächsten Blog-Beitrag werde ich ein weiteres agile-Missgeschick ansprechen, das mit dem heutigen Thema zusammenhängt: Alle Rahmen sind falsch, außer meinem. Darin werden wir uns mit der wachsenden Zahl von Rahmenwerken befassen, mit den Gründen, warum so viele auftauchen und ob sie tatsächlich relevant sind. Bleiben Sie dran und denken Sie auch an abonnieren Sie unseren Newsletter für ein monatliches Goodiebag mit agile-Inspiration.















