<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom" xmlns:media="http://search.yahoo.com/mrss/">
    <title>No Bullshit Agile</title>
    <link href="https://no-bullshit-agile.de/feed.xml" rel="self" />
    <link href="https://no-bullshit-agile.de" />
    <updated>2026-07-18T15:01:52+02:00</updated>
    <author>
        <name>Thomas</name>
    </author>
    <id>https://no-bullshit-agile.de</id>

    <entry>
        <title>Warum LLMs auf einem Plateau sind und was das für Softwareentwicklung bedeutet</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/llm-plateau-softwareentwicklung.html"/>
        <id>https://no-bullshit-agile.de/llm-plateau-softwareentwicklung.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/208/llm-plateau-cover.jpg" medium="image" />
            <category term="Tools"/>

        <updated>2026-07-18T14:58:18+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/208/llm-plateau-cover.jpg" alt="Warum LLMs auf einem Plateau sind" />
                    Dieser Artikel passt hier eigentlich gar nicht rein, weil es nicht direkt um agiles Arbeiten geht. Das Thema ist aber wichtig genug, dass ich es trotzdem hier aufschreibe, denn es betrifft jeden, der Software entwickelt oder entwickeln lässt. Meine These: Wir sind bei der Entwicklung großer Sprachmodelle auf einem Plateau&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/208/llm-plateau-cover.jpg" class="type:primaryImage" alt="Warum LLMs auf einem Plateau sind" /></p>
                <p>Dieser Artikel passt hier eigentlich gar nicht rein, weil es nicht direkt um agiles Arbeiten geht. Das Thema ist aber wichtig genug, dass ich es trotzdem hier aufschreibe, denn es betrifft jeden, der Software entwickelt oder entwickeln lässt.</p>
<h2>TL;DR</h2>
<p>Meine These: Wir sind bei der Entwicklung großer Sprachmodelle <strong>auf einem Plateau angekommen</strong>. Damit meine ich nicht, dass die Technologie wieder verschwindet. Ich meine, dass der wirtschaftliche Nutzen von LLMs für ernsthafte Softwareentwicklung <strong>deutlich kleiner ausfällt und deutlich langsamer eintritt, als das investierte Kapital unterstellt</strong>. Der Zuwachs an Fähigkeit seit Ende 2024 kam vor allem aus besseren Werkzeugen und aus einer Art des Nachdenkens (Reasoning-Modelle), die mit mehr Rechenzeit erkauft wird, und kaum noch aus grundlegend klügeren Modellen. Der Preis pro Anfrage ist heute subventioniert und muss sich den echten Kosten annähern. Die messbaren Produktivitätsgewinne zeigen sich auf der Ebene einzelner Aufgaben, aber nicht auf der Ebene ganzer Unternehmen. Und der Kapitalmarkt beginnt gerade, genau das einzupreisen. Wenn Unternehmen die realen, moderaten Effizienzgewinne einmal gehoben haben, sinkt der Investitionsdruck, und mit ihm das Tempo der Weiterentwicklung.</p>
<p>Wer den Rest des Textes liest, bekommt die Herleitung, mit Quellen für die harten Zahlen. Wer mir am Ende nicht folgt, soll mir bitte sagen, an welcher Stelle die Kette bricht.</p>
<h2>Zwei Lager</h2>
<p>In der Debatte um LLMs gibt es grob zwei Positionen. Das eine Lager sagt, in wenigen Jahren brauche man kaum noch fertige Software, weil man sich das, was man gerade benötigt, einfach vom Modell schreiben lässt. Modelle und die Werkzeuge um sie herum würden immer besser, das Tempo bleibe hoch. Das andere Lager sagt, die Modelle selbst würden kaum noch klüger. Was besser werde, seien die Werkzeuge ("Harness") und die Art, wie ein Modell sie benutzt, aber nicht die eigentliche Denkleistung. Ich gehöre zum zweiten Lager, und dieser Text erklärt, warum das aus meiner Sicht logisch folgt.</p>
<h2>Was sich seit 2022 wirklich verbessert hat</h2>
<p>Zwischen dem Erscheinen von ChatGPT Ende 2022 und Ende 2024 sind die Modelle klar klüger geworden. Das bestreite ich nicht. Danach ändert sich das Muster. Der spürbare Fortschritt kommt seitdem <strong>weniger aus dem Modell selbst und mehr aus dem, was um das Modell herum passiert</strong>. Ein Assistent, der Dateien lesen, Code ausführen und Werkzeuge bedienen kann, wirkt deutlich fähiger, ohne dass das darunterliegende Modell fundamental mehr verstehen würde. Diese Umgebung ist der eigentliche Hebel der letzten Zeit.</p>
<p>Der häufigste Einwand lautet, dass die neuen Reasoning-Modelle doch ein echter Sprung seien. Das stimmt zur Hälfte, und die andere Hälfte ist für meine These entscheidend. Reasoning-Modelle sind teils echter Modellfortschritt, weil das Nachdenken über Zwischenschritte ins Training eingebaut wird. Teils sind sie aber schlicht mehr Rechenzeit zur Laufzeit, was Fachleute als <a href="https://www.emerge.haus/blog/test-time-compute-generative-ai">Test-Time-Compute</a> bezeichnen. Das Modell denkt länger, indem es mehr Anfragen an sich selbst stellt. Diese zusätzliche Denkzeit ist nicht kostenlos, sie wird in Tokens bezahlt. <strong>Bessere Antworten durch mehr Nachdenken heißt also fast immer teurere Antworten.</strong> Das ist wichtig, weil es den vermeintlichen Fähigkeitssprung direkt mit der Kostenfrage verbindet.</p>
<h2>Die Preise sind subventioniert</h2>
<p>Heute wirken LLMs billig. Das ist zu einem guten Teil eine Marktphase und nicht der Preis, der sich langfristig einstellen muss. Die Anbieter kämpfen um Nutzer und Marktanteile und geben die Token unter den Vollkosten ab. Dieses Muster kennt man aus dem Cloud-Geschäft: erst war alles günstig, bis alle drin waren, dann zogen die Preise an. Dasselbe sieht man im Fahrdienstgeschäft, wo die Preise nach der subventionierten Anfangsphase deutlich angezogen haben.</p>
<p>Ein häufiger Einwand ist, dass die Kosten pro Token seit Jahren sinken statt steigen, und das stimmt. Effizientere Modelle und bessere Hardware drücken die Kosten je Anfrage laufend. Mein Punkt ist ein anderer. <strong>Der heute gezahlte Preis liegt unter den echten Kosten, nicht über ihnen, und er muss sich ihnen über die Zeit annähern.</strong> Und selbst dort, wo die Kosten je Token fallen, frisst das teure Nachdenken der Reasoning-Modelle einen Teil davon wieder auf, weil es ein Vielfaches an Tokens verbraucht. Beides zusammen spricht gegen die Vorstellung, dass alles gleichzeitig schlauer und praktisch umsonst wird.</p>
<h2>Der Nutzen zeigt sich nicht dort, wo er zählt</h2>
<p>Der stärkste Einwand gegen meine Position lautet, die Effizienzgewinne seien riesig, ganze Tätigkeiten würden bald überflüssig. Wenn das so wäre, müsste man es nach etwa vier Jahren breiter LLM-Nutzung inzwischen deutlich sehen. Man sieht es auf der Ebene einzelner Aufgaben, und auf der Ebene ganzer Unternehmen sieht man es nicht. Diese Lücke ist der Kern meiner These.</p>
<p>Auf der Ebene einzelner Aufgaben sind die Gewinne real. Je nach Studie werden Einzelaufgaben um Werte im Bereich von grob zwanzig bis über fünfzig Prozent schneller erledigt. Goldman Sachs selbst nennt für einzelne, klar messbare Aufgaben einen Median von rund dreißig Prozent. Auf der Ebene ganzer Unternehmen und der Volkswirtschaft verschwindet dieser Effekt fast vollständig. Dieselbe Analyse von Goldman Sachs findet <a href="https://finance.yahoo.com/news/goldman-finds-no-meaningful-relationship-143553714.html">keinen belastbaren Zusammenhang zwischen Produktivität und LLM-Nutzung auf gesamtwirtschaftlicher Ebene</a>, und der Chefökonom fasst den Beitrag der gewaltigen Investitionen zum US-Wachstum 2025 mit <a href="https://www.tomshardware.com/tech-industry/artificial-intelligence/ai-boosted-us-economy-by-basically-zero-in-2025-says-goldman-sachs-chief-economist-we-think-theres-been-a-lot-of-misreporting-of-the-impact-that-ai-investment-had-on-gdp-growth">"basically zero"</a> zusammen.</p>
<p>Noch deutlicher wird es beim Blick in die Unternehmen. Eine <a href="https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/">MIT-Auswertung von 2025</a> kommt zu dem Ergebnis, dass rund <strong>fünfundneunzig Prozent der Enterprise-Projekte mit generativen Modellen keinen messbaren Ergebnisbeitrag</strong> liefern. In einer PwC-Umfrage 2026 sagt <a href="https://www.forbes.com/sites/guneyyildiz/2026/01/20/ai-productivitys-4-trillion-question-hype-hope-and-hard-data/">gut die Hälfte der Vorstände, sie hätten aus ihren Investitionen bislang nichts herausbekommen</a>.</p>
<p>Besonders sauber zeigt die Lücke eine kontrollierte Studie von METR aus dem Jahr 2025. Erfahrene Entwickler, die an ihren eigenen, gereiften Projekten arbeiteten, waren mit LLM-Werkzeugen im Schnitt <a href="https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/"><strong>neunzehn Prozent langsamer</strong></a>, glaubten aber selbst, sie seien zwanzig Prozent schneller gewesen. Die Studie ist klein, betrifft eine bestimmte Werkzeuggeneration, und METR selbst ordnet sie inzwischen als Momentaufnahme ein. Aber die Richtung passt genau zu den großen Zahlen. <strong>Das gefühlte Tempo und das gemessene Ergebnis fallen auseinander</strong>, und im Alltag großer Codebasen kann Hilfe sogar bremsen.</p>
<h2>Vibe Coding ist nicht Softwareentwicklung</h2>
<p>Die entscheidende Unterscheidung, die in der Debatte fast immer fehlt, ist die zwischen zwei völlig verschiedenen Tätigkeiten, die nur zufällig beide Code hervorbringen. Wer sie vermischt, kommt zwangsläufig zu falschen Schlüssen über den Markt.</p>
<p>Auf der einen Seite steht das, was oft Vibe Coding genannt wird. Jemand, der nicht wirklich programmieren kann, beschreibt in normaler Sprache, was er will, und das Modell liefert etwas, das läuft. Typisch ist ein kleines Werkzeug für den eigenen Bedarf, etwa damit man für eine simple Aufgabe kein Präsentationsprogramm öffnen muss. Das Ergebnis muss nur jetzt und nur für diese eine Person funktionieren. Niemand muss den Code verstehen, niemand muss ihn in ein größeres System einpassen, niemand pflegt ihn über Jahre, und niemand haftet, wenn er in einem halben Jahr nicht mehr funktioniert. Der Nutzen ist real, aber er ist privat und klein. <strong>Für die Gesamtbetrachtung ist er fast bedeutungslos.</strong> Sobald die Anfragen echtes Geld kosten, rechnet sich ein großer Teil dieser Bastellösungen ohnehin nicht mehr, und die Leute öffnen wieder das Präsentationsprogramm.</p>
<p>Auf der anderen Seite steht das, wofür Unternehmen wie SAP oder Uber tatsächlich Geld ausgeben. Diese Software muss über Jahre verlässlich laufen, von vielen Menschen weiterentwickelt werden, sich in andere Systeme einfügen, abgesichert sein und im Fehlerfall jemanden haben, der geradesteht. Hier besteht die Arbeit nur zu einem kleinen Teil aus dem Schreiben neuer Code-Zeilen. Der weitaus größere Teil ist Verstehen bestehender Zusammenhänge, Prüfen, Integrieren, Absichern, Warten und Abstimmen zwischen Menschen. Diese Teile kann ein Modell nicht übernehmen, weil sie Verantwortung und ein Verständnis des Ganzen verlangen, das über die einzelne Aufgabe hinausreicht. Ein Modell beschleunigt die isolierte Aufgabe. Es beseitigt nicht den Engpass, und der Engpass ist bei ernsthafter Software fast nie das Tippen.</p>
<p>Damit lösen sich die widersprüchlichen Zahlen auf. Die großen Speedups stammen aus der ersten Welt, aus abgegrenzten Einzelaufgaben. Die ausbleibende Wirkung auf Unternehmens- und Volkswirtschaftsebene stammt aus der zweiten Welt, in der das große Geld steckt. Wer aus einem Vibe-Coding-Erlebnis schließt, Softwareentwicklung sei bald gelöst, hat schlicht die beiden Welten verwechselt. <strong>Große Software braucht über Jahre echte Menschen, die sie führen und verantworten.</strong></p>
<p>Daraus folgt eine nüchterne Schätzung. Für ernsthafte Softwareentwicklung halte ich ein Einsparpotenzial in der Größenordnung von <strong>zehn bis zwanzig Prozent</strong> für realistisch, nicht die neunzig Prozent, die manchmal behauptet werden. Wer die hohe Zahl nennt, rechnet meist einen Task-Speedup hoch, der sich im Gesamtprozess nicht wiederfindet. Bemerkenswert ist, dass selbst überzeugte Vertreter der Disruptionsthese für den geordneten Fall am Ende von rund zehn Prozent Verbesserung sprechen und von steigenden Preisen, sobald der Markt verteilt ist. Damit landen sie bei genau den Werten, die ich hier verwende, ohne sie zu messen.</p>
<h2>Was der Kapitalmarkt gerade sagt</h2>
<p>Es gibt einen aktuellen Fall, an dem sich meine These überprüfen lässt, weil dort das Geschäft offen als der eigentliche Markt verkauft wurde. Im Jahr 2026 wurde xAI mit SpaceX verschmolzen und das gemeinsame Unternehmen an die Börse gebracht. <a href="https://www.sec.gov/Archives/edgar/data/1181412/000162828026036936/spaceexplorationtechnologi.htm">In den Unterlagen zum Börsengang</a> wurde ein Gesamtmarkt von rund achtundzwanzig Billionen Dollar aufgespannt, von dem <strong>über neunzig Prozent</strong> (26,5 von 28,5 Billionen) den Sprachmodellen über xAI zugeschrieben wurden. Der Raumfahrtanteil wurde bewusst klein gehalten. Die Erzählung war also das Modellgeschäft, nicht Raketen.</p>
<p>Die entscheidende Zahl steht im selben Dokument. xAI setzte 2025 rund 3,2 Milliarden Dollar um und schrieb dabei einen operativen Verlust von etwa <strong>6,4 Milliarden</strong>, der vollständig aus dem Gewinn von Starlink gedeckt werden musste. Ein als Zukunftsmarkt verkauftes Geschäft, das doppelt so viel verbrennt, wie es einnimmt, und von der Rakete quersubventioniert wird. Dass die Aktie dann innerhalb eines Monats <a href="https://www.bloomberg.com/news/articles/2026-07-16/spacex-post-listing-collapse-threatens-ipo-market-s-ai-euphoria">unter den Ausgabepreis</a> fiel, passt ins Bild, auch wenn dabei ein sehr kleiner frei handelbarer Anteil und die allgemeine Marktstimmung mitspielten. Der am reinsten über Sprachmodelle vermarktete Börsengang dieser Größe stützte sich auf einen astronomischen Markt, verbrannte dabei Geld, und der Markt zahlte den Preis nicht mit. Das passt zu der Vermutung, dass der versprochene Markt kleiner ist als die Erzählung.</p>
<h2>Warum das ein Plateau ergibt</h2>
<p>Jetzt lässt sich die Kette schließen. Die Modelle selbst werden kaum noch grundlegend klüger, der Fortschritt kommt aus Werkzeugen und aus zusätzlicher Rechenzeit. Diese Rechenzeit ist heute subventioniert und wird sich verteuern. Der reale Nutzen für ernsthafte Software liegt eher bei zehn bis zwanzig Prozent und schlägt gesamtwirtschaftlich kaum durch, weil das große Geld in Systemen steckt, die Menschen brauchen. Der Kapitalmarkt beginnt, genau das einzupreisen.</p>
<p>Ein berechtigter Einwand lautet, dass die großen Anbieter wie Google, Microsoft, Meta oder Nvidia ihre Modellentwicklung aus laufendem Konzerngewinn finanzieren und nicht auf Risikokapital angewiesen sind. Die Forschung hört also nicht auf, nur weil die Euphorie abkühlt. Das stimmt, ändert aber wenig. Auch diese Budgets richten sich nach dem erwarteten Ertrag, und wenn sich der Markt als deutlich kleiner erweist als versprochen, sinkt auch dort die Bereitschaft, jede neue Modellgeneration mit immer größeren und teureren Trainingsläufen zu erkaufen. Die Frage ist nicht, ob es weitergeht, sondern in welchem Tempo. Und dieses Tempo überschätzt die erste Position.</p>
<p>Wenn Unternehmen das moderate Potenzial einmal realisiert haben, gibt es keinen Grund mehr für immer neue, riesige Investitionsrunden in der Hoffnung auf einen viel größeren Markt. Sinkt aber der Zufluss an Kapital, sinkt auch das Budget für die Weiterentwicklung von Modellen und Werkzeugen. Damit verlangsamt sich das Tempo, das die erste Position als selbstverständlich annimmt. <strong>LLMs verschwinden nicht, sie werden ein nützliches Werkzeug mit begrenztem, gut abschätzbarem Nutzen.</strong> Das ist es, was ich mit Plateau meine.</p>
<h2>Was diese These widerlegen würde</h2>
<p>Damit der Text ehrlich bleibt, nenne ich den Punkt, an dem er kippt. Mein Kostenargument bricht, wenn frei verfügbare Modelle so gut und so effizient werden, dass sie leistungsfähig auf normaler Hardware vor Ort laufen. Dann wären die Anfragen faktisch fast umsonst, und teures Nachdenken bliebe billig. Diese Entwicklung schließe ich nicht aus, und die besten offenen Modelle sind bereits erstaunlich stark. Wichtig ist aber, dass dieser Einwand <strong>nur die Kostenseite trifft</strong>. Selbst wenn die Anfragen umsonst wären, bliebe der zweite Teil meiner These bestehen. Große Software braucht über Jahre echte Menschen, die sie sinnvoll führen und verantworten. Der billige Zugang macht das Werkzeug zugänglicher, aber er macht aus zehn bis zwanzig Prozent keine neunzig.</p>
<h2>Fazit</h2>
<p>Ich behaupte nicht, dass LLMs eine Modeerscheinung sind. Ich behaupte, dass der Abstand zwischen dem versprochenen und dem tatsächlichen Nutzen für ernsthafte Arbeit groß ist und dass dieser Abstand die weitere Entwicklung bremsen wird. Die Belege dafür liegen inzwischen vor, in Produktivitätsstudien, in gesamtwirtschaftlichen Zahlen und in der Reaktion des Kapitalmarkts. Wer anderer Meinung ist, muss zeigen, an welcher Stelle die Kette reißt. Genau darauf bin ich gespannt.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK10: Die 4 Zustände. Lernst du oder machst du nur Aktionismus?</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak10-die-4-zustaende-learning-oder-aktionismus.html"/>
        <id>https://no-bullshit-agile.de/nbak10-die-4-zustaende-learning-oder-aktionismus.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/207/nbak10-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-07-17T16:31:09+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/207/nbak10-cover.jpg" alt="Work Feedback Loop 4 Zustände" />
                    Dein Team liefert wie verrückt und wird trotzdem nicht besser? Dann steckt ihr wahrscheinlich im Aktionismus. In dieser Folge zeige ich die vier strukturellen Zustände des Work-Feedback Loops - Learning, Aktionismus, Frustration, Stagnation - und wie du erkennst, in welchem ihr gerade seid. Wichtig: Diese Zustände sind strukturell, nicht kulturell.
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/207/nbak10-cover.jpg" class="type:primaryImage" alt="Work Feedback Loop 4 Zustände" /></p>
                <p>Dein Team liefert wie verrückt und wird trotzdem nicht besser? Dann steckt ihr wahrscheinlich im Aktionismus. In dieser Folge zeige ich die vier strukturellen Zustände des Work-Feedback Loops - Learning, Aktionismus, Frustration, Stagnation - und wie du erkennst, in welchem ihr gerade seid. Wichtig: Diese Zustände sind strukturell, nicht kulturell.</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/97-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>Der Work-Feedback Loop hat zwei unabhängige Geschwindigkeiten: Work Speed - wie schnell das System Arbeit mit realem Effekt erzeugt -  und Feedback Speed - wie schnell dieser Effekt als relevantes Signal zurückkommt. Die meisten Organisationen optimieren nur die erste und übersehen die zweite. Genau dort sitzt aber oft der Engpass.</p>
