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

Hallo und herzlich willkommen bei NoBullshit 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 NoBullshit Agile. In der letzten Folge habe ich mit Anne über ihren Weg hin zur Scrum Masterin gesprochen. Wenn dich das interessiert, hör da 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 Betonen 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, ich habe eine Umfrage gestartet. 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 agil Methoden in Unternehmen zum Einsatz kommen und 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 hier gebrauchen. Also je mehr Leute mitmachen, je größer die Datenbasis ist, desto besser ist die Auswertung. Ich werde die Umfrage auch länger laufen lassen. Ich veröffentliche auf meinen Kanälen immer mal Zwischenergebnisse. Also vor allen Dingen Mastodon und LinkedIn sind ja meine Kanäle. Du findest den Link zu der Umfrage in den Show Notes. Meine große Bitte ist, nimm Teil, wenn du noch nicht teilgenommen hast und teile die Umfrage in deinem Team auf der Arbeit, auf 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, was von dieser Auswertung hast. 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 Freitag nachmittags, weil das bei mir zeitlich einfach ganz gut passt. Mich würde mal interessieren, hört ihr das eher auf den Weg zur Arbeit, ist es euch egal, wann die Folge erscheint, weil ihr sie eh irgendwann in eurem Podcatcher habt. Das Beste wäre, du gibst mir ein Feedback in den Phone-Strat 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 dem Artikel, auch den verlinke ich. Der Artikel Titel lautet "Avoiding Agile Must Do's". Und das Problem ist ein bisschen und das hängt mit weiteren Komponenten zusammen. Viele legen den Fokus auf eine agile Methode, Scram oder Kanman oder XP oder was auch immer eure agile Methode ist, eine agile Methode 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, als wir Scram gemacht haben, dass wir uns ganz akkurat an den Scram Guide halten. Und ich habe gedacht, das wäre auch eine gute Sache. Und natürlich ist das auch eine gute Sache. Also, wenn man eine Methode hat, dann sollte man sie richtig anwenden. Das macht keinen Sinn, sage ich mal, Scram zu machen und zu sagen, aber Daily machen wir nicht. Oder Scram Master haben wir nicht. Weil die agile Methode hat ja schon eine gewisse Idee, da steckt ja viel Erfahrung drin und dann sollte man sie korrekt anwenden. Aber das reicht halt nicht. Der Ansatzpunkt dazu ist an einer ganz anderen Stelle. Man muss viel früher überlegen, warum brauche ich ein Agiles vorgehen und dann erst sagen, und das ist die Methode, die wir benutzen. Die grundsätzliche Denke ist oft. Wir müssen uns jetzt nur an die Regeln der Methode halten und dann sind wir Agil. Daher kommt tatsächlich meiner Meinung nach auch diese Flut an Artikeln und YouTube Videos zu Agilität ist tot. Das ist natürlich auch, ja, ich sage mal, catchy und clickbait. Und trotzdem steckt da schon ein gewisser Teil an Wahrheit drin. Das Thema habe ich ja ein bisschen umfänglicher behandelt in der eigenen Folge. Das ist die Folge 30. Aber hier nochmal vielleicht ganz kurz so eine Zusammenfassung. Die Leute sagen Agilität ist tot, weil dann zum Beispiel Scram bei ihnen im Unternehmen nicht funktioniert. Und wenn man ein bisschen tiefer guckt, dann liegt das gar nicht an Scram, sondern eben daran, dass jetzt weitere Leute Scram für sich entdeckt haben. Also ich sage ja immer das Management. Ich kenne das auch von Kunden, die denken, oh, ja, damit habe ich die volle Kontrolle über einem Projekt, lass uns Scram machen. Und Scram kann da gar nichts dafür. Das wird nur falsch benutzt beziehungsweise das Wissen davor ist nicht da. Mit so einer Denke und auch Weiterentwicklung basierend auf dieser Denke. Wir haben Methode, wir führen die ein, also mir fällt ja immer safe ein. Kommt es dann einfach dazu, dass alles nur noch Projektmanagement ist. Jede Erweiterung der grundsätzlichen agilen Idee, agiles Manifest, zwölf agile Prinzipien, ist dann irgendwie nur noch um ein Projekt besser zu managen, mehr Regeln, mehr Prozesse, mehr Definitionen. Und das führt halt einfach immer nur weiter weg von der Agilität und nicht hin zur Agilität ist, unterstützt dann gar nicht mehr die Agilität, weil diese Denke des Managements eines Teams und oder eines Projekts jetzt dazu gekommen ist. Die Basis, hatte ich gerade schon gesagt, das Agile Manifest und die zwölf Prinzipien geraten einfach in den Hintergrund oder werden eigentlich nie besprochen. Es kommt eben einfach dazu, man ist ja schon Agil, weil man diese Methode korrekt anwendet, welche Methode es auch immer ist. Und das öffnet Tür und Tor unter diesem Denkmantel der Agilität. Gänsefüßchen, Scrum will das ja so, Projekt und Teammanagement einzuführen. Dann kommen Reportingmechanismen dazu, es kommen Predictions dazu, man möchte die Zukunft vorhersagen. Wir haben ja unsere aktuelle Velocity, ich weiß, das steht so nicht im Scrum Guide, aber es kommt immer mit an dieser Stelle und können deswegen sagen, mit dieser Velocity schaffen wir im nächsten Sprint ja so viele Stories. So und wenn der Projekt Gegenstand Agil umgesetzt werden muss, dann kann ich diese Prediction ja gar nicht machen, denn und da komme ich gleich mehrfach noch dazu, warum will ich denn Agil sein? Weil ich vielleicht eine gute Beschreibung eines oder mehrer Ziele habe, aber dadurch, dass ich was Neues mache oder schnell auf dem Markt agieren muss, kann ich den Weg noch nicht beschreiben. Es ist keine Wiederholung, keine Repetition, die ich hier mache, sondern ich betrete Neuland. Und wenn ich Neuland betrete, dann kann ich die Zukunft nicht vorhersagen. Das ist das Thema immer nennen, das steckt rein logisch einfach schon drin. All das führt eben weg von dem Fundament dem Agil mein Zett. Also ich habe dazu in der Folge 29 mal gesprochen und vielleicht nochmals wiederholen und nicht alle Tätigkeiten, um das vielleicht auch noch mal festzuhalten, sind überhaupt geeignet, sie Agil umzusetzen und das ist vollkommen okay. Also wir haben bei uns Tätigkeiten, das sind 30 Prozent eben so klar, umrissenes Ziel ist klar, der Weg ist klar. Wir haben das mehrfach gemacht, dem Kunden ist vollkommen klar, was hinten rauskommen muss und was der Nutzen ist und in dem Moment brauche ich Agile Methoden nicht. Wenn man sie dann abwickelt innerhalb des Rahms der Agil Methode, ist das auch wieder okay, man will ja nicht, ich sage mal für jede Umsetzung in einer anderen Methode aufmachen, aber dies Bewusstsein dafür, dass es einen Anteil, einen Arbeit gibt, der eben gar nicht Agil umgesetzt werden muss. Dieses Bewusstsein muss man auch mal schaffen und in Zweifel zwar im Team und mit weiteren Leuten auch mal diskutieren. Ja wie gesagt, also wenn der Weg zum Ziel und das Ziel bekannt ist, wenn es eine repetitive Tätigkeit ist, dann müsst ihr das nicht Agil machen und es macht dann Zweifel Agilität auch überhaupt gar keinen Sinn mehr. Und wir hatten das zum Beispiel immer wieder, als wir Scrum gemacht haben, wichtiger Bestandteil und das finde ich ist auch ein total wichtiger Bestandteil, beschreibe das Sprintziel. Das soll ja das Licht sein, das uns führt über unseren Sprint, damit wir Entscheidungen treffen können und das macht total Sinn. Plus wenn man an einer Stelle ist, wo das Sprintziel einfach nur noch formuliert wird, als die Story sollen fertig werden oder sich eine Story rauspickt und sagt, diese Story, das was da drin vereinbart ist, das muss fertig werden, dann ist es eben kein gutes Sprintziel. Das leitet Leute nicht. Ja um vielleicht einen schönen Satz aus dem Artikel zu zitieren, Agility doesn't mean good at waterfall. Da steckt viel drin, da kann man mal in Ruhe drüber nachdenken. Ja und wie gesagt, wenn der Anlass ein Projekt Agil durchzuführen, wenn der nicht da ist und wenn das nicht verstanden wird, dann nützt es einfach nichts Agilmethoden einzusetzen. Das kann man dann auch wirklich nicht der Agilität, die Agilität ist tot, Gänsefüßen in der Luft oder eine Agil Methode, Scrum ist tot, anlasten, das ist einfach so. Meiner Meinung nach brauchen wir, braucht ihr ein Agiles Vorgehen, wenn ihr schnell auf dem Markt sein müsst oder eure Kunden für die ihr was entwickelt. Wenn ihr ein oder mehrere Ziele benennen könnt, aber den Weg dahin eben nicht, sei es für euch oder für die Kunden. Oft genug stelle ich zumindest fest, können Kunden schon beschreiben, was sie da wollen und manchmal schreiben Kunden auch wirklich viel und lange und haben Beispiele und trotzdem ist es so, dass wenn man das so entwickeln würde oder das entwickeln würde, was die Kunden da vorhaben, sie nicht das bekommen, was sie brauchen und das stelle ich im Projekt wirklich fest. Wir haben super Beschreibung, wir entwickeln das auf diese Art und Weise, liefern ein erstes Inkrement und die Kunden sagen, ah, nee, das hätte ich gerne anders hier, die Funktionalität, die jetzt dahinter steckt, die passt gar nicht in mein Workflow rein. Obwohl sie es eigentlich so beschrieben haben, ich streite mich dann mit dem Kunden überhaupt nicht darüber. Also der Kunde sagt dann auch nicht, nee, ich bin nicht bereit, jetzt noch mal was zu bezahlen oder so, ist überhaupt nicht das Thema. Mir geht es hier um die Effektivität. Ja, wichtiger Punkt ist, für wann brauche ich Agilität, wenn ihr Neuland betretet und wenn ihr die Iteration braucht und das Ergebnis der Iteration, das Feedback dazu, um die nächsten Iterationen zu planen. Das sind gute Zeichen dafür, dass man Agile vorgehen kann, wenn ihr auch in der Iteration kein Feedback-Zyklus habt, in dem ihr bestimmte Daten auswertet, Endkunden zur Bedienung befragt und dieses Feedback nicht in die nächsten Iterationen einfließt, ja, dann habt ihr einfach einen großen Teil der Agilität verloren an der Stelle. Wenn vor diesen Bedingungen, ich glaube den Katalog könnte man sogar noch erweitern, Bedingungen nicht erfüllt sind, dann sind Agile-Methoden eben nur eine Hülle und um das auch nochmal zu betonen, das ist schon okay, dass man mit dieser Hülle andere Dinge macht, bloß ihr dürft euch dann nicht beschweren oder die Beschwerden finde ich gelten nicht, dass die Methode schuld ist oder die Agilität schuld ist und dass die Agilität tot sei. Agilität bedeutet eben kleine Iteration, häufige Auslieferung, Auswertung, ob die Annahmen für die Iteration dann richtig war, um den Ziel näher zu kommen, Anpassungen der nächsten Iterationen, falls die eben nötig sind und Agiles Vorgehen unterstützt eben dann Risiken zu limitieren, Overhead zu verkleinern und es ermöglicht euch auf Änderung schnell zu reagieren. Agilität bedeutet eben nicht Planbarkeit in unplanbaren Umgebungen herstellen, hat ich vorhin kurz gesagt, das Thema Velocity, Cumulative Flow Diagramm Burndown Chart, irgendeine Art von Berechenbarkeit, wann irgendwie ein Epic fertig ist. Das hat mit Agilität überhaupt nichts zu tun, wir sind auch irgendwie ja ein bisschen verbrannt von Tools wie Gira, die natürlich so ein Reporting haben, das ist ja aus deren Produktmarketing Sicht auch richtig, aber wir denken immer, naja, aber in Gira gibt es ja einen Burndown Chart und da gibt es ja Velocity Berechnungen für Sprints und Predictions für die nächsten Sprints. Also muss das ja Agil sein, aber das ist es nicht, Agilität bedeutet auch nicht Teammanagement, das hat mit HR Teams und Teamverwaltung überhaupt nichts zu tun, es hat nichts damit zu tun, dass man mit Hilfe von Agilität Rollen definiert und vielleicht sogar Gehaltsmodelle dran macht, ein Scrum Master verdient bei uns so viel, weil das ja eine Rolle in Scrum ist, das macht alles überhaupt keinen Sinn. Agilität bedeutet nicht POs oder PMs oder andere aus dem Management haben jetzt Kontrolle über To-Do-Listen und können definieren, was als nächstes gemacht wird. Das ist alles nicht Agilität und trotzdem taucht es in der Praxis so auf und das ist übrigens ein Grund, warum auch Kunden immer mehr sagen, wir wollen Scrum machen. Scrum ist die bekannteste Methode, sie ist die am deutlichen definierteste Methode und Scrum vermittelt vielen Leuten, die haben das Gefühl, dass viele Konsultants auch Kunden dahin beraten, dass sie all diese Punkte, die ich gerade genannt habe mit Scrum eben machen können, eine Kontrolle ausüben können, eine Zukunft vorhersagen können, immer in unbekannten Umfällen und das ist nicht so, die Zukunft kann man in unbekannten Umfällen eben nicht vorher sagen, egal mit welcher Methode man muss nur anerkennen, dass wir unbekanntes Land betreten und eine richtige Methode auswählen und das Fundament dazu, das Beste und erfolgreichste Fundament ist ein agiles Vorgehen. Vielleicht noch mal eine kleine Zusammenfassung. Wir wollen von Benutzern des Systems lernen. Wir wollen Risiken minimieren und das bedeutet kleine Schritte und permanente Anpassbarkeit. Wir wollen Fokus auf den Wert legen, den Wert, den das Produzierte schafft und keinen Fokus auf die Menge der Arbeit, die wir schaffen. Die Menge der Arbeit ist vollkommen irrelevant. Es geht doch darum, dass wir dem Kunden ein Wert an die Hand liefern, damit er Geld, Kohle von seinem Investment zurückricht. Deswegen Fokus auf Wert, nicht auf Menge der Arbeit. Wir wollen Teamempowerment. Wir wollen das Team in die Selbstständigkeit bringen. Wir wollen den Rahmen schaffen. Wir brauchen dazu Vertrauen. Dazu hatte ich auch mal eine Folge. Diesem Powerment ist Pflicht. Jede Kontrolle, die ihr über ein Team ausführt, wie es etwas umsetzt, wie es herangeht an die Problematik, ist ein Riesenproblem und nimmt Stück für Stück Potenzial der Agilität weg. Wir wollen die permanente Verbesserung in allen Bereichen, in der Technik, in unseren Prozessen, in der Interaktion. Dafür haben wir Retros. Deswegen sieht Scrum eine Retro vor und deswegen halte ich zum Beispiel eine Retro für super wichtig. Wir haben deswegen Feedback-Zyklen, damit wir permanent daran arbeiten können, was können wir verbessern. Agilität wird nicht dadurch erreicht, dass man es dem Team aufzwingt und im Zweifel sogar sagt, und so geht Agilität. Es geht nicht darum, das Volumen dessen, was wir liefern, als Team zu erhöhen. Das ist nicht Gegenstand von Agilität. Agiles Vorgehen ist das Ergebnis von Teams, die auf ihre Ziele hinarbeiten, indem sie Feedback-Schleifen verkürzen, experimentieren, lernen und sich anpassen. Und das soll es für heute gewesen sein. Ich bin wie immer ganz gespannt, wie eure Meinung zu dem Thema ist. Bitte, bitte, gebt mir Feedback. Was erlebt ihr so in der Praxis? Wenn du Feedback hast, dann erreichst du mich auf verschiedenen Kanälen. Du kannst mir ganz klassisch eine Mail schreiben. Nobias@gmail.com ist die E-Mail-Adresse. Ich habe ein Mastodon-Profil, da bin ich ziemlich aktiv und begleitend zu dem Podcast gibt es ja einen Forum und zu jeder Folge gibt es auch einen Forum-Thread. Deswegen auch da lasst uns gerne diskutieren und unsere Erfahrung austauschen. Eine Bitte habe ich noch. Wenn dir die Folge gefallen hat, vielleicht hat es dir sogar geholfen. Teil sie bitte mit anderen, mit Leuten in deinem Team, vielleicht auf deinen Social-Media-Kanälen. Je mehr Leute wir hier erreichen, desto besser wird die Diskussion, desto besser wird der Erfahrungsaustausch und das ist der Hauptgrund, warum ich diesen Podcast gestartet habe. Habt noch eine ganz tolle Woche und bis zum nächsten Mal. Bye. [Musik]