NBA15: Warum so viele scheitern: Agilität ist ein Mindset!

Thomas 17 Mai 2024 Podcast

Shownotes

Über Feedback freue ich mich immer: nobsagile@gmail.com. Ihr erreicht mich auch auf Mastodon unter https://mastodon.social/@nobsagile.

Kommentare und Diskussion gerne hier: https://forum.no-bullshit-agile.de/d/31-nba15-warum-so-viele-scheitern-agilitaet-ist-ein-mindset

—

Letzte Folge NBA14: Peer Feedback

https://no-bullshit-agile.de/nba14-peer-feedback.html

NBA05: Ist das Agile Manifest noch relevant?

https://no-bullshit-agile.de/nba05-ist-das-agile-manifest-noch-relevant.html

NBA06: Die 12 Agilen Prinzipien

https://no-bullshit-agile.de/nba06-die-12-agilen-prinzipien.html

Umfrage

Zusammenfassung

In Folge 15 von No Bullshit Agile geht Thomas der Frage nach, warum viele Agile-Implementierungen scheitern und erklärt, dass Agilität vor allem eine Denkweise, ein Mindset ist. Viele Organisationen missverstehen Agilität und verwechseln sie mit der Nutzung von Frameworks wie Scrum oder Kanban, ohne das zugrunde liegende Prinzip zu verstehen.

Thomas hebt hervor, dass Agilität nicht einfach bedeutet, Methoden oder Tools zu verwenden, sondern eine Haltung erfordert, die Flexibilität und kontinuierliches Lernen betont. Die Essenz von Agilität liegt darin, sich an sich ändernde Anforderungen und neue Erkenntnisse anzupassen, anstatt starr an vorab definierten Plänen festzuhalten.

Er erklärt, dass Agilität besonders dann wichtig ist, wenn Projekte Neuland betreten, unklare Anforderungen bestehen und kontinuierliches Feedback notwendig ist. In solchen Fällen ist Agilität der effektivste Ansatz, um Verschwendung zu vermeiden und echten Wert zu schaffen.

Abschließend betont Thomas, dass die Implementierung von Agilität mehr ist als das Befolgen von Regeln; es erfordert das Verinnerlichen der Agilitätsprinzipien und des Agile Manifests. Um wirklich agil zu sein, muss man die Prinzipien verstehen und umsetzen, nicht nur die Praktiken übernehmen.

Transkript

Hallo und herzlich willkommen bei No Bullshit Agile. Mein Name ist Thomas. Ich bin Teil eines agilen Teams und bespreche hier jede Woche Themen aus der agilen 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 Woche habe ich über ein Verfahren gesprochen, das jedem im Team ein regelmäßiges Feedback garantiert, das sogenannte Peer Feedback. Wenn dich das interessiert, hör gerne rein. Den Link dazu findest du wie immer in den Shownotes.

Das ist die Folge 15 und heute geht es darum, dass Agilität ein Mindset ist.

Okay, steigen wir in das Thema ein. Wenn man sich mal umguckt auf Social Media, andere Podcasts zur Agilität hört, Reddit liest oder in Foren nachliest, werdet ihr feststellen oder habt es vielleicht schon festgestellt: Viele Leute haben große Schwierigkeiten mit der Agilität. Die meisten, zumindest aus meiner Erfahrung, verwechseln Dinge wie „Wir machen Scrum“ oder „Wir nutzen Kanban“ oder „Wir haben Jira“ oder „Wir machen regelmäßig einen Daily“ oder „Ich bin PO“ mit Agilität und wundern sich dann, dass das alles nicht funktioniert. Viele sind dann tatsächlich einfach nur frustriert. Die Frage ist: Warum ist das so?

Ich würde mal anfangen mit der Frage: Was ist überhaupt die Erwartung? Ich habe aus Spaß mal nach „Why Agile“ gegoogelt und kann euch nur empfehlen, das auch mal zu tun. Was man da so liest bei den ersten Treffern, allein in den Snippets, die Google einem da gibt, da sieht man das Drama schon. Hier ein paar Zitate:

„Agile Methods can help teams manage work more efficiently and do the work more efficiently while delivering the highest quality product with the constraints of the budget.“ Da ist jetzt auf einmal Budget mit drin, und es geht um Effektivität und höchste Qualität. Und das soll eine Definition oder Antwort auf die Frage sein, warum überhaupt agil sein?

