In der aktuellen Folge von No Bullshit Agile geht es darum, dass Agilität nicht durch starre Prozesse oder Methoden erreicht wird, sondern durch tiefere Prinzipien. Thomas spricht über die Gefahr, dass Agilität oft falsch verstanden wird, indem sich Unternehmen zu stark an Methoden wie Scrum oder SAFe klammern, ohne das eigentliche Ziel agiler Arbeitsweisen zu berücksichtigen. Er betont, dass es nicht reicht, Regeln zu befolgen – der wahre Wert der Agilität liegt in der Anpassungsfähigkeit, Teamempowerment und dem kontinuierlichen Lernen.

Außerdem stellt Thomas seine Umfrage vor, bei der er Daten über die Nutzung agiler Methoden in Unternehmen sammelt, und bittet die Hörer, teilzunehmen und die Umfrage zu teilen.

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 agilen Projektwelt. Dabei orientiere ich mich an den großen Kategorien: Menschen, Teams, Kunden, Projekte und Agilität. Mein Fokus liegt dabei auf der Praxis, daher auch der Name No Bullshit Agile.

In der letzten Folge habe ich mit Anne über ihren Weg hin zur Scrum Masterin gesprochen. Wenn dich das interessiert, hör gerne rein. Den Link zu der Folge findest du, wie alle Links, in den Show Notes. Das ist die Folge 34, und heute geht es darum, dass Agilität nicht durch Einheiten von Beton oder Prozesse erreicht wird, sondern durch viel wichtigere Dinge.

Bevor wir mit dem Thema einsteigen, ein bisschen Housekeeping diesmal. Ich habe zwei Dinge.
Das erste ist, dass ich eine Umfrage gestartet habe. Diesmal tatsächlich ein bisschen größer, also nicht nur auf LinkedIn oder Mastodon. Mir geht es darum, einen Überblick darüber zu gewinnen, welche agilen Methoden in Unternehmen zum Einsatz kommen, wie zufrieden die Teams mit diesen Methoden sind und wie erfolgreich das Unternehmen ist. Ich will diese Daten auswerten, und mittlerweile haben knapp 30 Leute mitgemacht. Ich kann aber deine Hilfe gebrauchen! Also je mehr Leute mitmachen, desto größer die Datenbasis und desto besser wird die Auswertung. Ich werde die Umfrage auch länger laufen lassen und veröffentliche auf meinen Kanälen immer mal Zwischenergebnisse. Vor allem Mastodon und LinkedIn sind meine Kanäle. Du findest den Link zur Umfrage in den Show Notes.

Meine große Bitte: Nimm teil, wenn du noch nicht teilgenommen hast, und teile die Umfrage in deinem Team, auf der Arbeit oder deinen Social-Media-Kanälen. Das wäre echt richtig cool. Je mehr Daten wir bekommen, desto cooler wird die Auswertung, und ich hoffe mir halt, dass alle – also auch du – etwas von dieser Auswertung haben. Deswegen sage ich hier schon mal vielen Dank fürs Teilen und Mitmachen.

Das zweite, was mich interessiert, ist: Wann hört ihr NBA? Ich veröffentliche immer so freitagnachmittags, weil das bei mir zeitlich einfach ganz gut passt. Mich würde mal interessieren, ob ihr das eher auf dem Weg zur Arbeit hört, ob es euch egal ist, wann die Folge erscheint, weil ihr sie eh irgendwann in eurem Podcatcher habt. Das Beste wäre, du gibst mir ein Feedback im Forum-Thread zu dieser Folge. Auch den Link findest du in den Show Notes.

Okay, soweit zum Housekeeping. Dann würde ich sagen, wir steigen mal ein.

Die Inspiration zu dieser Folge oder zu diesem Thema kommt tatsächlich von einem Artikel, den ich auch verlinke. Der Artikel trägt den Titel „Avoiding Agile Must Do's“. Das Problem, das darin thematisiert wird, hängt mit weiteren Komponenten zusammen: Viele legen den Fokus darauf, eine agile Methode wie Scrum, Kanban oder XP korrekt auszuführen. Und das führt oft zu einem „Wasserfall mit dem Deckmantel der Agilität“. Das ist uns auch passiert.

Ich habe früher immer gesagt, mir ist es wichtig, dass wir uns ganz akkurat an den Scrum Guide halten. Ich dachte, das wäre eine gute Sache – und natürlich ist das auch eine gute Sache. Wenn man eine Methode hat, sollte man sie richtig anwenden. Es macht keinen Sinn, Scrum zu machen und dann zu sagen, „aber Daily machen wir nicht“ oder „Scrum Master haben wir nicht“. Die agile Methode hat ja eine gewisse Idee, da steckt viel Erfahrung drin, und dann sollte man sie korrekt anwenden. Aber das reicht halt nicht.

Der Ansatzpunkt liegt woanders. Man muss viel früher überlegen, warum man ein agiles Vorgehen braucht, und dann erst sagen: „Das ist die Methode, die wir benutzen.“ Die grundsätzliche Denke ist oft: „Wir müssen uns nur an die Regeln der Methode halten, und dann sind wir agil.“ Daher kommen meiner Meinung nach auch diese Flut an Artikeln und YouTube-Videos zu „Agilität ist tot“. Das ist natürlich catchy und clickbait, aber es steckt schon ein gewisser Teil Wahrheit drin.

Das Thema habe ich ja schon in einer eigenen Folge behandelt, das war die Folge 30. Aber hier nochmal eine kurze Zusammenfassung: Die Leute sagen, „Agilität ist tot“, weil Scrum in ihrem Unternehmen nicht funktioniert. Wenn man aber genauer hinschaut, liegt es nicht an Scrum, sondern daran, dass Management-Ebenen Scrum für sich entdeckt haben. Ich sage immer, das Management denkt: „Oh, damit habe ich die volle Kontrolle über ein Projekt, lass uns Scrum machen.“ Dabei kann Scrum gar nichts dafür, es wird nur falsch benutzt.

Es gibt diese Denke: „Wir haben eine Methode, führen sie ein, und dann sind wir agil.“ Ein Beispiel ist SAFe (Scaled Agile Framework). Damit wird alles nur noch Projektmanagement – mehr Regeln, mehr Prozesse, mehr Definitionen – und das führt einfach weiter weg von der Agilität und nicht hin zur Agilität. Das unterstützt die Agilität gar nicht mehr, weil die Denke des Managements von Projekten hinzugekommen ist.

Das Agile Manifest und die 12 agilen Prinzipien geraten in den Hintergrund oder werden nie besprochen. Man ist schon „agil“, weil man die Methode korrekt anwendet, aber das öffnet Tür und Tor für Projekt- und Teammanagement unter dem Deckmantel der Agilität. Dann kommen Reportingmechanismen, Predictions, und man möchte die Zukunft vorhersagen. Aber das widerspricht Agilität!

Warum will man denn agil sein? Weil man vielleicht eine gute Beschreibung eines oder mehrerer Ziele hat, aber den Weg dorthin noch nicht kennt. Man betritt Neuland. Und wenn man Neuland betritt, kann man die Zukunft nicht vorhersagen. All das führt eben weg vom Fundament des Agilen Manifests.

Nicht alle Tätigkeiten eignen sich, um sie agil umzusetzen, und das ist völlig okay! Bei uns gibt es Tätigkeiten, bei denen das Ziel und der Weg klar sind – dann brauchen wir keine agilen Methoden. Wenn es aber unklar ist, dann macht Agilität Sinn.

Wenn der Anlass, ein Projekt agil durchzuführen, nicht verstanden wird, nützen agile Methoden nichts. Es ist schon okay, dass man mit der „Hülle“ der Agilität andere Dinge macht, aber dann darf man sich nicht beschweren, dass die Methode oder Agilität tot sei.

Zusammenfassend:
Wir wollen von den Benutzern des Systems lernen.
Wir wollen Risiken minimieren – das bedeutet kleine Schritte und Anpassbarkeit.
Wir wollen den Fokus auf den Wert legen, den das Produzierte schafft, nicht auf die Menge der Arbeit.
Wir wollen das Teamempowerment stärken und Vertrauen schaffen.
Und wir wollen permanente Verbesserung in allen Bereichen – in der Technik, in unseren Prozessen und in der Interaktion.

Das war's für heute. Ich bin gespannt auf eure Meinung! Bitte gebt mir Feedback, was ihr in der Praxis erlebt. Ihr erreicht mich über verschiedene Kanäle: per Mail unter nobsagile@gmail.com, auf Mastodon oder im Forum. Wenn euch die Folge gefallen hat, teilt sie gerne mit anderen. Je mehr Leute wir erreichen, desto besser wird die Diskussion und der Erfahrungsaustausch. Das ist der Hauptgrund, warum ich diesen Podcast gestartet habe.

Habt noch eine tolle Woche und bis zum nächsten Mal.

NBA34: Agil sein durch Feedback und Anpassung, nicht durch starre Prozesse

Shownotes

Zusammenfassung

Transkript

Featured

Subscribe

Tags