<h2>Zusammenfassung</h2>
<p>Kombiniert man beide Geschwindigkeiten, ergeben sich vier Zustände. Im Learning-Quadranten (Work schnell, Feedback schnell) ist das System adaptiv – das ist der einzige Zustand, in dem strukturelles Lernen möglich ist, und er muss geschützt werden. Aktionismus (Work schnell, Feedback langsam) bedeutet viel Output bei niedriger Lernrate; der Engpass ist die Verarbeitung der Realität. Frustration (Work langsam, Feedback schnell) heißt: Probleme werden erkannt, aber nicht entschieden – der Engpass sitzt in der Entscheidung. Stagnation (beides langsam) ist doppelt blockiert. Entscheidend: Diese Zustände sind strukturell, nicht kulturell. Ein engagiertes Team kann in Frustration feststecken, eine disziplinierte Firma in Aktionismus. Und verschiedene Ebenen können gleichzeitig in verschiedenen Zuständen sein – ein Team im Learning, das Portfolio darüber in Stagnation. Das Modell ist kein Reifegrad, sondern ein Diagnose-Werkzeug: Finde den langsameren der beiden – das ist dein Engpass.</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich <a href="https://no-bullshit-agile.de/kontakt.html">hier</a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">hier</a></li>
<li>Das Modell im Detail: <a href="https://no-bullshit-agile.de/wfl/">Die Work-Feedback Loop</a></li>
<li>Buch "Agiles Arbeiten in der Praxis": <a href="https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html">hier</a></li>
<li>Diskutier mit auf <a href="https://mastodon.social/@nobsagile">Mastodon</a></li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei No Bullshit at Real Kompakt, mein Name ist Thomas.<br> In der letzten Folge haben wir die Einführung in die Work Feedback Loop gestartet<br> und wir haben darüber gesprochen, was Work und was Feedback überhaupt ist.<br> Wenn dich das interessiert, hör da gerne rein, den Link dazu findest du in den Show Notes.<br> Heute gehen wir dann den nächsten Schritt und schauen uns an, dass es eigentlich zwei Geschwindigkeiten gibt,<br> nämlich die Work Geschwindigkeit, die Geschwindigkeit, in der wir unsere Arbeit erledigen<br> und getrennt davon die Feedback Geschwindigkeit.<br> Und wenn man das kombiniert, erhält man vier Zustände und ich finde, die vier Zustände helfen auch wieder sehr gut zu diagnostizieren,<br> wo hast du vielleicht im agilen Arbeiten ein Problem.<br> Ich will aber vorab einmal ganz kurz noch das Thema Work und Feedback versuchen, ein bisschen besser zu definieren.<br> Wenn ich von Work spreche, spreche ich von einer Aufgabe, die zu erledigen ist.<br> Dabei geht es nicht um, ist es ein Epic, ist es eine Story, ist es ein Task, sondern es gibt eine Aufgabe.<br> Ein Stück Software soll erstellt und geliefert werden.<br> Ich verallgemeine hier also, wir wollen etwas Kleines.<br> Storys sollen klein sein, unsere Arbeit soll möglichst klein sein, Sinnvolles liefern.<br> Das nenne ich dann Work.<br> Und dann bekomme ich Feedback.<br> Feedback von echten Usern, die dieses Stück Arbeit, dieses Work benutzen.<br> Ich habe ja dieses Stück Arbeit aufgeschrieben und gesagt, das entwickeln wir als nächstes, weil ich eine Hypothese hatte.<br> Wir müssen diesen Teil des Logins verbessern, wenn wir jetzt über Webentwicklung sprechen.<br> Und wir haben auch eine Hypothese, warum wir es verbessern müssen.<br> Und wir erhalten dann hoffentlich zeitnah ein Feedback der User.<br> Und bei Usern geht es mir um die Benutzer des Systems.<br> Feedback, das hatte ich in der letzten Folge auch schon gesagt, kann sowas sein wie Analytics-Daten.<br> Natürlich auch echtes User-Feedback durch Umfrage oder durch ein Usability-Lab.<br> Also wir wollen nicht vom Auftraggeber, wenn da einer dazwischen ist, ein Feedback,<br> sondern wir wollen von den Benutzern des Systems ein Feedback.<br> Es geht ja ums Lernen.<br> Das ist das Fundament von agilem Arbeiten.<br> Das Fundament ist, ich bin mir nicht sicher, wie ich ein bestimmtes Problem lösen soll.<br> Wie wir das Login wirklich verändern.<br> Also stelle ich die Hypothese auf, wir verändern das Login wie folgt.<br> Ich entwickle das, ich packe das in die Welt da draußen und bekomme jetzt ein Feedback der User,<br> ob meine Hypothese gestimmt hat oder nicht.<br> Und dieses Feedback soll wieder in den nächsten Schritt von Work einfließen,<br> damit eine Sicherheit da ist, dass ich auf dem Markt vernünftig agieren kann.<br> Das ist mir halt nochmal ganz wichtig, dass ihr Work und Feedback wirklich auch so versteht.<br> Gut, dann würde ich sagen, steigen wir mal jetzt in den nächsten Teil ein.<br> Ich habe zwei Geschwindigkeiten.<br> Also ich arbeite eine Aufgabe ab.<br> Das dauert eine gewisse Zeit.<br> Also keine Ahnung.<br> Das hängt am Release-Zyklus ab.<br> Wie schnell ihr überhaupt was releasen könnt.<br> Ob ihr von Hand testet, ob ihr automatisierte Tests habt, ob ihr eine Kombination habt, ob ihr permanent testen könnt.<br> Du kannst dir vorstellen, es gibt viele, viele Gründe, woran die Geschwindigkeit der Arbeit hängen kann.<br> Also die Work-Geschwindigkeit ist die Geschwindigkeit von, ich starte eine Aufgabe bis die Aufgabe ist in Produktion und benutzbar.<br> Eine ganz andere Geschwindigkeit ist dann die Feedback-Geschwindigkeit.<br> Wie schnell erhalte ich ein relevantes Signal zurück, das ich koppeln kann mit der Arbeit, die ich da gemacht habe.<br> Also, ich bekomme ein Feedback zu dieser Veränderung des Login-Mechanismus, dann ist das gekoppelt.<br> Wie lange dauert das, bis ich dieses Feedback bekomme?<br> Und nochmal, irgendein Feedback zu irgendetwas anderem ist nicht gekoppelt.<br> Das hat mit meiner Arbeit nichts zu tun.<br> Nur wenn ich es koppel, kann ich daraus lernen.<br> Und in der Regel, und das kenne ich von mir auch, ist es so, dass die Feedback-Geschwindigkeit wahrscheinlich der begrenzende Faktor ist.<br> Es dauert in der Regel ein bisschen länger, oder auch sehr viel länger, hängt ein bisschen davon ab,<br> bis ich Feedback zu meiner gelieferten Arbeit von den Usern bekomme,<br> als es gedauert hat, diese Arbeit in Produktion zu bringen.<br> Und wenn man das jetzt mal in so einem Quadranten malt,<br> ich blende dir hier so eine Kapitelmarke ein, dann siehst du so eine Grafik.<br> Und wir uns so vier Quadranten vorstellen.<br> Links auf der Y-Achse haben wir die Geschwindigkeit der Arbeit.<br> Links unten langsam, links oben schnell.<br> Und horizontal, die X-Achse, haben wir die Geschwindigkeit des Feedbacks.<br> Links ist die Geschwindigkeit langsam und rechts ist die Geschwindigkeit schnell.<br> Dann haben wir vier Quadranten.<br> Und oft genug ist es so, dass wir nicht in dem Quadranten sind, in dem wir sein wollen.<br> Wir wollen die gleiche Geschwindigkeit zwischen Arbeit, Work und Feedback,<br> damit wir unseren Zyklus, unsere Kopplung insgesamt schnell durchgehen können.<br> Diesen Teil, schnelle Arbeit, schnelles Feedback.<br> Wir wollen das natürlich versuchen, so sicher und so schnell wie möglich zu machen.<br> Den habe ich Learning genannt.<br> Jetzt haben wir ein System, in dem die nächste Arbeit einen Einfluss hat,<br> und zwar von dem Feedback, das ich bekommen habe.<br> Also kann mein Unternehmen, kann meine Software, kann mein Produkt lernen.<br> Sehr, sehr oft ist es so, dass zwar die Arbeitsgeschwindigkeit schnell ist,<br> aber die Feedbackgeschwindigkeit langsam.<br> Es dauert Ewigkeiten, also fange ich schon mal irgendwas Neues an.<br> In dem Moment rate ich halt.<br> Ich rate, was man wohl als nächstes tun muss.<br> Und diesen Quadranten habe ich Aktionismus genannt.<br> Der andere Fall, die Arbeit ist langsam, Work ist langsam und Feedback ist schnell,<br> das ist Frustration.<br> Da kommt immer schnell Feedback, viel Feedback, du müsstest das verändern,<br> du müsstest das verändern und ich kriege das nicht abgearbeitet.<br> Und der letzte Quadrant, das ist das, wenn die Arbeit langsam ist<br> und das Feedback langsam ist, ist Stagnation.<br> Da werde ich rechts und links auf dem Markt von anderen überholt.<br> Wenn man sich diese Quadranten jetzt mal anguckt,<br> dann können wir nochmal so einen Side-Step hin zu AI machen,<br> denn AI, das wissen wir alle, beschleunigt zwar den Work-Teil,<br> aber eben nicht den Feedback-Teil.<br> Den können nur echte User liefern.<br> Also kann ich den auch nicht weiter beschleunigen.<br> Und deswegen ist in der Arbeit mit AI, dieser Feedback-Teil,<br> der begrenzende Faktor.<br> Es mag ja sein, dass ich meinen Work-Teil die Geschwindigkeit erhöhen kann,<br> aber die Grenze bildet der Feedback-Teil.<br> Denn sonst lande ich wieder in diesem Aktionismus-Bereich.<br> Also ich arbeite und arbeite, ich schubse Code raus,<br> es gibt Releases über Releases,<br> mein Produkt wird immer größer, immer voller,<br> aber das Feedback kommt einfach nicht an.<br> Da sehen wir zum Beispiel an Jira, um ganz ehrlich zu sein.<br> Da steckt so viel Quatsch drin, ich kann mir wirklich nicht vorstellen,<br> dass das alles auf User-Feedback basiert.<br> Um das vielleicht an dieser Stelle noch zu sagen,<br> diese Zustände, in denen dann Teams oder Unternehmen sind,<br> das hat nichts mit Haltung oder Motivation oder so zu tun.<br> Ein engagiertes Team kann komplett in diesem Frustrationsbereich feststecken.<br> Es kann eine disziplinierte Firma geben, die komplett im Aktionismus lebt.<br> Und wie so oft, ehrlich gesagt, so gut wie immer,<br> die Ursache liegt nicht an Menschen oder so,<br> sondern sie liegt am System und in unserem Fall an der Kopplungsgeschwindigkeit.<br> Wenn du Software entwickelst, du aber keinen direkten Kontakt zu deinen Usern hast,<br> weil ein Auftraggeber dazwischen ist zum Beispiel,<br> dann ist das super frustrierend und du wirst nie ein gutes Ergebnis erzielen.<br> Aber das Diagnose-Tool Work-Feedback-Loop hilft dir, das besser anfassbar zu machen.<br> Das ist ja genau die Idee hinter diesem Diagnose- und Denkmodell Work-Feedback-Loop.<br> Du siehst es jetzt einfach viel transparenter, wo das Problem überhaupt ist.<br> Und wir wissen alle, Theory of Constraints, wir suchen eigentlich immer nach dem Engpass<br> und da hilft dir dieses Schaubild, da hilft dir das Verständnis von<br> was ist mit Arbeit, mit Work gemeint, was ist mit Feedback gemeint<br> und dir hilft das Verständnis, dass da eine enge Kopplung zwischen beiden sein muss,<br> sonst sind wir gar nicht im agilen Arbeiten<br> und dann suchst du halt wie sonst auch den Engpass.<br> Ja, und eigentlich soll es das gewesen sein,<br> ich habe so das Gefühl, die Folge ist ein bisschen länger geworden als 5 Minuten,<br> ist wahrscheinlich gar nicht so schlimm.<br> Wie immer, ich freue mich auf kritische Anmerkungen dazu,<br> ich freue mich auf dein Feedback,<br> ich freue mich, wenn du die Feedback-Loop, die Work-Feedback-Loop liest,<br> ich habe das ja als PDF oder als Webseite auch veröffentlicht,<br> den Link dazu findest du in den Shownotes<br> und ich würde mich freuen, wenn wir darüber in den Austausch kommen.<br> In der nächsten Folge, Folge 11, wird es dann darum gehen,<br> dass dein Team gar nicht langsam ist, sondern euer Feedback zu spät kommt.<br> Da geht es mir um die Feedback-Response-Time.<br> Was heißt das jetzt schon wieder?<br> Naja, das bedeutet, oft genug muss man sich die Zeit angucken,<br> die es braucht, bis ein Feedback ankommt und eine Arbeit beeinflusst<br> und diese beeinflusste Arbeit dann wieder in Produktion ist.<br> Und wir lernen dabei dann übrigens auch,<br> dass eine Feedback decayt.<br> Also ein Feedback, das ich sofort verarbeiten kann,<br> ist mehr wert als ein Feedback,<br> das ich erst nach 3 oder 5 oder 8 Monaten bearbeite,<br> weil dieses Feedback gar keine Gültigkeit mehr haben kann.<br> Gut, das soll es dann tatsächlich für heute gewesen sein.<br> Hab noch eine ganz tolle Woche<br> und bis zum nächsten Mal.<br> Ciao, ciao.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK09: Work - Feedback. Der einzige Kreislauf, der zählt</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak09-work-feedback-der-einzige-kreislauf.html"/>
        <id>https://no-bullshit-agile.de/nbak09-work-feedback-der-einzige-kreislauf.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/206/nbak09-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-07-10T17:22:00+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/206/nbak09-cover.jpg" alt="Work und Feedback" />
                    Wenn man allen Ballast abwirft - Zertifikate, Rollen, Rituale - bleibt der Kern von agilem Arbeiten übrig: Work und Feedback. In dieser Folge stelle ich mein eigenes Modell vor, die Work-Feedback Loop, und erkläre, warum Feedback, das die nächste Arbeit nicht verändert, gar kein Feedback ist - und warum das&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/206/nbak09-cover.jpg" class="type:primaryImage" alt="Work und Feedback" /></p>
                <p>Wenn man allen Ballast abwirft - Zertifikate, Rollen, Rituale - bleibt der Kern von agilem Arbeiten übrig: Work und Feedback. In dieser Folge stelle ich mein eigenes Modell vor, die Work-Feedback Loop, und erkläre, warum Feedback, das die nächste Arbeit nicht verändert, gar kein Feedback ist - und warum das ein Kopplungs- und kein Mindset-Problem ist.</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/96-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>Wir schleppen uns zu Dailies, schätzen Story Points und pflegen Boards, und trotzdem dauert es Monate, bis Arbeit beim echten Nutzer ankommt. Diese Folge startet Block 2 der <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">Serie</a> und reduziert agiles Arbeiten auf das Wesentliche: einen Kreislauf aus Work und Feedback, dessen Geschwindigkeit über die Lernfähigkeit eines Systems entscheidet.</p>
<h2>Zusammenfassung</h2>
<p>Die Work-Feedback Loop ist eine Wirkungskette: Work erzeugt einen realen Effekt, dieser Effekt wird als Feedback sichtbar, führt zu einer Entscheidung und verändert die nächste Arbeit. Nur wenn alle vier Schritte gekoppelt sind, lernt das System. Der einzige Maßstab für Agilität ist die Geschwindigkeit dieses Kreislaufs - nicht die Zahl der Zertifikate oder Code-Zeilen. Geschwindigkeit heißt dabei nicht Hektik, sondern die Fähigkeit, schnell zu lernen, ohne Qualität, Sicherheit oder UX zu opfern; dafür braucht es Skills, nicht neue Meetings. Der wichtigste Satz der Folge: Feedback ist erst dann Feedback, wenn es die nächste Arbeit verändert. Wenn ein System auf ein Signal nicht reagiert, ist das kein Mindset-Problem, sondern ein Kopplungsproblem.</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich <a href="https://no-bullshit-agile.de/kontakt.html">hier</a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">hier</a></li>
<li>Das Modell im Detail: <a href="https://no-bullshit-agile.de/wfl/">Die Work-Feedback Loop</a></li>
<li>Buch "Agiles Arbeiten in der Praxis": <a href="https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html">hier</a></li>
<li>Diskutier mit auf <a href="https://mastodon.social/@nobsagile">Mastodon</a></li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei No Bullshit Agile Kompakt, mein Name ist Thomas.<br> Mit der letzten Folge, der Folge 8, mit dem Thema warum Agilität nicht tot ist,<br> haben wir hier bei der Reise in BA Kompakt tatsächlich das Fundament abgeschlossen<br> und im nächsten Schritt und damit zuallererst mal mit dieser Folge geht es jetzt um den Kern von agilem Arbeiten.<br> Und im Prinzip ist agiles Arbeiten zweierlei, auf der einen Seite haben wir Arbeit, Work<br> und auf der anderen Seite haben wir Feedback und daraus ergibt sich ein Kreislauf, ein Zyklus, eine Kopplung.<br> Das Feedback soll Einfluss haben auf die Arbeit, Work und Feedback sind gekoppelt.<br> Das einzige Maß, was wir hier haben, der große Maßstab, an dem wir uns orientieren sollen, ist jetzt,<br> was für eine Geschwindigkeit haben wir, in welcher Geschwindigkeit dreht sich dieser Kreislauf.<br> Also Work mit einer Handlungsabsicht, wir haben etwas vor, weil wir eine Hypothese haben und deswegen wollen wir etwas implementieren.<br> Dann haben wir das Feedback dazu, da gleichen wir das Feedback, was wir bekommen haben, mit unserer Handlungsabsicht ab<br> und treffen eine Entscheidung, was das für uns bedeutet, für die nächste Arbeit, also für den nächsten Teil Work.<br> Und fundamental wichtig, und das ist für mich das Fundament von agilem Arbeiten,<br> wenn das Feedback die nächste Arbeit nicht verändert, dann ist es nicht wirklich ein Feedback.<br> Und das bedeutet eben, wir haben dann nicht irgendwie ein Mindset-Problem oder ein Team-Problem im agilen Arbeiten,<br> sondern was wir in Wirklichkeit haben, ist halt ein Kopplungsproblem.<br> Work und Feedback sind eben nicht gekoppelt.<br> Um mal einzusteigen, ein bisschen in die Denke, man kann sich natürlich mal die Frage stellen,<br> die habe ich mir dann auch gestellt, warum veranstalten wir diesen ganzen Zirkus überhaupt?<br> Daily Storypoints, Methoden, Jira-Boards, Abläufe, warum tun wir uns das überhaupt an?<br> Und vor allen Dingen, wenn es dann doch Monate dauert, bis irgendetwas Neues in Produktion ist,<br> beim Nutzer ankommt und wir die erste Chance haben auf dem Feedback.<br> Oft genug, und das ist so ein bisschen auch der Anlass gewesen,<br> warum ich diese Word-Feedback-Loop, dieses Denkmodell angefangen habe zu schreiben,<br> haben wir halt in meinen Augen ein bisschen den Fokus verloren.<br> Wir diskutieren über Save vs. Scrum, wir diskutieren über alle möglichen Dinge,<br> aber darunter haben wir ein Riesenproblem, unser Handwerk ist verrottet,<br> denn das Handwerk ist Work und Feedback.<br> Und deswegen finde ich es schön und befreiend, mal alles wegzulassen,<br> alles, was du über agiles Arbeiten weißt,<br> und sich wirklich mit dieser Kopplung nur zu beschäftigen,<br> die Kopplung zwischen Work und Feedback.<br> Und das Ganze hier, diese Folge, ist jetzt der Start.<br> Ich werde jetzt ein paar mehr Folgen machen,<br> um dieses Denkmodell von mir, die Work-Feedback-Loop, ein bisschen auseinanderzunehmen.<br> Ja, wie schon gesagt, wir reduzieren mal alles auf Skelett.<br> Wir haben Work, wir arbeiten an etwas,<br> wir haben eine Hypothese aufgestellt, warum wir daran arbeiten,<br> wir bekommen möglichst schnell ein Feedback dazu,<br> und wir können unsere Hypothese mit der Wirklichkeit vergleichen<br> und aufgrund dessen eine Entscheidung treffen,<br> die dann in die nächste Arbeit einfließt.<br> Und diese Loop wollen wir so schnell und so sicher wie möglich drehen.<br> Sicher meint hier halt, wir wollen dabei halt keine oder so gut wie keine Fehler machen.<br> Und was mir auch wichtig ist, das ist hier kein Ablaufplan,<br> das ist keine To-Do-Liste,<br> sondern hier geht es mir eben um eine Kopplung und eine Wirkungskette.<br> Weil ich es schon höre und ich es auch nachvollziehen kann,<br> wäre für mich noch Folgendes wichtig.<br> Man könnte denken, weil ich jetzt ja dieses Geschwindigkeitsthema reingebracht habe,<br> naja, wenn wir jetzt einfach schneller coden,<br> dann bricht uns das System zusammen.<br> Und das ist vollkommen richtig.<br> Und gerade über die letzten drei, vier Jahre,<br> gefühlt in meinen Augen, vor allen Dingen in 2025,<br> ist durch LLMs jetzt eben noch das deutlich offensichtlicher geworden.<br> Wir erhöhen einen Teil der Geschwindigkeit,<br> die Work-Geschwindigkeit,<br> und wundern uns, dass das System nach einem halben Jahr dann doch zusammenbricht.<br> Und das meine ich eben damit.<br> Wir brauchen eine richtige Geschwindigkeit.<br> Die kann vielleicht aufgrund von Regulatorien oder so langsam sein,<br> aber sie muss halt so schnell wie möglich sein.<br> Und der Fokus auf Work und Feedback hilft dir eben genau das zu erkennen.<br> Und das ist das Fundament, warum ich das Ganze auch Denkmodell nenne.<br> Das ist keine Methode oder so, die man anwendet,<br> sondern es soll dich in die Lage versetzen,<br> intensiver darüber nachzudenken,<br> wie funktioniert mein System und wo ist denn was kaputt.<br> Um das System stabil zu halten,<br> brauchen wir halt grundsätzlich mal Skills,<br> und zwar auf beiden Seiten des Kreislaufs.<br> Und jetzt siehst du auch, wie das Bild sich langsam schließt.<br> Wenn wir auf die Work-Seite gucken,<br> um das stabil zu halten,<br> brauchen wir Kenntnisse in der Architektur,<br> wir brauchen Testing, wir brauchen DevOps,<br> wir brauchen gutes Slicing von Storys.<br> Die Liste kann man viel, viel länger machen.<br> Und auf der anderen Seite, auf der Feedback-Seite,<br> brauchen wir sowas wie Usability-Untersuchungen,<br> wir brauchen Analytics-Daten,<br> wir brauchen schnelle Feedback-Kanäle zu unseren Usern.<br> Und dann siehst du,<br> da tauchen jetzt auf einmal wieder alle Begriffe auf,<br> die wir also kennen.<br> Ich habe ja mal über den agilen Eisberg gesprochen<br> und die Dinge, die unterhalb der Wasseroberfläche sind,<br> das sind die Dinge,<br> die Work und Feedback sicher machen.<br> Der fundamentale Satz für diese Folge ist tatsächlich für mich,<br> Feedback ist keine Information.<br> Es ist erst dann Feedback,<br> wenn das nächste Stück Arbeit dadurch verändert wird.<br> Ist das nicht der Fall,<br> nutzt uns dieses Feedback nichts.<br> Und oft genug reagieren wir auf Signale nicht gut genug,<br> weil es zu teuer ist,<br> weil das Feedback zu spät ankommt.<br> Da kann man eine lange Liste machen,<br> da gibt es nochmal eine explizite Folge dazu.<br> Aber das ist halt sehr wichtig zu verstehen.<br> Agiles Arbeiten bedeutet,<br> wir sind in einem komplexen Umfeld<br> und wir müssen eben anerkennen,<br> dass wir etwas liefern mit einer Hypothese<br> und es prüfen müssen.<br> Work und Feedback.<br> Was du machen kannst,<br> kleiner Praxistest für dich.<br> Nimm dir mal irgendwas ganz Konkretes,<br> an dem du gerade arbeitest.<br> Ein Release, vielleicht ein Meeting,<br> irgendeine Policy, die ihr vielleicht habt.<br> Und frag dich mal,<br> welchen realen Effekt soll das denn haben?<br> Wo und wann wird dieses Signal sichtbar,<br> was wir uns da erarbeiten?<br> Wann können wir eine bindende Entscheidung darauf treffen?<br> Und diese Entscheidung,<br> die wir da treffen,<br> verändert die wirklich die nächste Arbeit?<br> Ist da wirklich eine Kopplung da?<br> Ich bin mir ganz sicher,<br> oft genug wirst du feststellen,<br> da ist keine Kopplung.<br> Und dann scheitert agiles Arbeiten.<br> Und es ist eben wichtig,<br> diesen fundamentalen Blick zu behalten<br> und die Kopplung nicht zu vergessen.<br> Ein Feedback, das irgendwann kommt,<br> kann zum Beispiel viel zu spät kommen.<br> Gut, das soll hier kurz und kompakt<br> jetzt tatsächlich mal der Einstieg<br> in dieses Denkmodell Work-Feedback-Loop sein.<br> Das lange Dokument dazu,<br> das verlinke ich dir natürlich auch in den Shownotes.<br> Schaut da gerne schon mal rein.<br> Aber wie gesagt, die nächsten Folgen,<br> da nehme ich das jetzt auch tatsächlich<br> ein bisschen weiter auseinander.<br> Also wir merken uns,<br> agiles Arbeiten ist Work und Feedback<br> und das muss eng gekoppelt sein.<br> Und diese Kopplung,<br> die muss auch relativ schnell sein.<br> Und im Prinzip mal ist alles andere jetzt bei Werk,<br> um diesen Kern gut zu machen.<br> Ja, ganz konkret werde ich in der nächsten Folge<br> darüber sprechen,<br> dass es vier Zustände gibt,<br> wenn man sich Work und Feedback anguckt<br> und überlegt,<br> wie gut sind die gekoppelt oder nicht gekoppelt.<br> Und da werden wir feststellen,<br> ganz, ganz viel ist tatsächlich<br> in so einem Quadranten,<br> den ich dann Aktionismus genannt habe.<br> Ja, ansonsten würde ich sagen,<br> das soll es für heute auch schon gewesen sein.<br> Ich freue mich wie immer über Feedback,<br> gerne auch über kritisches Feedback.<br> Wie du mich erreichst,<br> findest du in den Shownotes.<br> Und ansonsten sage ich,<br> habe noch eine ganz tolle Woche<br> und bis zum nächsten Mal.<br> Ciao, ciao.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK08: Warum Agilität nicht tot ist</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak08-warum-agilitaet-nicht-tot-ist.html"/>
        <id>https://no-bullshit-agile.de/nbak08-warum-agilitaet-nicht-tot-ist.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/205/nbak08-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-07-04T14:34:49+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/205/nbak08-cover.jpg" alt="Agiles Arbeiten ist nicht tot" />
                    "Agilität ist tot". Diese These flammt regelmäßig auf. Ich halte sie für grundfalsch. Was wirklich gescheitert ist: Fake Agile, Dark Agile und die kommerzialisierte Komplexität. Warum das Label "Agile" verbrannt sein darf, das Handwerk aber gerade erst anfängt. Wenn Agilität angeblich tot ist, was ist dann die Alternative? Zurück zum&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/205/nbak08-cover.jpg" class="type:primaryImage" alt="Agiles Arbeiten ist nicht tot" /></p>
                <p>"Agilität ist tot". Diese These flammt regelmäßig auf. Ich halte sie für grundfalsch. Was wirklich gescheitert ist: Fake Agile, Dark Agile und die kommerzialisierte Komplexität. Warum das Label "Agile" verbrannt sein darf, das Handwerk aber gerade erst anfängt.</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/95-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>Wenn Agilität angeblich tot ist, was ist dann die Alternative? Zurück zum Wasserfall? In dieser Folge nehme ich die "Agile ist tot"-Debatte auseinander und zeige, dass sich der berechtigte Frust nicht gegen den Kern von Agilität richtet, sondern gegen ein Zerrbild.</p>
<h2>Zusammenfassung</h2>
<p>Drei Muster befeuern die Frustration: Fake Agile (Methode ohne Verständnis der Basis), Dark Agile (agiler Deckmantel über weiterhin top-down gesteuerter Kontrolle) und die Kommerzialisierung, die schlanke Prinzipien mit immer mehr Komplexität überlädt. Dazu kommt die Scrum-Zwickmühle: Seine Einfachheit macht ihn erfolgreich und verleitet dazu, alle Rituale zu befolgen, ohne agil zu sein. Agilität lebt dort, wo Time-to-Market und Cost of Delay zählen; sie stirbt, wo sie zum Produkt für alle wird. Der Weg nach vorn heißt Back to Basics: das Label loslassen und vom Handwerk sprechen: Agiles Arbeiten als Iteration und Feedback.</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich <a href="https://no-bullshit-agile.de/kontakt.html">hier</a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">hier</a></li>
<li><a href="https://no-bullshit-agile.de/wfl/">Die Work-Feedback Loop</a></li>
<li>Buch "Agiles Arbeiten in der Praxis": <a href="https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html">hier</a></li>
<li>Diskutier mit auf <a href="https://mastodon.social/@nobsagile">Mastodon</a></li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei NoBullshit Agile Compact, mein Name ist Thomas.<br> In der letzten Folge habe ich über das Agile Manifest als ökonomische Strategie gesprochen.<br> Da ging es mir darum, das Agile Manifest mal ein bisschen anders zu beleuchten.<br> Wenn dich das interessiert, den Link und alle weiteren Links findest du wie immer in den Shownotes.<br> Heute geht es als Abschluss zu dem ersten Teil von NBA Compact, das Fundament tatsächlich darum nochmal zu beleuchten,<br> warum ich denke, dass es Quatsch ist, wenn Leute behaupten, Agilität sei tot, agiles Arbeiten ist tot.<br> Das halte ich für grundsätzlich mal falsch.<br> Ich glaube, was tot ist, und das ist auch schön so, ist das Zerrbild darum, was denn agiles Arbeiten ist.<br> Also sowas wie Fake Agile oder Dark Agile, das Thema Kackokult, über das ich hier gesprochen habe,<br> und auch die Kommerzialisierung rund um agiles Arbeiten.<br> Und ja, es mag sein, dass dieses Label verbrannt ist, aber ich glaube, das Handwerk lebt.<br> Iteration, Work und Feedback.<br> Es geht mir um Back to Basics.<br> Gut, wie kommt der Eindruck zustande, warum sagen Leute, Agilität oder agiles Arbeiten ist tot?<br> Ja, wie gesagt, ich glaube, es sind drei fundamentale Dinge.<br> Das erste ist Fake Agile.<br> Wir müssen agil werden und dann nutzen wir Scrum als eine Art Einstiegsdroge,<br> weil das eben einfach und transparent ist.<br> Aber ohne die Basis, ohne das Verständnis dahinter, Work und Feedback, wir müssen schnell auf den Markt reagieren,<br> ja, verschwindet das alles.<br> Und wir haben halt dieses Fake Agile.<br> Wir haben Rituale und verstehen nicht, warum wir diese Rituale überhaupt haben.<br> Das heißt übrigens auch nicht, dass Scrum tot ist.<br> Manchmal liest man auch das, aber für viele ist einfach Scrum gleich mit agilem Arbeiten.<br> Aber das stimmt natürlich auch überhaupt nicht.<br> Eine Methode, wie Scrum oder wie kann man, die implementiert ja nur die fundamentalen Dinge von agilem Arbeiten.<br> Die zweite mögliche Ursache, die deutlich schlimmer ist in meinen Augen, ist tatsächlich Dark Agile.<br> Also wir haben so einen Deckmantel, den haben wir uns bewusst gewählt.<br> Der Deckmantel lautet agiles Arbeiten.<br> Der Deckmantel lautet dann vielleicht im Detail Scrum.<br> Und jetzt nutzen wir diesen Deckmantel, um top-down doch alles zu steuern, bis hin zum Micromanagement.<br> Wir planen Wochen über Wochen oder Monate Sprints voraus, weil wir ja eine Velocity haben.<br> Wir nutzen das Daily, um Leuten im Prinzip die To-Do-Listen ins Heft zu kleben, sage ich mal, in die Story zu schreiben.<br> Und du machst das und du machst das.<br> Das ist dann halt bewusst den Deckmantel gewählt, agiles Arbeiten, um dann doch nach innen hin eher Micromanagement zu machen, um nach außen hin vielleicht moderner zu wirken, sage ich mal.<br> Und die dritte große Ursache meiner Meinung nach ist die permanente Kommerzialisierung rund um alles, was agiles Arbeiten anbelangt.<br> Also, Zertifikatswut fällt mir da ein.<br> Es werden immer und immer mehr und es wurden immer und immer mehr Zertifikate erfunden, die man ja Leuten wunderschön verkaufen kann.<br> Oder Coaching-Flut.<br> Nichts gegen agile Coaches.<br> Es gibt ganz viele da draußen, die einen ganz tollen Job machen.<br> Aber es war halt auch so oder ist zum Teil auch noch so, dass viele sich einfach diesen Titel auch gegeben haben und denen ging es nicht darum, dass ein Produkt besser entwickelt wird oder ein Team sich besser entwickelt, sondern denen ging es eigentlich nur darum, ja, einen Coaching-Job zu haben mit diesem Deckmantel, agiles Arbeiten.<br> Das sieht man übrigens wunderschön, dass ganz viele dieser Leute auf einmal AI-Coach sind.<br> Auch ganz lustig.<br> Ja, und diese Frustration, die da drin steckt, agiles Arbeiten ist tot, die ist total verständlich und auch berechtigt.<br> Aber ich glaube eben einfach, es geht hier um dieses Zerrbild, die Disjungtheit zwischen was Leute denken, was agiles Arbeiten ist und was es eigentlich im Fundament ist.<br> Ja, ein bisschen herausheben, vielleicht an dieser Stelle tatsächlich noch mal ganz kurz diese Scrum-Zwickmühle, habe ich es genannt.<br> Wie gesagt, für viele ist Scrum und agiles Arbeiten deckungsgleich.<br> Und das Schöne an Scrum, die Einfachheit, das klare Playbook, ist natürlich auch ein bisschen das Problem von Scrum.<br> Also man wendet das an und denkt, ist agil, aber es gehört halt deutlich mehr dazu, als den Scrum-Guide anzuwenden.<br> Und deswegen schimpfen viele sofort auf Scrum, weil das der erste Blick auf agiles Arbeiten ist.<br> Aber lasst mal das arme Scrum in Ruhe.<br> Wenn man das richtig macht, ist das tatsächlich eine ganz tolle Methode.<br> Und ja, das trägt halt leider zu diesem Zerrbild bei.<br> Wann lebt jetzt agiles Arbeiten und wann ist es vielleicht wirklich tot?<br> Agiles Arbeiten fühlt sich da wohl, wo es darum geht, sowas wie Time-to-Market und Cost-of-Delay haben einen großen Wert.<br> Ich muss auf einem Markt schnell agieren oder reagieren.<br> Es hat dann einen Wert, wenn ich in einem komplexen Umfeld unterwegs bin.<br> Wenn ich halt nicht so genau weiß, wie kann ich ein Ziel erreichen.<br> Und unabhängig von der Methode ist das zumindest für mich die einzige Möglichkeit, in so einem Umfeld etwas zu entwickeln.<br> In meinem Fall rede ich ja immer von Software entwickeln.<br> Dort, wo das alles gar nicht gegeben ist, dieser Rahmen.<br> Also da müsst ihr auch nicht agil arbeiten.<br> Und da agiles Arbeiten anzuwenden, ist vielleicht auch nur ein Overhead.<br> Für mich, und das hatte ich Ende letzten Jahres auch schon mal in einem Blogpost geschrieben, ist es halt so, ich habe so das Gefühl, wir sind jetzt wirklich an einem Punkt einfach auch angelangt, wo wir dieses Label mal loslassen müssen.<br> Und wo wir mehr ins Handwerk gehen müssen.<br> Wir müssen eben uns klar machen, worauf kommt es wirklich an.<br> Und der Kern des Ganzen ist dieser Zyklus Work und Feedback über alles im System, über alles in der Organisation.<br> Und deswegen habe ich diese Work-Feedback-Loop tatsächlich auch mal zusammengeschrieben.<br> Und damit wird es dann in der nächsten Folge tatsächlich auch weitergehen, um diesen Begriff agiles Arbeiten einfach mal nicht mehr benutzen zu müssen, um gedanklich mal wegzukommen von dem, was Leute alles reininterpretieren in diesen Begriff.<br> Und ja, das soll tatsächlich auch schon der Abschluss sein.<br> Mir geht es eben, wie gesagt, darum, back to the basics, zurück zum Handwerk.<br> Überlegt doch mal, was macht für euch agiles Arbeiten aus?<br> In welchem Umfeld seid ihr tätig?<br> Dass das Label verbrannt ist, ist vollkommen okay.<br> Aber das heißt noch lange nicht, dass das Gedankenmodell dahinter kaputt ist.<br> Und das ist eine wundervolle Einleitung im Prinzip schon für die nächste Folge.<br> Wie gesagt, ich habe ja mal so ein bisschen mein Denkmodell zusammengeschrieben, die Work-Feedback-Loop.<br> Und in den nächsten Folgen würde ich die jetzt auch ein bisschen klein hacken.<br> Und ganz konkret fangen wir eben mit den Grundlagen Work- und Feedback in der nächsten Folge an.<br> Was ich dir mitgeben kann, du kannst dir gerne mal ein bisschen dein Umfeld angucken.<br> Was machst du?<br> Wo ist deine Unternehmen unterwegs?<br> In was für einem Markt?<br> Und überleg doch mal, was wäre denn wirklich eine Alternative zum agilen Arbeiten?<br> Nicht zu Scrum oder so, sondern zu dem, was agiles Arbeiten ist.<br> Und ja, das soll es dann tatsächlich für heute auch schon gewesen sein.<br> Ich hoffe, du konntest ein bisschen was mitnehmen.<br> Wie immer freue ich mich auf dein Feedback.<br> Und ansonsten sage ich, ich habe noch eine ganz tolle Woche.<br> Und bis zum nächsten Mal.<br> Ciao, ciao.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK07: Agiles Manifest als ökonomische Strategie</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak07-agiles-manifest-oekonomische-strategie.html"/>
        <id>https://no-bullshit-agile.de/nbak07-agiles-manifest-oekonomische-strategie.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/204/nbak07-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-06-27T10:35:01+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/204/nbak07-cover.jpg" alt="Agiles Manifest - Ökonomische Strategie" />
                    Ein Gedankenexperiment: Was, wenn das Agile Manifest 2001 gar nicht primär für ein besseres Arbeitsumfeld geschrieben wurde, sondern als ökonomische Strategie, um dem Kunden schneller und sicherer marktfähige Software zu liefern? Diese Folge dreht die übliche Perspektive um und zeigt, warum genau das deine Retros, dein Refinement und deine Priorisierung&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/204/nbak07-cover.jpg" class="type:primaryImage" alt="Agiles Manifest - Ökonomische Strategie" /></p>
                <p>Ein Gedankenexperiment: Was, wenn das Agile Manifest 2001 gar nicht primär für ein besseres Arbeitsumfeld geschrieben wurde, sondern als ökonomische Strategie, um dem Kunden schneller und sicherer marktfähige Software zu liefern? Diese Folge dreht die übliche Perspektive um und zeigt, warum genau das deine Retros, dein Refinement und deine Priorisierung schärft.</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/94-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>Üblicherweise wird Agilität über gute Zusammenarbeit, Vertrauen und Selbstorganisation erklärt. Diese Folge stellt eine bewusst provokante Gegenthese: Das Agile Manifest ist im Kern eine ökonomische Strategie. Sein eigentliches Ziel ist schnellerer und sicherer Wert für den Kunden und das gute Arbeitsumfeld ist der notwendige Nebeneffekt, nicht der Selbstzweck.</p>
<h2>Zusammenfassung</h2>
<p>2001 war das Internet erwachsen geworden, die Märkte global und schnell, das Wasserfall-Modell dafür schlicht zu langsam. In Utah trafen sich 17 Vordenker aus Scrum, Extreme Programming und anderen Ansätzen und formulierten das Agile Manifest als Antwort auf dieses ökonomische Problem: Kunden befähigen, im Wettbewerb zu bestehen. Aus dieser Brille wird der Begriff "Wert" konkret. Wert ist Geld, das man dem Kunden verdient oder spart, kein abstraktes Gefühl. Das motivierte, gut geführte Team bleibt wichtig, ist aber Mittel zum Zweck. Im Alltag verändert das die Leitfrage hinter jeder Zeremonie: Bei Retro, Refinement und Story-Schnitt geht es nicht um Bequemlichkeit, sondern darum, mit dem geringsten Aufwand den maximalen ökonomischen Wert für den Kunden zu liefern. Oder wie Jeff Sutherland es sagt: "Figure out where the most value can be delivered for the least effort and do that one right away."</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich <a href="https://no-bullshit-agile.de/kontakt.html">hier</a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">hier</a></li>
<li>Die ausführliche Folge zum Thema (NBA29): <a href="https://no-bullshit-agile.de/nba29-gedankenexperiment-agiles-manifest.html">hier</a></li>
<li>Mein Buch "Agiles Arbeiten in der Praxis": <a href="https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html">hier</a></li>
<li>Diskutier mit auf <a href="https://mastodon.social/@nobsagile">Mastodon</a></li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei NoBullshitAgileKompakt, mein Name ist Thomas.<br> In der letzten Folge habe ich über KaroKult gesprochen, also wenn ihr Rituale nachahmt, ohne zu wissen warum ihr sie macht.<br> Wenn dich das interessiert, hört da gerne rein, den Link sowie alle weiteren Links findest du wie immer in den Shownotes.<br> Heute geht es mir um eine steile These, vielleicht ist die auch gar nicht so steil,<br> nämlich das Agile Manifest ist eigentlich als ökonomische Strategie zu verstehen.<br> Und das würde ich ganz gerne mal erklären, weil ich finde, dass das einen ganz guten Blickpunkt nochmal darauf wirft,<br> warum wir bestimmte Dinge im agilen Arbeiten tun.<br> Ja, wenn wir über agiles Arbeiten sprechen, kommt sehr oft auch Arbeitsumfeld dazu.<br> Agiles Arbeiten, die Selbstbestimmung, die Mitgestaltung, die Selbstorganisation in Teams<br> hängt natürlich auch ein bisschen in dem Thema New Work mit drin<br> und wird deswegen dann oft verknüpft mit, das ist ein Fundament von agilem Arbeiten.<br> Selbstorganisation in einem Rahmen ist bestimmt etwas, da habe ich auch schon öfter drüber gesprochen.<br> Und trotzdem glaube ich, wenn wir uns eines der Fundamente des agilen Arbeitens, also das Agile Manifest angucken,<br> dann ist das aus einer anderen Idee, einer anderen Umgebung und auch einem anderen Gedanken heraus entstanden.<br> Ich glaube nämlich, wenn ich mir auch angucke, wer da alles so in Utah war, 2001,<br> als das Agile Manifest geschrieben wurde, dass die Leute im Blick hatten,<br> okay, die Welt verändert sich, Softwareprojekte funktionieren nicht so, wie wir sie machen<br> und wir brauchen Leitlinien, ökonomisch gesteuerte Leitlinien.<br> Viele von denen waren Consultants, das darf man halt nicht vergessen.<br> Und ja, wenn wir uns jetzt mal die Zeit wirklich 2001 angucken,<br> ich meine, die agile Bewegung entsteht ja schon viel früher.<br> Also Scrum ist so 95, XP so 99.<br> Aber wenn wir uns jetzt einfach mal so als eine Marke 2001 angegucken,<br> dann sehen wir zum Beispiel, das Internet ist erwachsen geworden.<br> Der Markt ist viel größer geworden.<br> Es gibt einen enormen Druck für viele Unternehmen, möglichst schnell zu sein.<br> Und im Wasserfall durch die starre Planung und diese starre Trennung der Phasenanforderung,<br> Konzeptentwicklung, Test,<br> stellt man schnell fest, okay, das ist zu langsam.<br> Und ich glaube, ein Einfluss war eben bei diesem Treffen 2001,<br> wenn ich mir die Leute so angucke,<br> naja, wir brauchen ehrlich was, was wir für uns oder für unsere Kunden,<br> was uns ökonomisch schneller macht.<br> Wir wollen schneller Wert liefern.<br> Und da geht es um Euro oder Dollar halt.<br> Und man sieht es zum Beispiel daran,<br> dass das erste Prinzip, das 12 Prinzip im Agilen Manifest eben sagt,<br> wir erschließen bessere Wege, Software zu entwickeln.<br> Da geht es nicht darum, bessere Wege wie Menschen miteinander arbeiten,<br> sondern es geht darum, wir wollen Software,<br> wertvolle Software, schnell auf die Straße kriegen.<br> Natürlich ist es so, dass ein gutes Arbeitsumfeld da hilft.<br> Also, ich hatte es ja vorhin schon angesprochen,<br> die Selbstorganisation innerhalb eines Rahmens von einem Team soll dafür sorgen,<br> dass eben die Software schnell, sicher und sinnvoll geliefert wird.<br> Dass es gut für die Menschen ist, ist eine ganz tolle Sache,<br> aber stand hier nicht im Vordergrund.<br> Zumindest ist das jetzt erstmal hier, wie gesagt,<br> das Denkmodell oder die These in dieser Folge.<br> Und Wert, hier sieht man es, finde ich, auch wieder,<br> diese Wertediskussion, was heißt denn Wert liefern?<br> Hier geht es um Euros, hier geht es um Geld, es geht um Einnahmen.<br> Das Investment, von mir aus eines Sprints,<br> das muss sich refinanzieren, indem ich ein Inkrement liefere,<br> das einen wert schafft.<br> Muss ja nicht das einzige Inkrement sein.<br> Man kann das auch über eine längere Strecke sehen,<br> aber schlussendlich geht es natürlich darum,<br> das, was entwickelt wird, muss Geld einspielen.<br> Und was hilft uns diese Erkenntnis,<br> was hilft uns dieser Blickwinkel auf agilem Arbeiten?<br> Naja, hat viele Auswirkungen.<br> Zum Beispiel in der Retro.<br> Also es sollte nicht darum gehen,<br> wie kommen wir besser miteinander aus,<br> sondern wir wollen Blockaden finden in unserer Zusammenarbeit,<br> die die Lieferung eines schnellen Werts eben verhindert.<br> Oder im Refinement, wenn wir das nächste Inkrement planen,<br> dann geht es eben darum,<br> den geringsten Aufwand mit maximal ökonomischen Wert<br> zu erzeugen.<br> Und deswegen finde ich die Frage gut,<br> sich das in der Retro mal zu stellen,<br> okay, Action Points, die wir gefunden haben,<br> zahlen die wirklich auf solche Ziele ein?<br> Man kann das auch bei einer Story<br> oder einem ganzen Inkrement fragen,<br> wie viele Euro stecken da drin?<br> Und kann ich den Wert maximieren,<br> indem ich anders schneide oder anders priorisiere?<br> Sutherland sagt in seinem Buch zum Beispiel,<br> figure out where the most value can be delivered for the least effort<br> and do that one right away.<br> Wieder so ein Ding.<br> Ja, und tatsächlich soll es das auch schon gewesen sein.<br> Wie gesagt, mir geht es hier um den Shift,<br> dass ihr wirklich mal versucht,<br> wenn ihr es nicht eh schon tut,<br> all das, was ihr tut,<br> mit dieser Werte,<br> mit dieser ökonomischen Brille auch mal zu betrachten.<br> Wie ich schon gesagt habe,<br> das soll es für heute auch schon sein.<br> In der nächsten Folge werde ich darüber sprechen,<br> warum agiles Arbeiten nicht tot ist,<br> auch wenn man das gerne mal liest.<br> Bis dahin sage ich ganz vielen Dank fürs Zuhören<br> und noch eine ganz tolle Woche.<br> Ciao, ciao.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK06: Rituale ohne Seele - Cargo Cult Agility</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak06-cargo-cult-agility.html"/>
        <id>https://no-bullshit-agile.de/nbak06-cargo-cult-agility.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/203/nbak06-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-06-21T11:20:25+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/203/nbak06-cover.jpg" alt="Cargo Cult Agile" />
                    Dailys, Boards, Backlogs und trotzdem fühlt sich alles mühsam an? Dann steckt ihr vielleicht in einer Cargo Cult Agility: Die Form ist perfekt nachgeahmt, die Funktion fehlt. In dieser Folge geht es um die Symptome agiler Scheinwelten und um die eine Frage, die jedes Ritual bestehen muss. Der Begriff Cargo&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/203/nbak06-cover.jpg" class="type:primaryImage" alt="Cargo Cult Agile" /></p>
                <p>Dailys, Boards, Backlogs und trotzdem fühlt sich alles mühsam an? Dann steckt ihr vielleicht in einer Cargo Cult Agility: Die Form ist perfekt nachgeahmt, die Funktion fehlt. In dieser Folge geht es um die Symptome agiler Scheinwelten und um die eine Frage, die jedes Ritual bestehen muss.</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/93-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>Der Begriff Cargo Cult stammt von Inselbewohnern, die nach dem Krieg Landebahnen und Tower aus Holz nachbauten, in der Hoffnung, dass die Flugzeuge mit Fracht zurückkommen. Form perfekt, Funktion null. Genau das passiert mit Agilität, wenn Teams die Praktiken übernehmen, aber nicht das Mindset dahinter. Diese Folge zeigt, wie man das erkennt und was dagegen hilft.</p>
<h2>Zusammenfassung</h2>
<p>Cargo Cult Agility bedeutet: Es sieht agil aus, ist es aber nicht. Typische Symptome sind Rituale ohne Zweck, etwa das Daily, das nur ein Status-Reporting an den Chef ist, Wasserfall im Scrum-Gewand und das Festhalten an Kontrolle statt echter Selbstorganisation. Der gefährlichste Reflex ist, Output mit Outcome zu verwechseln: Viele geschlossene Tickets bedeuten nicht automatisch Wert. Die Ursache ist selten böser Wille, sondern Bequemlichkeit. Rituale lassen sich anordnen, ein verändertes Mindset nicht. Der Ausweg ist eine einzige ehrliche Frage zu jedem Ritual: Wozu machen wir das eigentlich? Kommt keine gute Antwort, ist es ein Ritual ohne Seele.</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich <a href="https://no-bullshit-agile.de/kontakt.html">hier</a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">hier</a></li>
<li>Mein Buch "Agiles Arbeiten in der Praxis": <a href="https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html">hier</a></li>
<li>Die ausführliche Folge zum Thema (NBA65): <a href="https://no-bullshit-agile.de/nba65-cargo-cult-agility.html">hier</a></li>
<li>Diskutier mit auf <a href="https://mastodon.social/@nobsagile">Mastodon</a></li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei NoBullshit Agile Compact. Mein Name ist Thomas.<br> In der letzten Folge habe ich über den agilen Eisberg gesprochen.<br> Wenn dich das interessiert, hör da gerne mal rein.<br> Den Link und alle weiteren Links findest du in den Shownotes.<br> Diese Folge stieß praktisch nahtlos an die letzte Folge an, denn es geht um Cargo-Kult.<br> Erkennt das vielleicht? Viele Teams kopieren eigentlich nur Rituale.<br> Das ist das Thema vom Eisberg tatsächlich auch gewesen.<br> Also Dailies, es gibt Boards, es gibt Backlogs und trotzdem verstehen sie das, warum dahinter nicht.<br> Meistens verhindert die Organisation oder das System, das sind gar nicht die Leute, die das nicht wollen,<br> sondern eher die Organisation, die dahinter steht.<br> Was heißt jetzt Cargo-Kult?<br> Es gibt tatsächlich, ich verlinke auch den Wikipedia-Artikel dazu,<br> Inselwohner, die nach dem Zweiten Weltkrieg angefangen haben,<br> Landebahn, Tower, Kopfhörer, also Artefakte, sag ich mal, nachzubauen,<br> weil sie gedacht haben, dann kommen die Flugzeuge mit der Fracht zurück.<br> Also sie ahmen die Form perfekt nach, sie verstehen aber nicht den Hintergrund und deswegen gibt es diesen Begriff von Cargo-Kult Agile.<br> Ja und wenn sowas passiert, dann ist es natürlich schwierig, weil dann eben das Versprechen von agilen Arbeit nicht eingelöst wird.<br> Wenn ich nur Rituale durchführe, ohne zu verstehen, warum tue ich sie und was soll das Outcome sein,<br> kann das arme agile Arbeiten gar nichts dafür, dass alle sagen, das funktioniert nicht,<br> sondern es liegt eben daran, dass keiner die Frage stellt, warum tun wir das?<br> Und das wäre tatsächlich auch meine größte Empfehlung.<br> Überlegt euch gerne mal, alles was ihr so macht rund um agiles Arbeiten, verändert das eure Arbeit?<br> Hat das wirklich einen Einfluss da drauf?<br> Wenn die Antwort ziemlich oft Nein ist, habt ihr eigentlich schon mal einen ganz schönen Ansatzpunkt,<br> um zu gucken, okay, warum machen wir dies, warum machen wir ein Daily,<br> wofür ist das gedacht, was soll dabei rauskommen und was kommt bei uns raus?<br> Ja, es gibt so ein paar Symptome, die ich mir aufgeschrieben habe,<br> woran man eigentlich ganz gut erkennt, ob ihr eher in diesem Bereich Cargo-Kult seid.<br> Also, schönstes Beispiel, fällt jedem wahrscheinlich sofort ein,<br> das Daily ist eher so ein Status-Report.<br> Jeder erzählt was und es geht eigentlich nicht darum,<br> alle anderen zu informieren, um eine Story fertig zu bekommen zum Beispiel,<br> sondern es geht nur darum, ich muss jetzt was sagen,<br> ich sage solche Dinge, dass alle anderen denken,<br> wow, der war super produktiv oder sie.<br> Manchmal gibt es ein Reporting an den Chef oder so,<br> ja, dann ist das Daily halt nicht in dem Sinne durchgeführt,<br> wie es eigentlich sein soll.<br> Das Daily soll ja dafür da sein, dass ihr euch austauscht,<br> damit die wichtigste Story fertig wird für die Scrum-Leute,<br> damit das Sprintziel erreicht wird.<br> Ich werde da ein bisschen tiefer übrigens in der Folge 30 drauf eingehen.<br> Oft liest man darüber, dass Scrum eher so ein Wasserfall wird.<br> Das wird durchgeplant, vorgeplant, von vorne bis hinten<br> und es gibt gar keine echte Anpassung aufgrund eines Feedbacks.<br> Also ihr released etwas und das Feedback dieser Iteration hat überhaupt keinen Einfluss<br> oder sehr wenig Einfluss auf das, was ihr im nächsten und im übernächsten Sprint macht.<br> Das ist auch so ein schönes Zeichen, so ein schönes Symptom,<br> dass ihr vielleicht eher so bei Cargo Kult seid.<br> Ja, und noch ein Symptom, es gibt viel mehr,<br> ich will gar nicht alle aufzählen, die mir so eingefallen sind.<br> Wenn es bei euch mehr um Output statt um Outcome geht,<br> also ihr misst super viel sowas wie, wie viele Tickets haben wir geschafft,<br> wie viele Story Points haben wir geschafft<br> und es geht gar nicht darum, wie viel Wert haben wir wirklich erzeugt.<br> Das Increment, was wir released haben, wie wertvoll war das,<br> wie gut hat das funktioniert,<br> was habt ihr gedacht, wie es funktioniert<br> und was ist jetzt das Feedback?<br> Also Output ist wichtig, nicht Outcome.<br> Tja, warum passiert das?<br> Naja, es ist ziemlich einfach, so eine Rituale nachzuahmen.<br> Das braucht auch Effort, natürlich,<br> aber wenn man nicht lange überlegen muss,<br> warum tue ich das und was ist das erwartete Outcome von zum Beispiel einem Ritual,<br> ja, dann ist es halt deutlich einfacher,<br> einfach das Ritual durchzuführen und zu sagen,<br> so, alles klar, wir haben eine Retro, das muss man machen,<br> super, wir sind agil.<br> Der Ausweg ist eigentlich auch ziemlich klar,<br> das hatte ich ganz am Anfang schon gesagt.<br> Nutzt gerne diese Frage, wozu machen wir das eigentlich?<br> Was ist unsere Erwartung?<br> Warum haben wir dieses Ritual, diese Methode, dieses Board,<br> diese Definition of Done?<br> Wenn ihr diese Frage stellt, wozu,<br> dann kommt ihr eigentlich schon gut ins Gespräch<br> und kommt sicherlich einen guten Schritt weiter,<br> in einer Kultur, wo solche Fragen auch, ja, gewünscht sind, ne?<br> Ja, also agil aussehen und agil arbeiten,<br> das können einfach zwei verschiedene Dinge sein, ne?<br> Und der Unterschied, der liegt in dem Zweck und nicht in der Zeremonie.<br> Und deswegen, ja, diese Frage halt.<br> Und ja, das soll es eigentlich auch schon gewesen sein.<br> Wir verlassen dann jetzt tatsächlich so ein bisschen die Theorie in NBA Compact<br> und wir kommen in der nächsten Folge dann dazu,<br> dass wir uns so einen ökonomischen Blick mal nehmen.<br> Ich werde darüber reden,<br> warum das Agile Manifest im Kern eigentlich eine ökonomische Strategie ist.<br> Ja, und das sollte es tatsächlich auch schon gewesen sein.<br> Ich hoffe, dir hat das gefallen.<br> Ich freue mich wie immer über Feedback,<br> auch gerne kritisches Feedback.<br> Und ich wünsche dir eine ganz tolle Woche<br> und wir hören uns beim nächsten Mal.<br> Ciao, ciao.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK05: Der agile Eisberg</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak05-der-agile-eisberg.html"/>
        <id>https://no-bullshit-agile.de/nbak05-der-agile-eisberg.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/202/nbak05-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-06-12T13:10:00+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/202/nbak05-cover.jpg" alt="Agiler Eisberg" />
                    Scrum, Daily, Retro: Das ist die Spitze des agilen Eisbergs. Was darunter liegt, entscheidet darüber, ob agiles Arbeiten wirklich funktioniert oder nur wie agiles Arbeiten aussieht. Ich erkläre die vier Säulen, die jedes agile Setup braucht, und die meisten ignorieren. Wer Scrum einführt und glaubt, damit agil zu sein, betreibt&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/202/nbak05-cover.jpg" class="type:primaryImage" alt="Agiler Eisberg" /></p>
                <p>Scrum, Daily, Retro: Das ist die Spitze des agilen Eisbergs. Was darunter liegt, entscheidet darüber, ob agiles Arbeiten wirklich funktioniert oder nur wie agiles Arbeiten aussieht. Ich erkläre die vier Säulen, die jedes agile Setup braucht, und die meisten ignorieren.</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/92-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>Wer Scrum einführt und glaubt, damit agil zu sein, betreibt mechanische Agilität – Cargo-Kult. Man imitiert die Rituale, weil sie bei anderen funktionieren, ohne die dahinterliegenden Prinzipien zu verstehen. Der eigentliche Hebel liegt unter der Wasseroberfläche: Mindset, Kultur, technische Exzellenz und echte Kollaboration.</p>
<h2>Zusammenfassung</h2>
<p>Die Spitze des Eisbergs – Scrum, Daily, Retro, Product Owner – ist sichtbar und einfach einzuführen. Deshalb setzen Organisationen sie mit "Agilität" gleich. Das ist ein Fehler. Echtes agiles Arbeiten braucht vier Fundamente:</p>
<ul>
<li>(1) Denkweisen und Prinzipien: Agiles Manifest, Servant Leadership, Vertrauen</li>
<li>(2) Kultur und Organisation: Fehlerkultur, lernende Organisation, offene Kommunikation</li>
<li>(3) Technische Exzellenz: inkrementelle Entwicklung, TDD, CI/CD</li>
<li>(4) Echte Kollaboration: Pair Programming, permanente Kundenbeteiligung.</li>
</ul>
<p>Wer nur die Spitze optimiert, bekommt Rituale ohne Seele – und wundert sich, warum "Scrum bei uns nicht funktioniert".</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich <a href="https://no-bullshit-agile.de/kontakt.html">hier</a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">hier</a></li>
<li>Grafik "Agiler Eisberg" als PDF: <a href="https://no-bullshit-agile.de/der-agile-eisberg.html">Download</a></li>
<li>Ausführliche Podcast-Folge zum Thema: <a href="https://no-bullshit-agile.de/nba49-der-agile-eisberg.html">NBA49 – Der agile Eisberg</a></li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei NoBudgetAgileKompakt. Mein Name ist Thomas.<br> In der letzten Folge habe ich darüber gesprochen, warum Mindset vor Methode geht.<br> Wenn dich das interessiert, hör da gerne rein, den Link und alle weiteren Links findest du in den Shownotes.<br> Heute will ich ein Bild beschreiben, den agilen Eisberg und ein bisschen darüber sprechen,<br> was so an der Oberfläche ist, was jeder sieht, was jeder sich unter agilem Arbeiten vorstellt<br> und was eigentlich darunter ist, viel mehr ausmacht und trotzdem verdeckt ist und viele einfach auch nicht sehen.<br> Und ja, meiner Meinung nach entstehen daraus halt viele Probleme.<br> Und ich würde sagen, genau damit steigen wir auch mal ein.<br> Was wir alle sehen, ist sowas wie ein Scrum, ein Daily, eine Retro, ein Product Owner, ein Scrum Master.<br> Es gibt Boards, es gibt Backlogs und Story Points.<br> Und das ist halt schön sichtbar und einfach, wenn wir auf den Scrum Guide gucken,<br> sage ich ja auch gerne immer wieder, das ist ein schönes Playbook.<br> Da sieht man eben genau, was man tun muss, führ diese Rollen ein, mach diese Rituale und dann bist du agil.<br> Und tatsächlich ist genau das mir passiert, schon ein bisschen länger her,<br> aber ich war mal der festen Überzeugung, als wir Scrum eingeführt haben,<br> okay, wir müssen uns da voll dran halten und dann sind wir agil.<br> Da ist es natürlich mit meinem heutigen Wissen klar, dass das nicht funktionieren kann.<br> Es zeigt aber, wie leicht man in diese Falle tappt und ich kann das auch nachvollziehen,<br> dass man in diese Falle tappt.<br> Wie gesagt, das ist sichtbar, das ist einfach zu greifen, das ist einfach einzuführen<br> und das lässt sich auch ziemlich schnell mit agilem Arbeiten gleichsetzen.<br> Und das Resultat ist dann mechanisches agiles Arbeiten oder mechanische Agilität.<br> Wir haben Rituale ohne ein Verständnis, wir kommen ganz schnell in so ein Cargo-Kult.<br> Apropos Cargo-Kult, was ist das?<br> Darum wird es in der nächsten Folge gehen.<br> Ja, wir imitieren halt einfach Praktiken, weil sie bei anderen ja zu funktionieren scheinen.<br> Also wir wissen halt einfach oder wir denken, wir wissen, okay, wir führen das so ein,<br> das funktioniert bei anderen, also sind wir dann agil.<br> Und dann haben wir Symptome, die man ziemlich schnell sieht, wenn man mal ein paar Blog-Beiträge<br> oder auf Mastodon was liest, stellt man das auch immer wieder fest.<br> Viele Probleme von denen, wo Leute drüber meckern, kann man genau an diesen Symptomen festmachen.<br> Das Daily ist auf einmal ein Status-Report, wir haben einen klassischen Wasserfall, es wird durchgeplant.<br> Es gibt diese schöne Geschichte, die man mal jemand erzählt hat, wo aufgrund von der Velocity<br> im Prinzip in der Excel-Tabelle ein ganzes Jahr geplant wurde.<br> Okay, dann schafft ihr ja, über das Jahr gesehen, in all euren Sprints folgendes.<br> Das ist Wasserfall.<br> Teams werden aufgrund von Velocity verglichen und nicht nach Outcome.<br> Es gibt doch so blöde Dinge, wie dass Abteilungen auf einmal Squats heißen.<br> Also ich meine, ihr kennt das alles.<br> Und das liegt daran, an diesem Eisbergbild, dass wir oben Dinge haben über der Wasseroberfläche,<br> die sehr klar sind, die jeder benennen kann.<br> Aber viel wichtiger ist das, was unter der Oberfläche ist.<br> Eisberg bedeutet ja immer, okay, der untere Teil, der Teil, der unter der Wasseroberfläche ist,<br> ist deutlich größer, aber versteckt.<br> Was ist jetzt unter dieser Oberfläche?<br> Das habe ich in vier Punkten zusammengefasst.<br> Also da gibt es viele, viele Themen rund um Denkweisen und Prinzipien.<br> Also das agile Manifest, Kennen und Leben, Servant Leadership, Vertrauen geben, Transparenz, Empowerment.<br> Also Selbstorganisation braucht diesen Platz, braucht das, damit es wachsen kann.<br> Der zweite Punkt ist Kultur und Organisation.<br> Fehlerkultur ist ein Riesending.<br> Viele verstehen Scheitern nicht als Lernchance.<br> Wir brauchen sowas wie eine lernende Organisation.<br> Wir brauchen offene und ehrliche Kommunikation.<br> Wir wollen vielleicht keine zu starren Hierarchien.<br> Und das ist alles Kultur und Organisation.<br> Der dritte Punkt ist technische Exzellenz.<br> Wir wollen inkrementell entwickeln.<br> Da brauchen wir eine riesige technische Basis für.<br> Ich sage hier TDD als ein Beispiel.<br> Wir brauchen eine gute CICD-Pipeline.<br> Wir müssen Verständnis davon haben.<br> Wir müssen im Prinzip jederzeit Code in Produktion bringen können, ohne Angst davor zu haben.<br> Nur dann können wir diesen Feedback-Zyklus starten.<br> Und die vierte Säule, die ich habe, ist echte Kollaboration.<br> Per- und Mob-Programming fällt einem hier ein.<br> Permanente Kundenbeteiligung fällt uns ein.<br> Und das halt nicht nur bei Anforderungserhebung, sondern während des gesamten Prozesses,<br> während des gesamten Projekts, sage ich jetzt einfach mal.<br> Es gibt noch ein paar mehr Punkte in diesem Bild dieses Eisbergs, das ich mal gemalt habe.<br> Das siehst du hier übrigens auch als Kapitelcover, falls du da beim Autofahren oder beim Rasenmähen reingucken willst<br> und dein Player das unterstützt.<br> Wir haben also den offensichtlichen Teil, der jeder von uns benennen kann.<br> Aber es gibt noch viel, viel mehr der Teil, der unter der Wasseroberfläche versteckt ist.<br> Jetzt kann man sich noch die Frage stellen, warum fokussieren wir uns so stark auf diese Spitze,<br> auf das, was man oben sieht.<br> Naja, wir sind halt Menschen.<br> Und es ist halt einfach, einen Scrum Master einzuführen.<br> Es ist viel schwieriger, eine Fehlerkultur aufzubauen.<br> Der untere Teil ist deutlich schwieriger und langwieriger als dieser obere.<br> Er ist aber nicht optional.<br> Er ist das Fundament.<br> Und darauf kommt es an.<br> Und immer wenn ihr mal was lest oder bei euch selber was feststellt und sagt,<br> irgendwie funktioniert das hier alles nicht, kann ich euch nur den Tipp geben,<br> guckt mal auf diese vier Säulen, die ich gerade benannt habe und auf diesen unteren Teil.<br> Ja, und das soll es eigentlich auch schon gewesen sein.<br> Ich finde, der agile Eisberg ist ein schönes Bild, um auch hier wieder im Team mit eurer Organisation<br> darüber zu sprechen, warum funktioniert das bei uns nicht.<br> Das heißt nicht, agiles Arbeiten funktioniert nicht.<br> In der Regel liegt es halt an anderen Dingen.<br> Schaut euch das gerne an.<br> Wie ich schon gesagt habe, in der nächsten Folge geht es dann um Cargo-Kult.<br> Ist also nahtloser Übergang, sage ich mal.<br> Und wie ich sonst auch immer sage, ich freue mich super auf jegliches Feedback.<br> Ich freue mich sehr auf Kritik.<br> Wie ihr mich erreicht, findet ihr in den Shownotes.<br> Haltet euch nicht zurück.<br> Ihr findet mich auch auf Mastodon.<br> Das ist wahrscheinlich der schnellste und direkteste Weg.<br> Ansonsten bleibt mir nichts anderes übrig, als zu sagen.<br> Habt noch eine ganz tolle Woche.<br> Und bis zum nächsten Mal.<br> Ciao, ciao.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK04: Mindset vor Methode</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak04-mindset-vor-methode.html"/>
        <id>https://no-bullshit-agile.de/nbak04-mindset-vor-methode.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/201/nbak04-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-06-05T10:13:36+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/201/nbak04-cover.jpg" alt="Mindset  vor Methode" />
                    Viele Teams machen Scrum, nutzen Jira, halten ihr Daily – und sind trotzdem frustriert. Der Grund: Sie haben bei der Methode angefangen statt bei der Haltung. In dieser Folge erkläre ich, warum Agilität zuerst ein Mindset ist, wofür die Stacey Matrix gut ist und welche zehn Bausteine wirklich zählen. „Wir&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/201/nbak04-cover.jpg" class="type:primaryImage" alt="Mindset  vor Methode" /></p>
                <p>Viele Teams machen Scrum, nutzen Jira, halten ihr Daily – und sind trotzdem frustriert. Der Grund: Sie haben bei der Methode angefangen statt bei der Haltung. In dieser Folge erkläre ich, warum Agilität zuerst ein Mindset ist, wofür die Stacey Matrix gut ist und welche zehn Bausteine wirklich zählen.</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/91-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>„Wir machen doch Scrum" – und trotzdem funktioniert es nicht. Dieses Gefühl kennen viele. In dieser Folge gehe ich der Ursache auf den Grund: dem Missverständnis, Agilität sei eine Methode. Ich zeige, warum die erste Frage immer lauten muss „Was für eine Arbeit machen wir eigentlich?", wie die Stacey Matrix bei der Antwort hilft und warum das Mindset immer vor dem Framework kommt.</p>
<h2>Zusammenfassung</h2>
<p>Agilität wird oft mit klassischem Projektmanagement verwechselt – pünktlich, im Budget, unter Kontrolle. Genau das kann und will sie nicht leisten. Sie ist die Antwort auf Neuland: Projekte, bei denen weder Anforderungen noch Lösungsweg am Anfang klar sind. Die Stacey Matrix macht sichtbar, wann agiles Arbeiten sinnvoll ist und wann ein klassischer Plan genügt. Der entscheidende Punkt: Scrum, Kanban und Jira sind nur Hilfsmittel, die auf einem Fundament aufsetzen – dem Agilen Manifest und seinen Prinzipien. Wer dieses Fundament überspringt, spult Zeremonien ab, ohne agil zu sein. Die zehn „Agile Primitives" von Stefan Wolpers sind der Baukasten, auf den es wirklich ankommt – unabhängig von jeder Methode.</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich <a href="https://no-bullshit-agile.de/kontakt.html">hier</a><a href="https://no-bullshit-agile.de/kontakt.html"></a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">hier</a></li>
<li>Die <a href="https://www.bva.bund.de/DE/Services/Behoerden/Beratung/BZB/Themenwelten/Strategie/Projektmanagement/Wissenspool/_documents/Standardartikel/stda-stacey-matrix.html">Stacey Matrix</a>: Wann agil, wann klassisch? </li>
<li>Buch: „Agiles Arbeiten in der Praxis" – <a href="https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html">no-bullshit-agile.de/buch</a></li>
<li>Diskutier mit auf <a href="https://mastodon.social/@nobsagile">Mastodon</a></li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei NoBildshit Agile Kompakt, mein Name ist Thomas.<br> In der letzten Folge habe ich über die 12 agilen Prinzipien gesprochen, die habe ich<br> tatsächlich umgewandelt in Fragen, weil ich das Gefühl habe, mit solchen Fragen kann<br> man im Team, in einem Meeting zum Beispiel mehr anfangen.<br> Heute geht es tatsächlich, wie ihr im Titel wahrscheinlich gesehen habt, um Mindset-Vormethode<br> und ich höre euch schon stöhnen, agiles Arbeiten ist ein Mindset.<br> Ich weiß, das ist ziemlich platt getreten, aber ja, gibt dem Ganzen eine Chance, ich<br> habe da so einen gewissen Spin drauf.<br> Ich bin der Meinung, man muss zuerst im Kopf verstehen, warum man agil arbeiten will und<br> was das bedeutet und erst dann wendet man einen Werkzeugkasten an, also Werkzeugkasten sowas<br> wie Scrum oder Werkzeugkasten sowas wie Jira oder einem Daily.<br> Es ist wichtig, deswegen habe ich damit angefangen zu verstehen, was bedeutet agiles Arbeiten<br> im Fundament, warum arbeitet man überhaupt agil.<br> Man muss das agile Manifest und die agilen Prinzipien verstehen, warum die entstanden sind, was der<br> Hintergrund dazu ist und dann kann man sich mit Methoden und Implementierungsarten beschäftigen.<br> Ihr baut sonst zuerst das Dach von einem Haus, bevor ihr das Fundament habt und dann wundert<br> ihr euch, ja, warum bleibt das Dach nicht in der Luft schweben.<br> Also, was für eine Arbeit machen wir eigentlich, das ist eine entscheidende Frage.<br> Und ich höre halt immer wieder und lese auch immer wieder, wir machen doch Scrum, warum funktioniert<br> es bei uns nicht?<br> Und ja, oft genug liegt eben das Problem genau an dieser Stelle.<br> Da ist was implementiert worden, eine Methode, aber das Verständnis, warum wollen wir diese<br> Methode anwenden, das ist halt nicht da.<br> Aber das erste Missverständnis ist so ein bisschen, dass es oft eine falsche Erwartungshaltung<br> gibt.<br> Also, macht das einfach mal zum Spaß, ich habe das auch mal gemacht, googelt einfach mal<br> why agile oder warum agil.<br> Da kommen sehr interessante Sachen bei raus, also sowas wie, hilft Projekte pünktlich im<br> Budget abzuschließen oder da habe ich eine bessere Projektkontrolle.<br> Und da sieht man halt schon, wo der Denkfehler ist.<br> Agiles Arbeiten hat nichts mit Projektmanagement oder Projektcontrolling zu tun.<br> Darum geht es agil im Arbeiten nicht.<br> Ich finde, eine fundamentale Frage, die man sich da stellen kann, ist, was für eine Arbeit<br> machst du?<br> Also, dein Team, dein Unternehmen und ich habe da zum Beispiel, ich weiß, das stimmt nicht<br> so ganz, aber ich finde es halt einfach passend, wenn man einen Golf baut, einen VW Golf, das<br> Auto, dann ist es halt so, dass eigentlich ziemlich klar ist, wie dieser Golf gebaut werden<br> muss.<br> Das hat man einmal erforscht und ab dann ist es nur noch Reproduktion.<br> Also, wir bauen jetzt von dieser Variante des Golfs 200.000 Stück.<br> Und wenn wir in Software arbeiten, ist es sehr, sehr oft so, dass wir Neuland betreten.<br> Die Anforderungen sind vage.<br> Manchmal weiß der Kunde auch nicht so genau, was hinten rauskommt.<br> Das ist auch ganz normal.<br> Das ist überhaupt kein Vorwurf.<br> Und wir erkennen eben an, dass wir im Projekt schlauer werden, dass wir am Anfang von einem<br> Projekt nicht benennen können, wo wir landen und wann wir sagen, so ist es gut oder gut<br> genug.<br> Und das ist halt der große Unterschied zu sowas wie einem Golf bauen.<br> Da weiß man eben, wenn der gebaut wurde, dann hat der folgende Eigenschaften.<br> Und da sind sich alle auch einig drüber.<br> Und um das ein bisschen auf eine Landkarte zu malen, gibt es eigentlich ein ganz schönes<br> Bild, auch schon ziemlich alt, die sogenannte Stacy-Matrix.<br> Die verlinke ich auch.<br> Und die hat im Prinzip zwei Achsen.<br> Auf der einen Achse steht das was, also sind die Anforderungen klar.<br> Und auf der anderen Achse steht das wie, ist der Lösungsweg klar.<br> Und daraus entstehen so vier Bereiche.<br> Es gibt so einen Bereich einfach, also Anforderungen sind sehr klar und Lösungsweg ist sehr klar.<br> Da kann man einen Wasserfall machen.<br> Das ist überhaupt kein Problem.<br> Am Wasserfall selber ist ja auch nichts Schlimmes.<br> Dann gibt es einen Bereich, der ist kompliziert.<br> Da braucht es dann vielleicht Expertenwissen.<br> Aber ich kann trotzdem noch eine klassische Methode anwenden.<br> Also es ist eigentlich klar, was rauskommen soll.<br> Dann kommen wir in einen ganz interessanten Bereich, nämlich in den Bereich Komplex.<br> Da sind wir oft in der Softwareentwicklung.<br> Das ist das Neuland.<br> Die Anforderungen sind nicht ganz klar, also das was.<br> Und der Lösungsweg ist nicht ganz klar.<br> Wir haben das nicht hunderttausend Mal gemacht.<br> Das ist also eine komplexe Umgebung.<br> Und da ist Agilität zu Hause.<br> Und dann gibt es ganz rechts oben noch so einen Bereich Chaos.<br> Hier ist halt im Prinzip kein Plan möglich.<br> Da muss man erstmal stabilisieren, um zumindest in diesem Bereich komplex zu kommen.<br> Dafür gibt es dann zum Beispiel ja diese weltberühmten Spike-Stories.<br> So eine Erforschungs-Story.<br> Also wichtig ist zur Ergänzung vielleicht an dieser Stelle,<br> wenn man dieses Bild von der Stacey Matrix mal verstanden hat,<br> noch ein bisschen Begrifflichkeit.<br> Agil heißt halt nicht schnell.<br> Agil heißt beweglich sein.<br> Und darum geht es.<br> Es geht, einen Weg zu finden im unbekannten Umfeld,<br> ein schnelles, ein gutes, ein bewegliches Vorgehen zu finden.<br> Und da drin zu lernen.<br> Ja, und so komme ich eben darauf, dass Agilität ein Mindset braucht.<br> Man muss das Verständnis dazu haben.<br> Das meine ich mit Mindset.<br> Und dann wird dieses Bild, das Agile Manifest, zwölf Prinzipien, total klar.<br> Und dann ist es auch wirklich kein Problem, eine Methode jetzt anzuwenden,<br> wie zum Beispiel Scrum und zu sagen, okay, das ist ja gut.<br> Und natürlich ist es so, viele Menschen wollen gerne klare Regeln.<br> Deswegen ist Scrum da halt ziemlich gut, um einzusteigen.<br> Und da habe ich auch überhaupt kein Problem mit.<br> Ich finde es halt gut, das habe ich in anderen Folgen ja auch schon mal gesagt.<br> Vielleicht muss man sich an manchen Stellen dann ein bisschen weiterentwickeln.<br> Ja.<br> Wichtig finde ich als Zusammenfassung, macht euch da wirklich mal Gedanken,<br> was produziert ihr, in welchem Umfeld arbeitet ihr?<br> Ist das alles eher unbekannt?<br> Ist das vielleicht alles eher komplex?<br> Oder ist es doch eher einfach und repetitiv?<br> Und schaut euch gerne das Agile Manifest und zwölf Prinzipien nochmal an<br> und überlegt euch mal, wie passt das denn zu dem, wie wir jetzt agil arbeiten?<br> Also wenn ihr eine Methode anwendet, wie ihr die anwendet?<br> Ich finde, daran kann man viel sehen.<br> Es ist halt eine Haltung und ihr braucht erst eine Haltung, ein Verständnis.<br> Und dann kommt das Werkzeug, also die Methode.<br> Ich werde dazu in der nächsten Folge, der Agile Eisberg, nochmal ein Bild malen,<br> dass das Ganze noch von der anderen Seite beleuchtet.<br> Nämlich, wenn wir über agiles Arbeiten sprechen,<br> nennen viele Leute sehr schnell sowas wie Scrum, Daily, Retro.<br> Das ist Leuten immer klar, aber es steckt halt viel, viel mehr dahinter.<br> Und das ist halt deswegen dieses Eisbergbild unter der Wasseroberfläche verborgen.<br> Wie gesagt, da würde ich dann in der nächsten Folge nochmal drüber sprechen.<br> Ansonsten sind wir für heute durch.<br> Ich hoffe, dir hat das gefallen.<br> Ich freue mich über Feedback.<br> Wie du mich erreichst, findest du in den Shownotes.<br> Übrigens auch Verlinkungen zu weiterführenden Themen findest du in den Shownotes.<br> Und ansonsten sage ich, ich habe noch eine ganz tolle Woche.<br> Und bis zum nächsten Mal bei NoBudget Agile Kompakt.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK03: Die 12 agilen Prinzipien als Checkliste</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak03-12-agile-prinzipien-checkliste.html"/>
        <id>https://no-bullshit-agile.de/nbak03-12-agile-prinzipien-checkliste.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/200/nbak03-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-05-29T17:34:51+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/200/nbak03-cover.jpg" alt="12 Prinzipien als Checkliste" />
                    Die 12 agilen Prinzipien kennen die meisten nur vom Hörensagen. In dieser Folge verwandle ich jedes Prinzip in eine konkrete Frage, die du dir und deinem Team regelmäßig stellen kannst. Keine Theorie, sondern eine Checkliste für den Alltag. Die 17 Autoren des Agilen Manifests haben ihre vier Werte mit zwölf&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/200/nbak03-cover.jpg" class="type:primaryImage" alt="12 Prinzipien als Checkliste" /></p>
                <p>Die 12 agilen Prinzipien kennen die meisten nur vom Hörensagen. In dieser Folge verwandle ich jedes Prinzip in eine konkrete Frage, die du dir und deinem Team regelmäßig stellen kannst. Keine Theorie, sondern eine Checkliste für den Alltag.</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/90-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>Die 17 Autoren des Agilen Manifests haben ihre vier Werte mit zwölf Prinzipien konkretisiert. Doch in der Praxis kennen die meisten diese Prinzipien kaum. In dieser Folge mache ich sie greifbar: Jedes Prinzip wird zu einer einfachen Frage, die du dir regelmäßig stellen kannst. Von „Erzeugen wir echten Nutzen?" bis „Hinterfragen wir regelmäßig unser Vorgehen?" – diese Checkliste deckt Lücken auf, die dir sonst nicht auffallen.</p>
<h2>Zusammenfassung</h2>
<p>Die 12 agilen Prinzipien werden oft einmal gelesen und dann vergessen. Das Problem: Als reine Aussagen laden sie zum Nicken ein, nicht zum Handeln. In dieser Folge verwandle ich jedes Prinzip in eine konkrete Frage – von Wertlieferung über nachhaltige Entwicklung bis zur Reflexion. Eine Frage zwingt zur ehrlichen Antwort. Besonders aufschlussreich: Misst du Fortschritt an funktionierender Software oder an Velocity? Assoziiert dein Team „agil" mit Überstunden? Die Prinzipien sind der Kompass für Entscheidungen – aber nur wenn du sie als Werkzeug nutzt, nicht als Wandschmuck.</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich <a href="https://no-bullshit-agile.de/kontakt.html">hier</a><a href="https://no-bullshit-agile.de/kontakt.html"></a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">hier</a></li>
<li><a href="https://no-bullshit-agile.de/nbak02-agiles-manifest-immer-noch-die-basis.html">NBAK02: Das Agile Manifest - Immer noch die Basis</a></li>
<li>Die 12 agilen Prinzipien als Fragen für den Alltag</li>
<li>Agile Prinzipien: <a href="https://agilemanifesto.org/iso/de/principles.html">agilemanifesto.org</a></li>
<li>Buch: „Agiles Arbeiten in der Praxis" – <a href="https://no-bullshit-agile.de/buch.html">no-bullshit-agile.de/buch</a></li>
<li>Diskutier mit auf <a href="https://mastodon.social/@nobsagile">Mastodon</a></li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei NoBudget Agile Kompakt. Mein Name ist Thomas.<br> In der letzten Folge habe ich über das Agile Manifest gesprochen und da gehört praktisch zwangsläufig ja dazu, dass es die zwölf agilen Prinzipien gibt.<br> Und ich habe mir überlegt, in dieser Folge will ich die mal durchgehen, aber ich will es ein bisschen anders machen.<br> Die zwölf agilen Prinzipien sind ja im Prinzip Aussagen. Ich habe jetzt einfach die mal in Fragen umformuliert.<br> Ich habe das Gefühl, wenn man so eine Frage stellt, kann man da ein bisschen mehr mitmachen.<br> Die Frage versucht ja immer im Kopf ein bisschen was anzuregen.<br> Und deswegen würde ich sagen, wir gehen da einfach mal rein. Ich würde jetzt einfach mal Stück für Stück durchgehen.<br> Gut, wir fangen mal an. Im ersten Prinzip geht es um Wert.<br> Und die Frage, die ich formuliert habe, ist, erzeugen wir mit der heutigen Arbeit echten Nutzen für den Kunden?<br> Das heißt also, ihr könnt euch gerne fragen, das was wir gerade tun, bringt das einen echten Nutzen?<br> Das zweite Prinzip ist Anpassungsfähigkeit. Und die Frage lautet, nutzen wir neue Erkenntnisse, um unsere Planung zum Vorteil des Kunden zu verbessern?<br> Wir wollen eben auf das, was der Kunde oder die Marktsituation braucht, reagieren.<br> Im dritten Prinzip geht es um die Frequenz. Und meine Frage dazu ist, können wir diesen Nutzen zeitnah ausliefern, statt auf ein großes Release zu warten?<br> Mir geht es darum, dass wir, wenn wir etwas haben, das möglichst schnell auch auf die Straße kriegen.<br> Warum wollen wir das?<br> Weil wir auch möglichst früh Feedback bekommen wollen, um zu gucken, liegen wir richtig?<br> Das vierte Prinzip ist eigentlich Zusammenarbeit. Und die Frage lautet, arbeiten wir mit der Fachseite täglich gemeinsam an der besten Lösung?<br> Fachseite, ja, Stakeholder könnte man sagen. Wir wollen zusammenarbeiten. Wir wollen nicht uns verstecken und sagen, okay, das steht ja alles definiert in Storys, was zu tun ist.<br> Das fünfte Prinzip hat die Überschrift Vertrauen. Und meine Frage dazu ist, schaffen wir ein Umfeld, in dem wir motiviert und eigenverantwortlich arbeiten können?<br> Also ist die Umgebung, in der wir leben, in der wir arbeiten, so, dass wir da wirklich auch unsere volle Leistung abrufen können?<br> Der sechste Punkt, habe ich gesagt, der ist Kommunikation. Und die Frage dazu lautet, nutzen wir das direkte Gespräch, um Informationen am schnellsten auszutauschen?<br> Geht es also darum, dass man versucht, nicht über Brieftaube, Slack, Teams, nächstes Meeting in der Videokonferenz, Drawfix, Themen zu spät zu besprechen,<br> sondern so gut es geht, eben die direkte Kommunikation zu suchen?<br> Der siebte Punkt lautet Fortschritt. Und die Frage ist, messen wir Erfolg an funktionierender Software statt an Plänen oder an Statusberichten?<br> Es geht also nicht darum, dass alle Projektampeln grün sind, sondern wir wollen gucken, das, was wir da entwickelt haben, mit unseren Annahmen, die wir getroffen haben,<br> wie es das Produkt besser macht, trifft es wirklich zu.<br> Der achte Punkt ist Nachhaltigkeit. Und meine Frage ist, arbeiten wir in einem Tempo, das wir dauerhaft, ohne Überlastung, beibehalten können?<br> Da könnte man jetzt super viel zu sagen. Man könnte jetzt auf AI eingehen und sagen, dass das nur den einen Teil beschleunigt, aber nicht den anderen.<br> Und dass der Mensch da der beschränkende Faktor ist und sein muss.<br> Ja, das tue ich jetzt nicht in der Tiefe, sondern hier geht es halt grundsätzlich darum, wir müssen halt das, die Geschwindigkeit, in der wir arbeiten, dauerhaft durchhalten.<br> Crunch-Zeit am Ende nützt halt nichts, das kann man mal machen, aber das wird man dauerhaft eben nicht durchhalten.<br> Der neunte Punkt lautet Zukunftsfähigkeit. Achten wir permanent auf technische Exzellenz und gutes Design.<br> Hier geht es darum, dass wir vielleicht ein bisschen mehr Zeit investieren in dem, was wir gerade tun, damit wir hinten später mal in einem halben Jahr, in einem Jahr Zeit sparen können.<br> Die Investition in technische Exzellenz steht hier oder in gutes Design, Software-Design, fühlt sich vielleicht erst mal falsch an.<br> Hey, können wir das nicht irgendwie machen? Aber man muss ja über einen größeren Zeitstrahl gucken.<br> Der zehnte Punkt steuert jetzt ein bisschen dagegen, nennt sich nämlich Einfachheit.<br> Konzentrieren wir uns auf das Wesentliche und lassen alles andere konsequent weg.<br> Das ist deswegen ein bisschen ein Gegenpol.<br> Technische Exzellenz könnte dazu führen, dass wir akademische Architektur machen.<br> Das macht man so. Und das ist damit nicht gemeint, sondern die Einfachheit ist auch ein wichtiger Punkt.<br> Das elfte Prinzip habe ich überschrieben mit Selbstorganisation.<br> Die Frage lautet, gestalten wir Architektur und Anforderungen eigenverantwortlich im Team?<br> Wir wollen, dass das Team in einem gesteckten Rahmen, da kommen wir irgendwann auch noch mal in einer anderen Folge dazu, die Chance hat, eigenverantwortlich zu arbeiten.<br> Und der zwölfte Punkt lautet Reflexion. Hinterfragen wir regelmäßig unser Vorgehen, um als Team besser zu werden.<br> Wir wollen eben gucken, wir haben was ausprobiert. Hat das gut oder nicht gut funktioniert? Was können wir lernen?<br> Ja, und das sind die zwölf agilen Prinzipien, die zu dem Agilen Manifest im Prinzip als Anhang dazugehören.<br> Sie sind eine Konkretisierung.<br> Mein Tipp wäre, nehmt euch mal einfach zwei, drei Fragen und stellt die mal in einem Daily oder wenn ihr über eine Story diskutiert.<br> Ich glaube, das ist ein sehr guter Prüfstein, um vor allen Dingen ins Gespräch zu kommen.<br> Ja, und wie so das Grundprinzip von dieser Serie ist, deswegen heißt es NBA Kompakt, soll es hier wirklich kurz und kompakt sein.<br> In der nächsten Folge wird es darum gehen, dass für mich Mindset vor Methode gilt und warum Agilität scheitert, wenn man bei Scrum anfängt statt beim Manifest.<br> Ja, wenn du Fragen hast, wenn du Anregungen hast, wenn du Kritik hast, freue ich mich immer.<br> Du findest alle Kontaktdaten in den Shownotes und ansonsten bleibt mir nur noch zu sagen, hab noch eine ganz tolle Woche und bis zum nächsten Mal.</p>
            ]]>
        </content>
    </entry>
    <entry>
        <title>NBAK02: Das Agile Manifest - Immer noch die Basis</title>
        <author>
            <name>Thomas</name>
        </author>
        <link href="https://no-bullshit-agile.de/nbak02-agiles-manifest-immer-noch-die-basis.html"/>
        <id>https://no-bullshit-agile.de/nbak02-agiles-manifest-immer-noch-die-basis.html</id>
        <media:content url="https://no-bullshit-agile.de/media/posts/199/nbak02-cover.jpg" medium="image" />
            <category term="Podcast"/>
            <category term="Grundlagen"/>

        <updated>2026-05-22T12:25:50+02:00</updated>
            <summary type="html">
                <![CDATA[
                        <img src="https://no-bullshit-agile.de/media/posts/199/nbak02-cover.jpg" alt="Agiles Manifest Basis" />
                    Das Agile Manifest ist 25 Jahre alt und passt auf eine halbe Seite. Trotzdem kennen es die meisten nicht, die „agil arbeiten". In dieser Folge gehe ich die vier Werte durch und stelle die Frage: Brauchen wir wirklich mehr als das Manifest? 2001 trafen sich 17 Leute in einem Ski-Resort&hellip;
                ]]>
            </summary>
        <content type="html">
            <![CDATA[
                    <p><img src="https://no-bullshit-agile.de/media/posts/199/nbak02-cover.jpg" class="type:primaryImage" alt="Agiles Manifest Basis" /></p>
                <p>Das Agile Manifest ist 25 Jahre alt und passt auf eine halbe Seite. Trotzdem kennen es die meisten nicht, die „agil arbeiten". In dieser Folge gehe ich die vier Werte durch und stelle die Frage: Brauchen wir wirklich mehr als das Manifest?</p>
<p>
<script class="podigee-podcast-player" src="https://player.podigee-cdn.net/podcast-player/javascripts/podigee-podcast-player.js" data-configuration="https://no-bullshit-agile.podigee.io/89-neue-episode/embed?context=external"></script>
</p>
<h2>Überblick</h2>
<p>2001 trafen sich 17 Leute in einem Ski-Resort in Utah. Das Ergebnis: vier Werte und zwölf Prinzipien, die auf eine halbe Seite passen. 25 Jahre später kennen die meisten eher den Scrum Guide als dieses Fundament. In dieser Folge erkläre ich die vier Werte kurz und knackig, frage warum so wenige Praktiker das Manifest wirklich kennen, und stelle die provokante These auf: Es reicht eigentlich, nur das Manifest zu verstehen.</p>
<h2>Zusammenfassung</h2>
<p>Das Agile Manifest fasst agiles Arbeiten in vier Werte zusammen: Menschen über Prozesse, funktionierende Software über Dokumentation, Kundenzusammenarbeit über Verträge, und Reagieren auf Veränderung über starre Pläne. Die rechte Seite ist nicht unwichtig – die linke ist nur wichtiger. Das Problem: Viele Teams arbeiten mit Scrum oder Kanban, ohne das Manifest je gelesen zu haben. Frameworks verdecken das Fundament. Dabei wurde das Manifest als ökonomische Strategie geschrieben – schneller Wert für Kunden, nicht bessere Arbeitskultur. Die gute Kultur ist ein Nebeneffekt. Wer die vier Werte und zwölf Prinzipien versteht und lebt, braucht im Grunde kein Framework.</p>
<h2>Shownotes</h2>
<ul>
<li>Du erreichst mich hier: <a href="https://no-bullshit-agile.de/kontakt.html">https://no-bullshit-agile.de/kontakt.html</a></li>
<li>Diese Folge ist Teil einer Serie "No Bullshit Agile Kompakt". Eine Übersicht über alle Folgen findest du hier: <a href="https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html">https://no-bullshit-agile.de/nba-kompakt-alle-folgen.html</a></li>
<li>Letze Folge "NBAK01: Gute Software schnell liefern" <a href="https://no-bullshit-agile.de/nbak01-gute-software-schnell-liefern.html">https://no-bullshit-agile.de/nbak01-gute-software-schnell-liefern.html</a></li>
<li>Die vier Werte des Agilen Manifests – kurz erklärt</li>
<li>Warum Frameworks das Fundament verdecken</li>
<li>Gedankenexperiment: Das Manifest als ökonomische Strategie</li>
<li>Agiles Manifest: <a href="https://agilemanifesto.org/iso/de/manifesto.html">https://agilemanifesto.org/iso/de/manifesto.html</a></li>
<li>Buch: „Agiles Arbeiten in der Praxis" - <a href="https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html">https://no-bullshit-agile.de/buch-agiles-arbeiten-in-der-praxis.html</a> </li>
<li>Diskutier mit auf Mastodon: <a href="mailto:https://mastodon.social/@nobsagile">https://mastodon.social/@nobsagile</a></li>
<li>NBA Kompakt – ein Thema, fünf Minuten, klare Meinung.</li>
</ul>
<h2>Transkript</h2>
<p> Hallo und herzlich willkommen bei NoBullshitAgileKompakt. Mein Name ist Thomas.<br> In der letzten Folge habe ich hier über einen meiner Lieblingssätze gesprochen, nämlich<br> gute Software schnell liefern. Hör da gerne mal rein, wenn dich das interessiert.<br> Heute soll es tatsächlich, wie du im Titel wahrscheinlich schon gesehen hast, um das Agile Manifest gehen.<br> Und stell dir mal selber die Frage, wann hast du das Agile Manifest das letzte Mal gelesen?<br> Nicht, wann hast du das letzte Mal von gehört, sondern wann hast du es dir bewusst angeguckt?<br> Und ich vermute einfach, die meisten von euch kennen wahrscheinlich den Scrum Guide und die<br> kennen ihn wahrscheinlich besser als das Agile Manifest. Und für mich ist es so, dass das<br> Manifest halt heute noch gilt und dass es einfach eine gute Basis ist, um über agiles Arbeiten<br> im Team zum Beispiel mal zu sprechen. Vielleicht kurz das Setting nochmal erklärt, woher kommt das<br> Agile Manifest? Wann ist es entstanden? Also, es gab ja so eine Bewegung aus dem klassischen,<br> der klassischen Softwareentwicklung, Wasserfallmodell.<br> Haben viele Leute schon erkannt, irgendwie funktioniert das so nicht in Softwareprojekten.<br> Und es gab, bevor es das Agile Manifest gab, XP, Extreme Programming, es gab tatsächlich auch<br> schon Scrum. Und irgendwann mal 2001 haben sich so ein paar Vordenker in Utah tatsächlich in<br> so einem Skiresort getroffen. Die haben gesagt, ey, lass uns mal zusammensetzen und gucken, ob wir<br> Gemeinsamkeiten finden, ob wir irgendeine Art finden, zu kommunizieren, was wir eigentlich sagen<br> wollen mit unseren Methoden, die wir vielleicht sogar schon benutzen. Und daraus entstanden, ist eine ganz<br> interessante Geschichte, ist dann eben schlussendlich das Agile Manifest. Und das Manifest zeichnet<br> meiner Meinung nach eben aus, dass es so kurz und knackig ist. Schlussendlich stehen da halt vier Werte.<br> Und ich will die gerne einmal kurz durchgehen und würde dich einfach bitten, dies sie doch auch nochmal<br> in Ruhe durch. Ich mache das hier natürlich auf Deutsch. Der erste Wert, der da steht, lautet<br> Individuen und Interaktion über Prozesse und Werkzeuge. Wichtig ist wirklich diese Formulierung<br> über. Also jedes Mal die Formulierung links steht was und das geht über das, was rechts steht. Das<br> bedeutet eben nicht, rechts ignorieren. In diesem Fall eben Individuen und Interaktionen sind<br> wichtiger, gehen über Prozesse und Werkzeuge. Das bedeutet, wir wollen uns nicht hinter einem<br> Prozess verstecken, sondern wir wollen direkt miteinander reden. Wir wollen nicht stur uns an<br> Tools festhalten. Welches Tool fällt mir jetzt sofort ein? Dir vielleicht auch? Jira. Jira hat ein<br> Verständnis von agilen Arbeiten, das an manchen Stellen vielleicht richtig ist, aber an vielen einfach<br> nicht. Und es wäre fatal zu sagen, aber Jira macht das so und deswegen geht hier Diskussionen an der<br> Stelle abbrechen. Genau, das ist das erste. Individuen und Interaktionen über Prozesse und Werkzeuge.<br> Das zweite lautet funktionierende Software über umfassende Dokumentation. Hier geht es eben darum zu sagen,<br> okay, was wollen wir eigentlich liefern? Was schafft denn Wert? Das ist eben ein Inkrement aus der<br> Software, ein Wert, der das Produkt ein Stück besser macht. Und natürlich ist Dokumentation auch ein<br> wichtiges Ding, aber es ist wichtiger, ein Stück Software in Produktion zu bringen. Ihr seht an diesen beiden<br> und auch an den nächsten beiden Werten schon, woher die kommen, warum das so aufgeschrieben wurde. Wie<br> gesagt, kurzer Reminder, wir sind so 2001 und es gibt schon länger, 10 Jahre, 15 Jahre erste Ansätze zu<br> versuchen, agiler zu werden, ohne dass das Wort so schon bekannt ist. Und in dieser Zeit davor war es eben<br> so, dass super viel vorgegeben wurde, weil die Idee war, wenn man alles definiert und alles vorgibt, dann kann<br> ja hinten nur noch das Richtige rauskommen. Und heute wissen wir eben ja, das funktioniert so nicht. Das wussten<br> die halt damals, Gänsefüßchen, auch schon. Und deswegen, eine Dokumentation ist eine schöne Sache, aber viel<br> wichtiger ist es ja, funktionierende Software zu schaffen. Projekte waren damals oft, oft, oft so, dass sie gar nicht aus der<br> Phase der Planung rausgekommen sind, sondern dann schon zum Beispiel so teuer geworden sind, dass man sie<br> abgebrochen hat. Und man hat nie richtige Software auf die Straße gekriegt.<br> Genau. Der dritte Wert, Zusammenarbeit mit dem Kunden, geht über Vertragsverhandlungen. Also, wir wissen, wir lernen im<br> Projekt. Kunden lernen ja auch im Projekt. Und wenn wir denken, das war vor drei Monaten mal sinnvoll, heißt das noch<br> lange nicht, dass es heute auch noch sinnvoll ist. Also, wir wollen eigentlich lieber gucken, okay, wir haben so viel<br> gelernt, lass uns das mal ein bisschen verändern, egal, was mal im Pflichtenheft stand. Und der vierte Wert, oder ja, der vierte<br> Wertepaar ist, reagieren auf Veränderungen geht über Befolgen eines Plans. Das ist ja mein ganz großes Mantra.<br> In der agilen Arbeit planen wir permanent. Es gibt nicht den einen Plan und dann sind wir drei Monate weg und halten uns<br> an dem Plan oder sechs Monate, sondern eigentlich wollen wir permanent planen. Wir tun das im Daily zum Beispiel, wir tun das<br> im Refinement, wir tun das in der Retro. Es gibt so viele Stellen, die eigentlich schon vorgesehen sind für dieses Plan.<br> Und das bedeutet eben, wenn man permanent plant, muss man auch bereit sein, einen bestehenden Plan zu verändern<br> und auch mal loszulassen.<br> Genau. Also, ganz wichtig, das sind eigentlich die Fundamente und meiner Meinung nach gelten die einfach heute auch noch<br> nach 25 Jahren. Und ich finde, es ist ein guter Startpunkt, darüber zu diskutieren.<br> Wenn ihr mal in einem Team an einem bestimmten Punkt seid und euch nicht sicher seid, also ich hatte ja vorhin dieses Jira-Beispiel,<br> schaut doch einfach mal ins Agile Manifest. Das gilt meiner Meinung nach heute auch noch.<br> Ich habe so ein bisschen das Gefühl, dass es keiner mehr so richtig kennt, weil das so verdeckt ist von Tools und Methoden,<br> die oben drauf sind. Also die Methode Scrum. Ich will jetzt nicht Scrum angreifen, aber die Leute kennen mehr den Scrum Guide,<br> als sie das Agile Manifest kennen. Und ja, wie gesagt, Toolings, dass wir so haben, Diskussionen, die wir führen,<br> gehen meistens gar nicht so richtig runter auf das Fundament.<br> Und wenn man das Agile Manifest nicht kennt, dann ist das eigentlich ein ganz guter Nährboden für das, was man so Cargo-Kult agil nennt.<br> Also man armt etwas nach. Agil in diesem Fall.<br> Da gehe ich übrigens in der Folge 6 noch mal ein bisschen genauer drauf ein.<br> Ansonsten habe ich noch tatsächlich mal mir Gedanken gemacht, was waren das für Leute, die da zusammengesessen haben und in welcher Situation waren die?<br> Und dazu habe ich so ein kleines Gedankenexperiment.<br> Was ist denn, wenn das Agile Manifest eine ökonomische Strategie ist, wenn es gar nicht darum geht, dass wir ein gutes Arbeitsumfeld haben?<br> Da werde ich in der Folge 7 drüber sprechen.<br> Und ja, kurz und knapp, das ist ja genau die Philosophie hier hinter No Bullshit Agile Compact, soll es das auch schon gewesen sein.<br> Wie immer freue ich mich auf ein Feedback, wie immer freue ich mich auf eine angeregte Diskussion auf Mastodon.<br> Ihr findet Links in den Shownotes, wie ihr mich erreichen könnt, schaut da gerne rein.<br> Und ansonsten sage ich, habt noch eine ganz tolle Woche und bis zum nächsten Mal.</p>
            ]]>
        </content>
    </entry>
</feed>