Ein weiteres Zitat lautet: „Agile Development is important because it helps to ensure that development teams complete projects on time and within budget.“ Auch hier ist so viel falsch dran. Was heißt denn das Projekt, und wie soll man am Anfang wissen, was hinten rauskommt? Wie kann man dann sagen, dass das Projekt, das man noch nicht einmal definieren kann, „on time“ und „within budget“ ist?

Ein drittes Zitat, das ich gefunden habe, ziemlich weit oben in den Treffern bei „Why Agile“, lautet: „Better project control.“ Agilität hat doch mit Projektmanagement und Projektcontrolling überhaupt nichts zu tun. Wie gesagt, da sieht man das ganze Drama schon und sofort, warum Leute frustriert sind und sagen, Agilität funktioniert nicht. Ich kann euch wirklich nur den Tipp geben, googelt selbst ein bisschen. Es ist schon erhellend und teilweise auch wirklich erheitern, wenn es nicht so traurig wäre.

Da sind auch nicht falsche Dinge dabei, aber das Fundament, der Grund für Agilität wird da überhaupt nicht aufgegriffen. Ein paar Dinge wie gute Qualität oder eine gute Auslieferung sind schon richtig, und dass man damit auch eine gewisse Art von Budgetkontrolle hat, wenn man in kleinen Versionen arbeitet, ist auch richtig. Aber der Grund, warum man ein Projekt agil machen möchte, wird dort nicht wirklich behandelt.

Die erste Frage, die ihr euch stellen könnt, ist: Was mache ich, was ist meine Tätigkeit, welche Projekte habe ich? Wenn ihr feststellt, dass ihr eigentlich immer das Gleiche macht, dann frage ich euch: Warum wollt ihr agil sein? Falls ihr in dieser Situation seid, denkt darüber nach.

Agilität ist eine Methodik, die eingeführt wurde, weil sie anerkennt, dass wir eben nicht immer das Gleiche machen. Gerade in der Softwareentwicklung machen wir neue Dinge. Wir betreten permanent Neuland. Es gibt Teile, die wir auch reproduzieren, aber in der Regel ist jedes Projekt anders. Jedes Projekt hat seine Eigenart, und tatsächlich ist es auch so, dass Kunden oft nicht vollständig beschreiben können, was ihre Anforderungen sind. Das ist ganz natürlich und kein Vorwurf an jemanden, denn das kann kein Mensch vollständig beschreiben.

Wir werden in Projekten immer schlauer, und das wollen wir anerkennen. Wenn wir immer das Gleiche tun, zum Beispiel, wenn wir VW sind und einen Golf bauen, wissen wir genau, was wir tun müssen, damit ein Golf herauskommt – wir reproduzieren. In diesem Fall brauche ich keine Agilität. Aber sobald ich kein Golf mehr baue, wird eine Definition am Anfang eines Projekts nicht das Ergebnis liefern, das ich brauche. Das ist das Fundament und der Hauptgrund, warum wir überhaupt an Agilität denken und sagen, wir brauchen einen anderen Ansatz, wie wir Projekte entwickeln.

In einem Umfeld, in dem am Anfang nicht klar ist, was hinten herauskommt, brauchen wir Agilität, weil wir Faktoren wie Learning während des Projekts einfließen lassen wollen. Wir wollen anerkennen, dass wir zwar die ersten Anforderungen gut definieren können, wir dann aber in einem Feedback-Zyklus auch Erfahrungen sammeln wollen. Wir wollen auswerten, funktioniert das, was wir da bauen, wird das von Kunden angenommen, ist die Bedienung gut? Dieses Feedback wollen wir einfließen lassen.

Das bedeutet, wir können am Anfang keinen großen Plan aufstellen, und deswegen können wir auch nicht über Timings und Budgets für das gesamte Projekt sprechen. Wir können für einen kleinen Teil, für den Anfang, über Timing und Budget sprechen, aber nicht für ein Projekt, das ein halbes Jahr läuft. Wir kennen zum Beispiel auch den Scrum Master nicht gut genug. Wir wissen nicht, ob die Software, die wir entwickeln, vom Markt angenommen wird. Das Ganze ist ein Experiment, es ist Neuland, und wir müssen agiler darauf reagieren. In einem solchen Umfeld ist Agilität relativ gesehen das schnellste Vorgehen.

