In dieser Folge von No Bullshit Agile widmet sich Thomas der Frage, ob Agilität wirklich tot ist – eine These, die in letzter Zeit immer häufiger diskutiert wird. Ausgangspunkt ist ein Heise-Artikel, der das Thema aufgreift. Thomas beleuchtet die häufigsten Kritikpunkte an Agilität, wie „Fake Agile“, „Dark Agile“ und die Kommerzialisierung agiler Methoden. Ein wichtiger Punkt dabei ist, dass Agilität oft missverstanden und falsch angewendet wird, was zu Frustration führt.

Thomas plädiert für ein "Back to Basics" – das Verständnis und die Umsetzung der Grundprinzipien des Agilen Manifests, bevor man sich Methoden wie Scrum oder Kanban widmet. Als Hilfsmittel hat er das Konzept eines "Agile Tech-Tree" entwickelt, das verdeutlicht, wie wichtig es ist, zuerst die Grundlagen zu beherrschen, bevor man weitergeht.

Thomas freut sich auf eure Meinungen und den fachlichen Austausch. Lasst uns diskutieren, wie wir Agilität wirklich leben können und sie nicht als reines Management-Tool missbrauchen.

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche jede Woche Themen aus der Agilenteam-Projektwelt. Dabei orientiere ich mich an den großen Kategorien Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt auf der Praxis, daher auch der Name No Bullshit Agile.

In der letzten Folge habe ich mir ein paar Gedanken gemacht zum Agilen Manifest, wo das herkommt, was damals die Basis war, und daraus abgeleitet ein kleines Gedankenexperiment. Wenn dich das interessiert, dann hör da gerne rein. Den Link zu der Folge findest du in den Shownotes.

Das hier ist die Folge 30 und heute möchte ich euch erklären, warum Agilität meiner Meinung nach nicht tot ist. Bevor wir da einsteigen, erstmal ein bisschen Housekeeping. Vor allem ganz, ganz vielen Dank an alle, die auf Mastodon so regelmäßig mit mir über Themen diskutieren. Das nimmt jetzt wirklich von Woche zu Woche zu. Das freut mich total. Wie gesagt, sage ich immer wieder in Folgen: Mir geht es mit diesem Podcast vor allem um den Austausch und, auch das sage ich immer wieder gerne, um den kritischen Austausch. Ich habe bestimmt nicht das Wissen hier geparkt für mich und hoffe, dass die Diskussion anderen hilft, darüber nachzudenken, was Agilität in der Praxis bedeutet. Deswegen hier nochmal vielen, vielen Dank an alle, die so regelmäßig in den Austausch mit mir gehen. Schöne Grüße!

Ja, kommen wir zum Thema der aktuellen Folge. Das Thema ist durch einen Heise-Artikel aufgetaucht, den ich natürlich auch in den Shownotes verlinke. Der Artikel lautet „Scrum, XP und Co.: Warum keiner mehr agil arbeiten will“. Ich lese immer wieder gerade in letzter Zeit Artikel, die sich damit beschäftigen, dass Agilität wohl tot ist. Dieses Thema passt super in viele Folgen, die ich in letzter Zeit aufgenommen habe, zum Beispiel in die letzte Folge 29. Das Thema, das ich dort behandelt habe, passt gut rein, aber auch in viele weitere, auf die ich später in der Folge nochmal eingehen werde.

Die Kernaussagen sind dann: Agilität hat uns nicht geholfen, Agilität funktioniert nicht und wir müssen etwas anders machen. Bei „Wir müssen etwas anders machen“ frage ich mich: Was denn? Was ist denn die Alternative zu Agilität?

In dem Heise-Artikel kommt dann ein Fazit, das ich ehrlich gesagt ganz gut finde und dem ich auch wirklich zustimme. Das erste, warum das so ist, ist „Fake Agile“, nämlich Unternehmen führen Agilität falsch ein und nutzen Agilität falsch. Oft genug ist es so, dass Leute sagen: „Oh, wir müssen agil sein“ und Agilität einführen wollen und dann zum Beispiel Scrum nehmen, weil Scrum sicherlich eine Art Einstiegsdroge ist – es ist halt sehr klar erklärt – aber die Basis dazu gar nicht haben. Warum führen wir Scrum ein und was bedeuten die einzelnen Regeln und Definitionen im Scrum Guide?

Der zweite Fall ist „Dark Agile“, nämlich mit Absicht eine Methode wie zum Beispiel Scrum einführen, um sie nur noch als Deckmantel zu benutzen und dann doch wieder aus dem Management heraus zu steuern und zu kontrollieren und eher wasserfallartig vorzugehen. Ich glaube – und das steht so auch im Artikel und dem stimme ich auch zu – eine dritte große Säule, warum dieses „Agil ist tot“ immer wieder kommt oder Leute das feststellen, die in einer, ich mache jetzt Gänsefüßchen in der Luft, „agilen Welt“ leben, dass es alles ehrlich gesagt gar nichts bringt, das ist ja eben so dann immer die Meinung zu „Agilität ist tot“. Ich glaube, ein dritter Teil davon ist eben die Kommerzialisierung, also Zertifikatsfluten, unheimlich viele Leute, die alle möglichen Arten von Zertifikaten erfunden haben.

Das ganze Thema „Agile Coach“-Coaching-Fluten, versteht mich nicht falsch, ein guter Agile Coach bringt sicherlich einen richtig guten Mehrwert, aber auch die sind ja alle wie Pilze aus dem Boden geschossen. Diese ganze Kommerzialisierung führt natürlich dazu, dass man immer mehr Dinge auch erfindet rund um Agilität: „Scrum von Scrum“, „Flight Level“, alles, was so dazugehört, weil man ja immer mehr Zertifizierungen erfinden muss, damit man halt eben so ein Geld verdienen kann.

Dann gibt es noch einen ganz extra Punkt für mich: Viele Leute reden oft von digitaler Transformation und hängen da immer Agilität dran oder andersherum: Agilität gehört zur digitalen Transformation. Für mich – und vielleicht ist das ein bisschen picky oder so, ich weiß es nicht – hat das eine mit dem anderen überhaupt nichts zu tun. Für mich ist digitale Transformation etwas viel Größeres und etwas ganz anderes. Nur weil man jetzt an der Stelle über Agilität nachdenkt oder Scrum einführt, um das so ganz platt zu sagen, hat man ja noch längst keine digitale Transformation gemacht. Deswegen denke ich bei dem Punkt immer: Was hat das eine mit dem anderen zu tun?

Ja, erstes Fazit aus diesem Artikel ist für mich halt eben ganz klar: Er stellt meine Sichtweise zu dem dar, was ich immer sage, nämlich „Back to Basics“. Es geht meiner Meinung nach darum, das Agile Manifest erstmal zu verstehen. Wenn es euch interessiert, was da im Detail meine Meinung zu ist, verlinke ich euch gerne in diesem Fall ganz konkret drei Folgen. Das sind die Folge 5, die Folge 6 und die Folge 29, wo ich mich mit diesen Basics nochmal beschäftigt habe. Denkt mal ein bisschen mehr und ein bisschen länger und intensiver über die Basics nach, unabhängig von irgendwelchen Methoden wie XP oder Scrum oder Kanban, und schaut mal, wann überhaupt die Anwendung von Agilität sinnvoll ist.

Interessanterweise zu diesem ganzen Thema sinnvolle Anwendung gab es auf Mastodon einen super interessanten Thread von Martin – schöne Grüße, auch den verlinke ich gerne. Martin sagt wirklich einfach genau diesen Kern, und das passierte alles die Woche über, ganz lustig. Ich lese das einfach mal vor: Also Martin schreibt, „Agilität lebt, wo Time to Market und Cost of Delay wichtige Metriken sind, wo es starken Marktwettbewerb, disruptive Technologie und sich schnell ändernde Kundenerwartungen gibt. Agilität ist tot, wo sie sich zu weit von ihrem eigentlichen Anwendungskonzept wegbewegt, sie zum Boxed Product für alle werden will, dadurch einfache Rezepte verkauft werden, die die organisationale Komplexität ins Unendliche steigert. Durch hohe Erwartungen kommt es zu überhöhter normativer Aufladung.“

Das ist wirklich genau dieser Punkt, ein ganz wichtiger Ausschnitt in dieser komischen Diskussion zu „Agilität ist tot“. Ich würde nämlich mal als Zwischenfazit sagen: Die Interpretation der Agilität ist super oft fehlgeleitet und das ist das allergrößte Problem. Leute denken, sie wären in einem Unternehmen, das agil arbeitet, und sind dann frustriert. Das kann ich auch nachvollziehen, weil die Basis in diesem Unternehmen einfach komplett fehlt – mit Absicht, „Dark Agile“ oder nicht mit Absicht durch Unwissenheit, dann würde ich auch eher sagen „Fake Agile“. Leider ist es gerade bei Scrum so, dass das oft missbraucht wird.

Ich habe mal eine Folge gemacht, da sage ich unter anderem: Scrum ist oft nur ein Management-Tool. Das liegt an Folgendem: Scrum ist einfach zu verstehen. Also, ich habe den Scrum Guide, der erklärt alle Rollen, der erklärt das Verfahren, der erklärt alle Rituale und wenn ich mich daran halte, sage ich jetzt einfach mal, dann mache ich auch Scrum. Aber die Basis fehlt, das Basiswissen, und man muss insofern tatsächlich nichts von Agilität verstehen und kann einfach dieses Scrum-Playbook benutzen und loslegen. Und das ist genau das Problem von Scrum.

Scrum ist da eine riesen Zwickmühle. Auf der einen Seite ist diese Klarheit und diese Einfachheit natürlich ganz toll und meiner Meinung nach auch der Hauptgrund, warum Scrum neben anderen agilen Methoden oder im Vergleich zu anderen agilen Methoden einfach so eine große Reichweite erzielt hat und so bekannt ist. Auf der anderen Seite ist es eben genau die Last, die Scrum trägt, dass Leute einfach sagen: „So, wir machen Scrum, wir sind jetzt agil“ und überhaupt nicht verstanden haben, dass man auch Scrum machen kann, ohne ein Stück agil zu sein. Erschreckend, aber so ist es. Da kann Scrum eigentlich gar nichts für, aber es ist sicherlich eine große Last, die Scrum da trägt und manchmal wird Scrum eben wirklich als Deckmantel benutzt.

Wir wollen ein modernes Unternehmen sein, vielleicht für neue Mitarbeiterinnen und Mitarbeiter oder für Kunden, die sagen, wir wollen Scrum. Also kann man Scrum einführen und in Wirklichkeit hintenrum hat man aber ein Arbeitsumfeld, das zwar alle Regeln von Scrum einhält und, ich sage mal, alle Rituale und alles, was dazugehört, aber eben kein Stück agil ist. Das ist natürlich super frustrierend, vor allem für Kolleginnen und Kollegen, die in so einem Umfeld leben.

Ja, viele setzen heute tatsächlich grundsätzliche Agilität mit Scrum gleich, und viele haben einfach wenig Ideen dazu, was die Basis ist, zum Beispiel was das Agile Manifest ist, was es wirklich bedeutet und in welcher Situation ich überhaupt agil sein sollte und in welchen Situationen es, wie der Tweet oder das Zitat, das ich vorhin erwähnt habe, vielleicht gar nicht nötig ist oder manchmal sogar hinderlich sein kann.

Ich hatte eigentlich noch ein ganz gutes Bild dazu, um das irgendwie anders zu formulieren und anders anzufassen. Das Bild habe ich auch auf Mastodon veröffentlicht, das werde ich auch auf der Webseite zu dieser Folge veröffentlichen. Schaut da also gerne rein, der Link zu der Folge findet sich immer in den Shownotes.

Wenn ihr euch mal überlegt, in Computeraufbauspielen, vielleicht kennt ihr sowas wie Civilization oder andere Computeraufbauspiele, gibt es oft so einen Tech-Tree. Ich muss eine gewisse Art von Erfahrung in dem Spiel sammeln, um bestimmte Dinge freischalten zu können. Ich kann nicht sofort, sagen wir mal, eine Zweihandaxt in einem Spiel führen, sondern ich muss mit dem Messer anfangen oder so. Schritt für Schritt muss ich mir Erfahrung erarbeiten, XP in dem Spiel, um mich dann zu entscheiden, in so einem Technologiebaum, der auch stark verzweigt ist, welche Fähigkeit ich als nächstes freischalten möchte.

Dieses Bild habe ich mal gemalt und den Agile Tech-Tree genannt. Ich habe jetzt nicht da irgendwie einen riesigen Baum gemalt; einiges davon ist dann auch ausgeblendet. Aber für mich ist es halt so: Ich versuche, das Bild mal zu erklären. Ganz links startet es mit dem Agile Manifest. Ich habe da einfach dran geschrieben, man braucht 10 XP, um das Agile Manifest freizuschalten. Wenn man das freigeschaltet hat, kann man als nächstes die 12 agilen Prinzipien freischalten, mit 18 XP, habe ich hier reingeschrieben. Wenn man das freigeschaltet hat, verzweigt sich jetzt der Baum. Da kann ich mich entscheiden: Ich kann entweder Scrum freischalten für 20 XP oder Kanban für 15 XP und so geht das immer weiter.

Dieses Gedankenbild finde ich eigentlich ganz schön, denn es würde ja bedeuten, wenn man das in der Realität so haben könnte, dass man gezwungen ist, bevor man über irgendetwas Methodisches nachdenkt, zuallererst das Agile Manifest und die 12 agilen Prinzipien freizuschalten. Sonst kann ich gar keine agile Methode freischalten. Und wie gesagt, ich finde dieses Bild einfach sehr passend, wenn ihr euch mit Computerspielen, so Aufbau-Spielen, auskennt.

Deswegen, vielleicht nutzt ihr das mal in der Diskussion mit einem Team oder mit dem Management bei euch im Unternehmen, um irgendwie darauf zu kommen, dass wir auch diese Basis brauchen. Insgesamt ist mein Punkt einfach: Investiert so viel wie möglich, so viel Einfluss, wie ihr auch habt, um eurem Umfeld eine agile Basis zu erklären, und zwar immer und immer wieder. Investiert so viel Zeit wie möglich und solange keine große Zeit auf agile Methoden wie Kanban, Scrum oder XP und deren Einführung, bis das Umfeld wirklich verstanden hat, wann Agilität nötig ist und was sie überhaupt bedeutet.

So etwas wie "Time to Market" und solche Geschichten. Schlussendlich basiert das Agile Manifest darauf, dass man eben für seine Kunden Software liefern will, die schnell auf dem Markt ist. Alles Wiederholungen aus Folge 29, ich weiß, aber es ist wichtig, das alles zu verstehen, bevor man guckt: Wie nutzen wir die Agilität bei uns im Unternehmen? Was ist die richtige Methodik? Mir wäre es lieber, es ist irgendein Mischmasch aus Scrum, Kanban und XP, der aber wie ein Handschuh für euch passt, wo ihr wirklich sagt: "Okay, aber damit erfüllen wir wirklich diese Basis der Agilität, den Zweck der Agilität", als klar zu sagen: "Oh, wenn wir Scrum machen wollen, dann müssen wir aber unbedingt dieses Ritual und jenes so und so machen."

Lieber pragmatisch sein. Vielleicht nehmt ihr dann dieses Bild von diesem Tech-Tree aus dem Computerspiel und denkt an die Experience, die XP-Punkte, die man dann investieren muss, um die nächsten Schritte freizuschalten. Legt eben mehr Wert auf die Basis. Das wäre mein Appell für diese Folge: Back to Basics, eben No Bullshit Agile. Das ist einer der Hauptgründe, warum ich mit diesem Podcast angefangen habe. Ich habe immer mal wieder so Basisfolgen, Erklärfolgen oder Meinungsfolgen, aber vielleicht erkennst du das, wenn du ein paar mehr Folgen schon gehört hast. Dann sage ich an dieser Stelle vielen Dank. Es geht mir genau um diesen Punkt.

Ich möchte ganz gerne, dass Leute das Fundament und eben No Bullshit Agile verstehen. Es ist einfach Quatsch zu sagen, Agilität ist tot. Diese Aussage ist einfach, ja, ich bin fast gewillt zu sagen, diese Aussage ist dumm. Es liegt eigentlich immer nur daran, dass Agilität nicht richtig eingeführt, benutzt und gelebt wird.

Ja, und das ist tatsächlich so mein Plädoyer für diese Folge und damit denke ich auch, dass wir soweit durch sind. Ich bin wie immer total gespannt auf eure Meinung. Was erlebt ihr so in der Praxis? Gebt mir dazu gerne Feedback. Weiterhin ist mir die Diskussion einfach unheimlich wichtig. Ich freue mich auch über Kritik, gerade Kritik hilft mir zu wachsen. Aber wie gesagt, fachlich bin ich total an der Diskussion interessiert.

Wenn du fachlich in die Diskussion mit mir einsteigen willst, gibt es viele Kanäle, wie du mich erreichen kannst. Es gibt Mail, ganz klassisch. Du erreichst mich unter nobsagile@gmail.com, du findest mich auf Mastodon, wenn du einen Mastodon-Account hast. Es gibt begleitend zu dem Podcast ein Forum, und zu jeder einzelnen Folge gibt es auch einen Thread. Auch die sind immer in den Shownotes verlinkt. Deswegen gibt es genug Punkte, wo du mich erreichen kannst. Ich freue mich einfach über eine Diskussion.

Wenn dir die Folge gefallen hat, habe ich noch eine ganz große Bitte an dich: Teile die Folge gerne oder auch alle Folgen oder einfach die Webseite mit anderen, die sich für Agilität interessieren könnten – Kolleginnen und Kollegen, Chefs, Freunde, die woanders arbeiten und ähnliches tun, auf deinen Social-Media-Kanälen. Ich mache das Ganze hier in meiner Freizeit und es macht mir unheimlich viel Spaß. Aber es ist wirklich einfach so: Ich kann nicht mehr Leute erreichen, das muss sich verteilen. Und wenn dir das gefällt, ich brauche keine Spende oder irgendwas in der Art. Es ist für dich eigentlich schnell gemacht, das zu teilen, wenn es dir gefällt oder mit jemandem darüber zu reden, und du tust mir einfach einen riesigen Gefallen. Deswegen sage ich an der Stelle schon mal vielen, vielen Dank dafür.

Ansonsten habt noch eine ganz tolle Woche und bis zum nächsten Mal!

NBA30: Warum Agilität nicht tot ist

Shownotes

Zusammenfassung

Transkript

Featured

Subscribe

Tags