Das „schnell“ ist in der Agilität auch stark verknüpft. Zumindest habe ich das Gefühl, dass es in den Köpfen der Leute stark verknüpft ist. „Lasst uns agil sein, weil dann geht alles viel schneller.“ Aber das ist auch ein Trugschluss. Agil heißt nicht schnell, sondern Agil heißt beweglich. Wir sind relativ gesehen mit Agilität in einem unbekannten Umfeld bestimmt schneller, ob das absolut sehr schnell ist, sei dahingestellt. Es ist das beste Verfahren, um zum Beispiel kein Waste zu produzieren, indem wir Erkenntnisse immer einfließen lassen.

Vielleicht nochmal ganz kurz zusammengefasst: Ihr solltet euch ehrlich fragen, welche Art von Tätigkeit ihr oder euer Team macht. Ist es eher das gleiche immer und immer wieder? Oder ist es wirklich so, dass es eine große Komponente von Neuland hat? Wenn es immer das Gleiche ist, braucht ihr nicht agil zu sein. In dieser Situation wird Agilität sicherlich das schlechtere Verfahren sein. Wenn ihr reproduziert, könnt ihr ganz klassisch planen, wann ihr was macht, und das ist auch vollkommen okay. Agilität geht um Projekte und Anforderungen, die uns in unbekanntes Land führen, wo die Anforderungen nicht klar sind.

Jetzt hatte ich ja gesagt, Agilität ist ein Mindset. Das heißt, wie kann ich Agilität umsetzen, wenn ich in einem solchen beschriebenen Umfeld bin? Ich sage, es ist ein Mindset, weil es eigentlich nicht viel braucht. Es braucht das Agile Manifest, die vier Punkte aus dem Agile Manifest. Dazu hatte ich mal detailliert in Folge 5 gesprochen und die Ergänzung zum Agile Manifest, die zwölf Agilitätsprinzipien, die ich in Folge 6 behandelt habe. Wenn man sich daran hält und das wirklich einsinken lässt – und deswegen ist es ein Mindset – dann seid ihr auf einem guten Weg zur Agilität.

Ich kann gut nachvollziehen, dass die natürliche Folge dann ist, zu sagen: „Okay, und was sind die Regeln?“ Denn das Agile Manifest ist eben nur ein Manifest. Deswegen verstehe ich auch, dass Leute in so etwas wie einen Scrum Guide schauen und sagen: „Okay, dann ist Scrum das Framework, das uns dazu bringt, agil zu sein, weil dort klare Regeln definiert sind.“ Wir Menschen orientieren uns gerne an Regeln oder Spielregeln. Aber nur weil ich Scrum mache, bin ich noch lange nicht agil.

Viele Leute machen zum Beispiel Scrum, und das gilt übrigens auch für Kanban oder andere Verfahren. Sie halten sich ans Regelwerk, ans Playbook, und wundern sich, warum sie nicht agil sind. Das liegt daran, dass das Regelwerk nur eine untergeordnete Rolle spielt. Da fehlt das Verständnis für das Fundament, die Agilitätsprinzipien und das Agile Manifest.

Scrum, ein Daily, Tools wie Jira oder Trello und Rollen wie Scrum Master und PO sind untergeordnet. Sie sollen nur eine Hilfestellung sein. Das kommt oben drauf, aber zuerst müsst ihr die Agilitätsprinzipien verstehen. Ihr müsst zuallererst schauen, ob euer Umfeld überhaupt geeignet ist, ob ihr das Mindset habt und ob das Mindset angekommen ist. Wenn das nicht der Fall ist, würde ich nicht schauen, warum Scrum bei uns nicht funktioniert, sondern ich würde prüfen, warum wir Agilität nicht verstehen. Vielleicht passt es nicht zu euch. Vielleicht müsst ihr wirklich am Mindset arbeiten.

Parallel zu dieser Folge starte ich auch eine Umfrage. Mich interessiert, wie zufrieden ihr mit der Agilität bei euch im Unternehmen seid. Die Umfrage starte ich auf Mastodon, und den Link dazu findet ihr in den Show Notes.

Ich denke, damit sind wir heute durch. Mich interessiert eure Meinung dazu. Ich weiß, dass es sicherlich eine eher polarisierende Folge ist. Mich würde interessieren, welche Erfolge ihr habt, wie ihr das alles in der Praxis erlebt, ob es bei euch Diskussionen dazu gibt, wie agil ihr seid, oder ob ihr euch einfach nur an einem Framework orientiert. Habt ihr Probleme mit der Agilität? Gebt mir gerne Feedback. Es gibt mehrere Wege, wie ihr mich erreichen könnt: