![\"\"](\"https://no-bullshit-agile.de/media/posts/192/1.png\")
Ich wisst, dass ich ambivalent gegenüber dem Einsatz von AI bin. Ich nutze AI für \"dumme\" Tätigkeiten wie Dokumente zusammenfassen oder analysieren, aber auch für komplexere Tätigkeiten wie Vibe Coding (z.B. ist so Cylenivo entstanden - mehr dazu in dem verlinkten Artikel). In der Firma diskutieren wir auch immer wieder, wo mögliches Potential für den Einsatz von AI steckt - so wie jeder. Darum soll es aber in diesem Artikel nicht gehen.
\nWir erleben (weiterhin) eine Beschleunigung durch den Einsatz von AI, wenn wir uns den reinen Output ansehen. Es gibt sogar Unternehmen die, mir vollkommen unverständlich, verbrauchte Token als ein Ziel oder eine Messgröße für die Bewertung von Devs heranziehen - und es hat auch einen Namen: Tokenmaxxing (Oh je). Das alleine wäre einen weiteren Artikel wert. Nach meiner Einschätzung wird diese Beschleunigung auch noch anhalten.
\nWas wir aber viel zu wenig sehen ist die Messung des Werts dieses Outputs. Wird euer Produkt, das in dieser steigenden Geschwindigkeit weiterentwickelt wird, in der gleichen Geschwindigkeit bzw. mit der gleichen Beschleunigung auch besser? Das zweifle ich weiterhin an.
\nIch habe oben bewußt von Output und nicht von Outcome gesprochen. Für mich ist der Outcome strickt mit Wert verbunden. Welchen Wert haben wir durch die Anpassung dem Produkt hinzugefügt?
\nUm diese Frage zu beantworte, nehme ich gerne meine Work-Feedback Loop zur Hilfe. Die Grundthese der WFL und des agilen Arbeiten ist: Das Produkt muss sich in der Realität bewähren und auf reales Feedback in kurzer Zeit reagieren. In der Work-Feedback Loop haben wir dafür einen Zyklus, der das einfach aber prägnant bezeichnet:
\nEin System lernt nur dann zuverlässig aus Realität, wenn alle vier Schritte tatsächlich gekoppelt sind:
\nWenn AI uns jetzt auf der Work-Seite beschleunigt und mittlerweile in der Lage ist, dies sogar recht fehlerfrei zu tun, dann muss auch Feedback beschleunigt werden. Und zwar das Feedback aus der Realität. Nur so haben wir eine geschlossene Loop. Ich zweifle aber stark an, dass die Masse der Produktentwicklung/Produktmanagements dieses Feedback in der Geschwindigkeit bekommt und/oder verarbeiten kann.
\nIst dies nicht der Fall, landen wir im Quadranten \"Aktionismus\" der Diagnose-Matrix. Wir investieren ohne zu wissen, ob das Ergebnis wirklich Mehrwert schafft. Das kann ein StartUp tun, aber keine Versicherung oder Bank. Und tut es eine Versicherung doch, landen wir eben in dem Enshittification Land, dass alle User ja bekanntlich lieben.
\nUnd deswegen bricht hier die Mähr von der Beschleunigung von Systemen durch AI, die uns die Sams und Darios dieser Welt predigen.
\nIch habe hier ein ganz wundervolles Zitat von ThePrimeagen aus einem Talk für euch:
\n\n\nIf the cost of a line of code has dramatically dropped, then the cost of the right line of code has dramatically increased.
\n
Ich denke, damit ist klar, dass ein System nicht produktiver werden muss, nur weil es schneller wird.
\nIch würde mir wünschen, dass wir alle - gerade in der agilen Bubble - wieder mehr über die Feedback Loop sprechen, wenn wir über den AI Einsatz und das Umgehen damit sprechen.
", "image": "https://no-bullshit-agile.de/media/posts/193/schnell-produktiv.png", "author": { "name": "Thomas" }, "tags": [ "Grundlagen" ], "date_published": "2026-05-02T13:28:49+02:00", "date_modified": "2026-05-02T13:41:05+02:00" }, { "id": "https://no-bullshit-agile.de/cylenivo-ein-werkzeug-kein-cockpit.html", "url": "https://no-bullshit-agile.de/cylenivo-ein-werkzeug-kein-cockpit.html", "title": "Cylenivo: ein Werkzeug, kein Cockpit", "summary": "Die meisten Flow-Tools tun so, als wäre ihr eigentlicher Kunde der Manager. Dashboard, Ampel, Heatmap, fertig ist das Reporting. Das Team kommt in dieser Geschichte nur als Datenlieferant vor. Das ist einer der Gründe, warum ich Cylenivo entwickelt habe (ein zweiter ist, dass Jira einfach keine guten und sinnvollen Reportings…", "content_html": "Die meisten Flow-Tools tun so, als wäre ihr eigentlicher Kunde der Manager. Dashboard, Ampel, Heatmap, fertig ist das Reporting. Das Team kommt in dieser Geschichte nur als Datenlieferant vor.
\nDas ist einer der Gründe, warum ich Cylenivo entwickelt habe (ein zweiter ist, dass Jira einfach keine guten und sinnvollen Reportings hat).
\nCylenivo ist eine kleine kostenlose Desktop-App (Windows, Mac und Linux), die Cycle Time, Lead Time, Throughput, Time in Status und Rework aus deinen Ticketdaten rechnet. Dabei holt sie sich die Daten aus Jira oder via Plugins aus Trello oder OpenProject und verarbeite sie lokal.
\nDas ist der ganze Trick: ein Erkenntnis-Tool, kein Überwachungs-Tool.
\n![\"\"](\"https://no-bullshit-agile.de/media/posts/192/3.png\")
Weil ich wissen wollte, wie lange Tickets bei uns wirklich liegen. Nicht „wie lange ist done_date – start_date\", sondern wo die Zeit tatsächlich versickert. In welchem Status. Wie oft laufen Tickets rückwärts (\"Rework\"). Welcher Workflow-Schritt ist der heimliche Bremsklotz.
Diese Fragen kannst du in keinem PM-Tool sauber beantworten, weil die meisten Tools mit Ticket-Feldern rechnen. Cylenivo rechnet mit Statuswechseln und benutzt dabei jeder einzelne Übergang from_status → to_status mit Zeitstempel. Das ist der Unterschied zwischen „das Ticket war 12 Tage offen\" und „das Ticket war 4 Tage in Review, dann 6 Tage zurück in Dev, dann nochmal 2 Tage in Review\". Die zweite Geschichte ist die interessante.
![\"\"](\"https://no-bullshit-agile.de/media/posts/192/4.png\")
Ihr schaut euch gemeinsam die Cycle-Time-Verteilung an. P50, P85, P95. Die Frage ist nicht „wer ist langsam\". Die Frage ist „was lernen wir daraus\".
\nWenn die P85 doppelt so hoch ist wie die P50, hast du ein Outlier-Problem: irgendwo passiert regelmäßig etwas, was Tickets zurückwirft. Schau in die Rework-Analyse. Welcher Statuspfad wird am häufigsten rückwärts gegangen? Welche Tickets sind betroffen? Das ist eine Diagnose, kein Urteil.
\nGenau das macht Cylenivo zu einem Werkzeug für die Work–Feedback Loop: Du verkürzt die Schleife zwischen „wir arbeiten\" und „wir sehen, was unsere Arbeit bewirkt\". Sichtbarkeit über echte Durchlaufzeit + Rework gibt dem Team etwas, womit es seinen eigenen Prozess anpassen kann. Ohne dass jemand von außen kommt und „Maßnahmen\" definiert.
\nCylenivo ist kein Velocity-Dashboard fürs Management. Cylenivo hat keine Personenmetriken oder Geschwindigkeits-Bestenlisten. Wer Cylenivo nutzt, um einzelne Entwickler zu vergleichen, hat das Tool nicht verstanden und wird mit den Daten ohnehin nichts Sinnvolles anfangen können.
\nWas es kann: Monte-Carlo-Forecasts. Wenn dich jemand fragt, wann die nächsten 30 Tickets fertig sind, simulierst du das einmal aus den letzten Wochen Throughput und gibst eine ehrliche Bandbreite zurück. Keine erfundene Deadline, keine Story-Point-Magie.
\nAuf deiner Maschine: Wir benutzen eine SQLite-Datei im App-Verzeichnis. Wenn du die KI-Analyse nutzen willst, kannst du Ollama lokal anschließen oder einen externen Provider deiner Wahl konfigurieren. Aber niemand zwingt dich, Engineering-Daten in eine Cloud zu kippen, deren Geschäftsmodell du nicht kennst. Das ist mir wichtig genug, dass es eine Designentscheidung war, kein Feature-Bullet.
\nCylenivo ist Open Source (MIT + Commons Clause), läuft auf macOS, Linux und Windows und hat ein Plugin-System für Datenquellen jenseits von Jira. Die App lebt unter cylenivo.org, der Code ist auf github.com/nobsagile/cylenivo.
\nWenn du ein Team hast, das ehrlich auf seine eigene Arbeit schauen will, ist die App vielleicht etwas für dich. Wenn du ein Reporting-Tool für die nächste Steuerungsrunde suchst, gibt es bessere Optionen.
\nSchreib mir gern, wie es bei dir läuft – nobsagile@gmail.com oder https://mastodon.social/@cylenivo auf Mastodon.
", "image": "https://no-bullshit-agile.de/media/posts/192/1-2.png", "author": { "name": "Thomas" }, "tags": [ "Tools" ], "date_published": "2026-04-15T14:02:59+02:00", "date_modified": "2026-04-15T18:49:02+02:00" }, { "id": "https://no-bullshit-agile.de/ai-entwicklung-2026-kritisch-ja-blind-nein.html", "url": "https://no-bullshit-agile.de/ai-entwicklung-2026-kritisch-ja-blind-nein.html", "title": "„Fasse ich nicht an. Ist mit AI gemacht." Mein Plädoyer für eine informierte Meinung.", "summary": "Eigentlich gehört dieser Artikel nicht hierher. Wie ihr wisst, geht es mir in diesem Blog um agiles Arbeiten. Aber ich habe in den letzten Wochen eine Erfahrung gemacht, die mich beschäftigt, und die Reaktionen darauf haben mich dazu gebracht, diesen Post zu schreiben. Ich habe eine Desktop-App entwickelt: Cylenivo, verfügbar…", "content_html": "Eigentlich gehört dieser Artikel nicht hierher. Wie ihr wisst, geht es mir in diesem Blog um agiles Arbeiten.
\nAber ich habe in den letzten Wochen eine Erfahrung gemacht, die mich beschäftigt, und die Reaktionen darauf haben mich dazu gebracht, diesen Post zu schreiben. Ich habe eine Desktop-App entwickelt: Cylenivo, verfügbar für Windows, Mac und Linux. Die Idee dazu hatte ich schon ein bisschen länger, weil Cylenivo eine Lücke von Jira schließt: Gute Auswertung von Cycle und Lead Time (und ein paar weitere kleine Dinge...).
\nDas Problem: Ich kann nicht entwickeln. Was ich kann ist Konzeption so wie Ideen in gute User Experience verwandeln und ich habe das Domain-Wissen wie man z.B. sinnvoll eine Cycle Time berechnet (das ist komplexer, als man so denkt...).
\nWas in 2026 noch hinzu kommt: AI Coding hat nochmal einen großen Schritt gemacht. Die Tools der bekannten Hersteller rund um Entwicklung mit AI sind deutlich besser geworden als sie es z.B. in 2024 waren.
\nIch habe für Cylenivo mit Claude Code gearbeitet. Ich hätte genauso gut Codex oder Gemini nehmen können. Mir geht es in diesem Artikel nicht darum, welches Modell das beste ist. Was mich interessiert, ist der Stand der Dinge im Jahr 2026, und der ist ein anderer als noch 2024 oder 2025. Ich habe da schon viel mit AI-gestützter Entwicklung experimentiert und war oft von den Ergebnissen enttäuscht. Das ist heute anders. Die Qualität der Ergebnisse, die Verlässlichkeit in komplexeren Kontexten, die Fähigkeit, über mehrere Iterationen hinweg kohärenten Code zu produzieren hat sich substanziell verbessert.
\nDas als Vorrede und zur Herstellung des Kontext für euch.
\nAuf Cylenivo habe ich verschiedene Reaktionen bekommen. Eine davon war sinngemäß: „Fasse ich nicht an, ist mit AI gemacht.\" Ich habe darüber nachgedacht, und ich kann diese Haltung bis zu einem gewissen Grad verstehen (ich komme im nächsten Kapitel dazu). Was mich aber beschäftigt ist, dass die entscheidende Frage dabei vollständig ausgeblendet wird: Löst die App ein Problem? Tut sie das, wofür sie gebaut wurde? Ist sie nützlich? Das scheint für manche Menschen keine Rolle mehr zu spielen, sobald das Wort „AI\" im Raum steht. Und das finde ich nicht sinnvoll. Nicht wegen meiner App, sondern wenn man das weiter denkt.
\nIch halte das für einen Realitätsverlust, der einer nüchternen Betrachtung nicht standhält. Die meiste Software, die heute genutzt wird, enthält mit hoher Wahrscheinlichkeit Anteile, die mit AI-Unterstützung entstanden sind. Und das wird eher zunehmen. Wer also die AI gestützte Entwicklung konsequent ablehnen will, wird kaum noch Software finden, die er verwenden kann.
\nUnd dann ist da noch AI Slop. Das nervt mich auch: Inhaltslose LinkedIn-Posts, die offensichtlich von einem Modell generiert wurden und nichts Eigenes enthalten, Videos, in denen AI-generierte Stimmen bedeutungslose Texte vorlesen, Produkte, bei denen AI-Features eingebaut wurden, weil es gerade trendy ist, nicht weil sie irgendeinen Mehrwert bringen. Das ist AI Slop.
\nEine App, die ein konkretes Problem löst ist für mich aber kein Slop. Egal womit sie gebaut wurde. Hier wird gerade sehr viel in einen Topf geworfen, was nicht zusammengehört.
\nNatürlich gibt es auch bei mir große Bedenken, wohin uns das alles führen wird. Und es gibt legitime Einwände gegen AI und AI in der Softwareentwicklung, die ich auch genauso sehe, gerade weil ich in meinem Job Verantwortung für Entwicklerinnen und Entwickler trage.
\nDer offensichtlichste Einwand ist der ökologische. Der Energieverbrauch großer Sprachmodelle ist erheblich, und die Infrastruktur dahinter ist nicht klimaneutral. Wer das in seine Entscheidung einbezieht, hat gute Gründe dafür.
\nEin zweiter Einwand betrifft die Trainingsdaten. Modelle wurden auf Code und Inhalten trainiert, bei denen die Frage nach Urheberrecht und Einwilligung nicht eindeutig beantwortet ist. Hinzu kommt die Frage, was mit den Daten passiert, die man während der Nutzung eingibt. Das sind berechtigte Bedenken, die ich nicht wegdiskutieren will.
\nWas mich persönlich am meisten beschäftigt, ist die Frage nach der Entwicklung von Entwicklerinnen und Entwicklern. Wenn AI zunehmend den Code schreibt, was passiert dann mit dem Lernprozess? Wie wird aus einem Junior ein Senior, wenn ein Großteil der kognitiven Arbeit von einem Modell übernommen wird? Wird irgendwann eine Generation von Entwicklerinnen und Entwicklern heranwachsen, die gut darin ist, Code zu reviewen, aber nicht darin, ihn zu denken? Ich habe darauf keine Antwort. Die Frage ist vollkommen berechtigt.
\nDazu kommt die Geschwindigkeit selbst als Risiko. AI beschleunigt die Produktion von Code erheblich. Aber Feedback-Zyklen, also die Frage, ob das, was man produziert, auch wirklich gebraucht wird, laufen nicht schneller (s.a. Work-Feedback Loop). Die Gefahr von Aktionismus sollte nicht unterschätzt werden: Wir bauen mehr, schneller, aber nicht unbedingt das Richtige.
\nUnd schließlich gibt es noch den Punkt der Abhängigkeit. Wer heute seine Entwicklungsprozesse tief in AI-Tools einbettet, macht sich abhängig von Unternehmen, die ihre Preise und Bedingungen frei gestalten können. Das Muster kennen wir zum Beispiel durch Uber. Die haben in vielen US-Städten den klassischen Taximarkt nahezu verdrängt. Jetzt, wo die Alternativen verschwunden sind, steigen die Preise. Das gleiche Risiko besteht bei AI-Infrastruktur, wenn die Marktdurchdringung groß genug ist.
\nAll das gesagt, gibt es handfeste Vorteile die ihr sehen solltet und die mit in die Diskussion gehören. Der wichtigste für mich: Jemand, der nicht entwickeln kann, kann eine Idee trotzdem verwirklichen. Das ist keine Kleinigkeit. In Cylenivo steckt, wenn ich es grob schätze, ein Äquivalent von mehreren Hundert Stunden Entwicklungsarbeit. Als Hobby-Projekt, das ich kostenlos zum Download anbiete, wäre das über eine beauftragte Agentur oder einen freien Entwickler schlicht für mich nicht finanzierbar gewesen. Die Idee wäre in meinem Kopf geblieben und ein Produkt, dass Teams helfen kann, wäre nicht entstanden.
\nAI macht Entwicklung außerdem schneller (mittlerweile auch über den gesamten Lebenszyklus eines Produkts) und in bestimmten Kontexten kostengünstiger als rein menschliche Entwicklung. Das ist ein wirtschaftlicher Fakt, der bedrohlich ist. Es bleibt aber eine Tatsache und in einem Markt, in dem man weltweit konkurriert, ist es ökonomisch nicht sinnvoll, dieses Potential nicht zu nutzen. Es sei denn, man kann damit leben, dass ein Unternehmen stirbt. Das klingt dramatisch, aber letztendlich ist es so.
\nEs gibt einige Mythen über AI-gestützte Entwicklung, die möglicherweise in 2024 zutrafen, heute aber nicht mehr der Realität entsprechen. Der erste Mythos ist, dass es nur mit einem perfekten One-Shot-Prompt funktioniert, dass man von Anfang an genau wissen muss, was man will, und dass man bei einem Fehlschlag von vorne anfangen muss. Das stimmt nicht mehr. Iterative Entwicklung, Korrekturen, Nachfragen, das Verwerfen von Teilansätzen und der Neustart in einem Teilbereich ist heute ein ganz normaler Ablauf.
\nDer zweite Mythos ist, dass AI sich in komplexen Projekten hoffnungslos verrennt. Auch das entspricht nicht mehr meiner Erfahrung, wenn man die richtigen Rahmenbedingungen schafft.
\nDer dritte Mythos, dem ich ab und zu begegne: Komplexere Ideen sind grundsätzlich nicht umsetzbar. Cylenivo ist kein einfaches Produkt. Es enthält Berechnungen, Datenbanklogik, eine GUI für drei Betriebssysteme, Exportfunktionen und trotzdem hat es funktioniert, die App zu entwickeln.
\nDann gibt es noch den vierten Mythos der schlechten Code-Qualität und Wartbarkeit von AI-Code. Die hängt aber heute (übrigens wie bei menschlichen Entwicklern auch) vom Vorgehen ab. Wer AI-generierten Code ohne Review übernimmt, bekommt möglicherweise schlechten Code. Wer strukturiert vorgeht, regelmäßig reviewt und Architektur, Sicherheit und potenzielle Bugs explizit prüft, bekommt etwas anderes. Der Quellcode von Cylenivo ist öffentlich auf GitHub einsehbar. Schaut rein und gebt Feedback, das ist ausdrücklich erwünscht und ich würde mich sehr darüber freuen.
\nIch erlebe, dass die Anforderungen an die Person, die mit AI entwickelt, oft unterschätzt werden. Die Vorstellung, man könne einfach eine Idee eintippen und eine fertige App erhalten, ist heute immer noch verbreitet. Tatsächlich eben oft unter den Menschen, die AI komplett ablehnen. Was man tatsächlich braucht, lässt sich in vier Bereichen beschreiben.
\nErstens braucht man ein gutes Harness für die AI: sehr gute, strukturierte Informationen über das Projekt, den Tech Stack, die Architektur. Tools wie Context7 helfen dabei, aktuelle Dokumentation in den Kontext zu bringen. Meta-Informationen (wie z.B. die CLAUDE.md) müssen permanent aktuell gehalten werden. Und nach jeder bedeutenden Änderung gehört ein explizites Review auf Architektur, Sicherheit und Bugs dazu. Nicht als optionaler Schritt, sondern als fester Bestandteil des Prozesses. (auch hier: Wie sonst auch, wenn Menschen entwickeln).
\nZweitens braucht man Erfahrung in der jeweiligen Domain. Konzept und Produktidee kann AI nicht liefern, Design im Sinne von Nutzerführung und Interaktionslogik muss vom Menschen kommen und setzt Erfahrung voraus. Berechnungen müssen verstanden und vorgegeben werden. Ein Beispiel aus Cylenivo: Was ist Cycle Time wirklich? Von welchem Moment zu welchem Moment wird sie gemessen? Wird sie nur einmal gemessen oder auch, wenn der Status eines Tickets die Cycle Time Grenzen mehrfach überschreiten? Das ist eine fachliche Entscheidung, keine technische, und sie muss der Mensch treffen.
\nDrittens spielt Erfahrung im Prompting eine erhebliche Rolle. Ich mache das seit Ende 2022, und ich lerne bis heute dazu. Die Fähigkeit, eine Anforderung so zu formulieren, dass das Modell sie richtig interpretiert, ist nicht trivial und kommt nicht von selbst.
\nViertens: Das Toolset drumherum ist genauso wichtig wie bei klassischer Entwicklung. Tests (und zwar durchdachte Tests, nicht irgendwelche) sind unverzichtbar. Eine vernünftige Entwicklungsumgebung, klare Testszenarien, ein strukturierter Arbeitsablauf und kleine Stories. Das ist im Kern analog zu dem, was menschliche Entwicklerinnen und Entwickler auch brauchen.
\nIch kann nachvollziehen, warum Menschen AI in der Softwareentwicklung ablehnen. Die Einwände (Umwelt, Datenethik, die Frage nach der Zukunft des Entwicklerberufs, Abhängigkeit von großen Unternehmen) sind real und verdienen eine ernsthafte Auseinandersetzung. Was ich nicht nachvollziehen kann, ist eine pauschale Ablehnung, die auf diesen Argumenten nicht wirklich aufbaut, sondern sich mit dem Schlagwort „AI\" begnügt.
\nMeine Empfehlung ist klar: Schaut euch an, wie AI-gestützte Entwicklung heute tatsächlich funktioniert, bevor ihr euch eine feste Meinung bildet. Gerade wenn ihr gegen AI seid und wenn ihr Devs seid. Nicht weil ihr AI gut finden müsst, sondern weil eine fundierte Meinung besser ist als eine reflexhafte. Das gilt für dieses Thema genauso wie für jedes andere.
", "image": "https://no-bullshit-agile.de/media/posts/191/1-1.png", "author": { "name": "Thomas" }, "tags": [ "Tools" ], "date_published": "2026-04-08T12:33:14+02:00", "date_modified": "2026-04-08T13:28:51+02:00" }, { "id": "https://no-bullshit-agile.de/ki-realistischer-einsatz-agiles-arbeiten.html", "url": "https://no-bullshit-agile.de/ki-realistischer-einsatz-agiles-arbeiten.html", "title": "KI reduziert meinen Mental Load. Mehr nicht. Und das reicht.", "summary": "Ich bin der festen Überzeugung, dass agiles Arbeiten das beste vorgehen ist, wenn es darum geht gute Software schnell zu liefern. Dabei hängt das nicht von einer Methode ab, sondern davon, die Work-Feedback Loop geschlossen und kurz zu halten. Daher ist mein Hauptthema momentan genau das. Und Ich bin von…", "content_html": "Ich bin der festen Überzeugung, dass agiles Arbeiten das beste vorgehen ist, wenn es darum geht gute Software schnell zu liefern. Dabei hängt das nicht von einer Methode ab, sondern davon, die Work-Feedback Loop geschlossen und kurz zu halten. Daher ist mein Hauptthema momentan genau das.
\nUnd Ich bin von zwei Seiten genervt.
\nVon der einen Seite höre ich auf Konferenzen, in Podcasts und in meinem Feed, dass KI alles verändert. Dass agiles Arbeiten damit überflüssig wird. Dass Teams sich neu erfinden müssen, weil ein Prompt das jetzt alles erledigt. Von der anderen Seite höre ich, dass KI Teufelszeug ist, dass man bloß die Finger davon lassen soll, dass das alles maßlos überschätzt wird.
\nNach meiner Erfahrung ist KI ein Tool wie Excel (ok, es ist deutlich mächtiger als Excel, aber eben nur ein Tool). Dieses Tool kann man, wie andere Tools, sinnvoll einsetzten um agiles Arbeiten zu unterstützen. Dieser Artikel stellt meinen pragmatischen Blick auf KI dar.
\nIch nutze KI seit ChatGPT im Dezember 2022 erschienen ist – erst neugierig, dann systematisch, dann ernüchtert, dann pragmatisch. Ich habe viel ausprobiert, viel Zeit verschwendet und ein paar Dinge gefunden, die wirklich funktionieren. Darum geht es hier.
\nIch bin Team Lead eines Kanban-Teams mit sieben Leuten. Wir machen Projekte für unterschiedliche, aber immer die selben Kunden. Ich bin kein Entwickler. Meine Arbeit passiert in zwei Richtungen: nach innen - das Team unterstützen, Prozesse gestalten, Stories schreiben, in der Konzeption unterstützen, etc. Nach außen - Projekte mit Kunden planen, Strategien mit Kunden entwickeln, Jour Fixes und weitere Meetings zur Abstimmung gestalten.
Mein tägliches Toolset: Jira, Confluence, Slack, Mail, Kalender, Joplin für Notizen.
Das Werkzeug, das ich für KI nutze, heißt Claude Cowork. Der entscheidende Grund: Es verbindet sich direkt mit Jira, Confluence, Slack, Mail, Kalender und Joplin. Das macht einen Unterschied, den ich gleich erklären werde.
Ein Wort zur Datenfrage, bevor jemand fragt: Ich habe KI lesenden Zugriff auf meine Mail und meinen Kalender gegeben. Das ist eine Entscheidung, die ich bewusst getroffen habe - und eine, die jeder für sich selbst treffen muss. Ich gebe keinen Rat dazu, weil das von der eigenen Situation, dem Arbeitgeber und der persönlichen Risikoeinschätzung abhängt. Ich berichte nur, was ich tue.
Bevor ich auf die konkreten Anwendungsfälle eingehe, ein paar grundsätzliche Beobachtungen aus drei Jahren Praxis:
\nKI verstärkt. Wenn etwas ohne KI schon gut funktioniert, kann KI es besser machen. Wenn etwas schlecht ist, macht KI es schlechter. Das klingt trivial, ist es aber nicht, wenn man ehrlich hinschaut.
\nKI produziert viel. Die Falle ist, dass man sich produktiv fühlt, ohne es zu sein. Ich habe das selbst erlebt. Man lässt KI etwas generieren, es sieht gut aus, man fühlt sich effizient. Aber hat es wirklich Zeit gespart? Diese Frage muss man sich stellen - immer wieder, unbequem ehrlich.
\nKI kann nicht denken. Alles, was Erfahrung, Einschätzung oder Kreativität braucht, ist nichts für KI. Eine User Story zu schreiben, die wirklich gut ist, kann KI nicht. Die Anforderungen verstehen, die Lücken erkennen, die richtigen Fragen stellen, das ist Menschenarbeit. Was KI gut kann: große Mengen Text schnell lesen, Zusammenfassungen bauen, Verbindungen zwischen Datenpunkten finden, die man selbst übersehen hätte, wenn man es eilig hat.
\nKI macht Fehler. Immer noch. Und das wird sich nicht vollständig ändern. Human in the Loop ist keine Option, es ist Pflicht.
\nDas ist mein bestes Beispiel, weil es den Unterschied zwischen \"KI als Chat-Tool\" und \"KI mit Datenzugang\" am deutlichsten zeigt.
\nIch habe einen sogenannten Skill in Claude Cowork - das ist im Grunde eine Anweisungsdatei, die beschreibt, was die KI tun soll. Dieser Skill macht folgendes: Er schaut im Kalender nach, wann der letzte Jour Fix mit dem jeweiligen Kunden war. Er liest das Protokoll und die Notizen vom letzten Termin aus Joplin - oder bei manchen Kunden aus Confluence. Er durchsucht Jira nach allem, was sich seit dem letzten Termin verändert hat: neue Stories, Status-Updates, Blocker. Er liest die relevanten Mails der Zwischenzeit.
\nAus all dem erzeugt er eine strukturierte Vorlage: Was sollte ich im nächsten Jour Fix ansprechen? Welche Punkte sind offen geblieben? Was hat sich verändert?
\nWas dabei auffällt: Die KI findet Verbindungen, die ich als Mensch, wenn ich es eilig habe, übersehen hätte. Eine Mail, in der ein Kunde eine Erwartung erwähnt hat, die in keiner Story steht. Ein Status in Jira, der nicht zum aktuellen Stand in der letzten Notiz passt. Diese Querverbindungen zwischen mehreren Datenquellen sind der eigentliche Mehrwert, nicht der generierte Text.
\nDie erzeugte Notiz bearbeite ich natürlich, weil KI Fehler macht. Und weil ich das letzte Wort haben will. Aber der Start ist gut, und die Zeitersparnis ist real.
\nIch bin Teilnehmer im täglichen Daily, kein Moderator, aber ich bringe meine Sicht als Team Lead mit ein. Dafür habe ich einen eigenen Skill.
Dieser Skill schaut sich das letzte Daily-Protokoll aus Joplin an und geht dann durch Jira, Slack und Mail seit dem letzten Daily. Er schreibt einen neuen Report: Was sollte ich heute ansprechen?
Das klingt simpel, ist aber in der Praxis ziemlich nützlich. Wenn in Mails oder Slack Status-Updates vorhanden sind, die in den entsprechenden Stories nicht aktualisiert wurden, fällt das dem Skill auf. Er erkennt Stories, die zu lange in einem Status hängen. Er sieht, wenn jemand eine Krankmeldung geschickt hat, und verknüpft das mit den Story-Assignments - mit dem Hinweis, dass das Team prüfen sollte, ob jemand anderes übernimmt.
Diese Verbindungen kann ein Mensch auch erkennen. Ich schaue das selbst auch durch, weil KI Fehler macht. Aber die KI findet sie zuverlässig und schnell, auch wenn ich unter Zeitdruck stehe. Das ist der Punkt.
Für andere Meetings, z.B. Projektmeetings, Refinements, unstrukturiertere Abstimmungen, gibt es einen ähnlichen, aber flexibleren Skill. Er zieht ebenfalls Infos aus allen angebundenen Quellen und erzeugt eine Zusammenfassung dessen, was relevant sein könnte.
\nDie Ergebnisse sind hier etwas schlechter als beim Jour-Fix-Skill. Der Grund ist einfach: Je mehr Struktur ein Meeting hat, desto besser kann KI sich darauf vorbereiten. Beim Jour Fix weiß der Skill genau, was er suchen soll. Bei einem freieren Meeting ist der Suchraum größer, die KI unsicherer, was wirklich wichtig ist.
\nTrotzdem: Als Startpunkt ist auch dieser Skill gut. Ich muss die erzeugte Notiz deutlicher bearbeiten, aber ich fange nicht bei null an, und das spart Zeit.
\nIch habe noch weitere kleinere Anwendungsfälle wie z.B. Zusammenfassung von Informationen und Analyse von Dokumenten, aber ich denke, das macht mittlerweile jeder und daher habe ich in diesem Artikel darauf keinen Fokus gesetzt.
\nKI ist kein Ersatz für agiles Arbeiten. Sie macht Teams nicht schneller, Prozesse nicht schlanker und Feedback-Loops nicht kürzer. Das muss der Mensch tun. Mit Erfahrung, Disziplin und dem Willen, Dinge wirklich zu verbessern.
Was KI macht: Sie nimmt mir den kognitiven Overhead ab, Informationen aus verschiedenen Quellen mühsam zusammenzusuchen. Das Ergebnis ist, dass ich meine Energie für das einsetzen kann, wofür sie wirklich gebraucht wird - für mein Team, für meine Kunden und für die inhaltliche (Denk-)Arbeit.
Mental Load reduzieren ist kein glamouröses Ziel. Es ist kein \"KI verändert alles\". Aber es ist real, messbar und täglich spürbar.
Das reicht mir.
", "image": "https://no-bullshit-agile.de/media/posts/190/ki-sinnvoll.png", "author": { "name": "Thomas" }, "tags": [ "Tools" ], "date_published": "2026-03-20T16:12:50+01:00", "date_modified": "2026-03-20T16:33:36+01:00" }, { "id": "https://no-bullshit-agile.de/kontext-work-feedback-loop.html", "url": "https://no-bullshit-agile.de/kontext-work-feedback-loop.html", "title": "Entstehung, Idee und Einordnung der Work-Feedback Loop", "summary": "Seit der Veröffentlichung der Work-Feedback Loop habe ich ein paar Fragen bekommen. Zeit, diese in einem Artikel zu beantworten. In Gesprächen online (vor allem auf Mastodon), aber auch auf der Arbeit, bin ich immer wieder an den Punkt gekommen, mir die Frage zu stellen, wie ich agiles Arbeiten definiere. Weiterhin…", "content_html": "
Seit der Veröffentlichung der Work-Feedback Loop habe ich ein paar Fragen bekommen. Zeit, diese in einem Artikel zu beantworten.
\nIn Gesprächen online (vor allem auf Mastodon), aber auch auf der Arbeit, bin ich immer wieder an den Punkt gekommen, mir die Frage zu stellen, wie ich agiles Arbeiten definiere. Weiterhin hab ich vermehrt - auch für mich selber - festgestellt, dass der Begriff agil ziemlich verbrannt ist.
\nAus diesen beiden Blickwinkeln - was ist die Essenz von agilem Arbeiten und wie kann man sie erklären, ohne den Begriff agil zu benutzen - ist die Work-Feedback Loop entstanden.
\nSchlussendlich geht es darum, dass wir nur erfolgreich in einem schnellen Markt arbeiten können, wenn Arbeit (\"Work\") mit Reaktion (\"Feedback\") eng gekoppelt ist. Es ist nötig, dass Feedback einen direkten Einfluss auf Arbeit hat. Zitat aus dem ersten Absatz der Work-Feedback Loop:
\n\n\nDie Work–Feedback Loop ist ein Denk- und Diagnosemodell, das zeigt, ob Arbeit in deiner Organisation realen Effekt erzeugt, sichtbar wird, Entscheidungen auslöst und dadurch zukünftige Arbeit tatsächlich verändert. So findest du schnell die strukturelle Engstelle, die eure Anpassungsfähigkeit begrenzt – ohne über Methoden oder „Agilität“ als Label zu diskutieren.
\n
Dieses prägnante Bild ist die Basis und so ist die Work-Feedback Loop entstanden. Die Entwicklung hin zu einem Diagnose-Modell war dann der natürliche nächste Schritt.
\nUnd der Begriff Modell ist mir hier wichtig. Die Work-Feedback Loop ist keine Methode. Sie ist kein Ersatz für Scrum oder Kanban. Sie will auch andere Methoden und Denkmodelle wie Flight Levels oder PDCA nicht ersetzen.
\nUnd damit kommen wir zu der zweiten Frage, die ich so öfter bekommen habe.
\nIch denke, der beste Einstieg ist die folgende Grafik.
\n![\"\"](\"https://no-bullshit-agile.de/media/posts/189/work-feedback-context-1080-2.png\")
Ich teile hier die nahen Begriffe in die Dimensionen \"Team Level\" oder \"System Level\" sowie \"Unterstützt Arbeit\" oder \"Erklärt Systeme\" ein.
\nMethoden oder Modelle, die eher operativ und nahe am Team sind, sind weiter unten angesiedelt. Sind sie eher für die tägliche Arbeit gedacht, befinden sie sich weiter rechts.
\nScrum als Methode ist in dieser Sicht unten links im Diagramm. Das Cynefin-Framework als Methode um Komplexität einzuordnen und daraus angemessene Entscheidungen und Handlungsweisen abzuleiten ist oben rechts.
\nDie Work-Feedback Loop versteht sich als Denkmodell für die Diagnose. Sie ist nicht als alltägliches Tool oder gar Methode zu verstehen. Daher steht sie relativ weit oben. Mit der Work-Feedback Loop lassen sich Systeme sehr gut diagnostizieren, daher steht sie relativ weit rechts.
\nDamit sind die beiden großen Fragen erst einmal erläutert. Natürlich freue ich mich auf weiteres Feedback - ihr erreicht mich hier.
", "image": "https://no-bullshit-agile.de/media/posts/189/work-feedback-context.png", "author": { "name": "Thomas" }, "tags": [ "Grundlagen" ], "date_published": "2026-03-07T15:43:28+01:00", "date_modified": "2026-03-07T17:13:42+01:00" }, { "id": "https://no-bullshit-agile.de/flight-levels-verschachtelte-work-feedback-loops-lerngeschwindigkeit.html", "url": "https://no-bullshit-agile.de/flight-levels-verschachtelte-work-feedback-loops-lerngeschwindigkeit.html", "title": "Flight Levels und verschachtelte Work–Feedback Loops: Entscheidungsarchitektur und Lernphysik verbinden", "summary": "Flight Levels beschreiben, wo in einer Organisation Entscheidungen getroffen werden. Verschachtelte Work–Feedback Loops beschreiben, ob diese Entscheidungsebenen tatsächlich lernfähig sind. Dieser Unterschied ist entscheidend. Das eine ist eine Landkarte von Koordination und Autorität. Das andere ist der zugrunde liegende Mechanismus, der die Lerngeschwindigkeit bestimmt. Werden beide Perspektiven kombiniert, entsteht kein…", "content_html": "Flight Levels beschreiben, wo in einer Organisation Entscheidungen getroffen werden. Verschachtelte Work–Feedback Loops beschreiben, ob diese Entscheidungsebenen tatsächlich lernfähig sind. Dieser Unterschied ist entscheidend. Das eine ist eine Landkarte von Koordination und Autorität. Das andere ist der zugrunde liegende Mechanismus, der die Lerngeschwindigkeit bestimmt. Werden beide Perspektiven kombiniert, entsteht kein weiteres Framework-Hybrid, sondern eine strukturelle Sichtweise darauf, wie Organisationen sich über Ebenen hinweg anpassen.
\nFlight Levels werden typischerweise als drei miteinander verbundene Ebenen verstanden: operative Lieferung, teamübergreifende Koordination und strategische Ausrichtung. Jede Ebene repräsentiert einen eigenen Entscheidungskontext mit eigener Taktung und eigenem Wirkungsbereich. Diese Sicht macht deutlich, wo Arbeit gesteuert und wo Richtung vorgegeben wird. Doch das Identifizieren von Entscheidungsebenen stellt noch nicht sicher, dass diese Ebenen wirksam auf die Realität reagieren. Dafür braucht es eine andere Perspektive – und genau hier wird die Work–Feedback Loop zentral.
\nDie Work–Feedback Loop beschreibt eine einfache strukturelle Dynamik: Arbeit trifft auf Realität, Realität erzeugt Feedback, und Lernen entsteht nur dann, wenn dieses Feedback nachfolgende Entscheidungen und Handlungen verändert. Lerngeschwindigkeit wird daher nicht dadurch bestimmt, wie viele Daten eine Organisation sammelt, sondern dadurch, wie sicher und wirtschaftlich sie Signale in Veränderung übersetzen kann. Wenden wir diese Linse auf Flight Levels an, wird jede Ebene selbst zu einer Schleife mit eigenem Feedback-Zyklus, eigener Taktung und eigenen Entscheidungsrechten. Die Ebenen sind nicht nur übereinandergestapelt – sie sind ineinander verschachtelt.
\nAuf der operativen Ebene läuft die Schleife in der Regel mit hoher Frequenz. Teams bauen, beobachten das Systemverhalten, passen Code oder Prozesse an und wiederholen den Zyklus. Feedback zeigt sich in Testergebnissen, Laufzeitsignalen, Fehlermustern oder direkten Nutzerreaktionen. In gut gestalteten Systemen kann diese Schleife eng und reaktionsfähig sein. Häufig wird operatives Lernen jedoch durch äußere Schleifen begrenzt. Architekturgates, Finanzierungslogiken oder Freigabemechanismen verzögern oder verwässern die Reaktion. Feedback ist vorhanden, doch die Fähigkeit zu handeln ist strukturell eingeschränkt. Die Schleife ist aktiv, aber teilweise blockiert.
\nDie Koordinationsebene bringt ein anderes Tempo und einen größeren Wirkungsbereich mit sich. Der Fokus verschiebt sich von einzelnen Features hin zum Fluss über Teams und Wertströme hinweg. Signale zeigen sich in Warteschlangenlängen, blockierter Arbeit, Integrationsreibung oder Nacharbeitsmustern. Ziel dieser Schleife ist nicht die Optimierung lokaler Produktivität, sondern die Regulierung des systemischen Flusses. Dennoch operieren Koordinationsschleifen häufig innerhalb von Rahmenbedingungen, die sie selbst nicht beeinflussen können. Wenn Anreizsysteme Auslastung statt Fluss belohnen, reagiert die Schleife rational – aber innerhalb fehlgeleiteter Leitplanken. Lernen findet statt, jedoch nur innerhalb von Grenzen, die die Gesamtleistung untergraben.
\nAuf der strategischen Ebene dehnt sich die Schleife weiter in Zeit und Wirkung aus. Entscheidungen betreffen Investitionslogik, Portfolio-Reihenfolge und Risikobereitschaft. Feedback erscheint in Form von Ergebniskennzahlen, Marktreaktionen, Opportunitätskosten und Verschiebungen der Wettbewerbsposition. Die Herausforderung liegt hier selten im Mangel an Information, sondern in der Entscheidungslatenz. Signale steigen aus unteren Schleifen auf, doch Mechanismen zur Anpassung von Prioritäten, Finanzierungsmodellen oder strategischer Ausrichtung bleiben langsam oder unklar. Verantwortung diffundiert, Reaktionen werden vorsichtig. Lernen verlangsamt sich gerade dort, wo sein Hebel am größten wäre.
\nDurch diese Linse betrachtet liegt das zentrale Problem nicht in der Existenz von Schleifen, sondern in ihrer Kopplung. Verschachtelte Schleifen bedeuten wechselseitige Abhängigkeit. Äußere Schleifen definieren Intention und Rahmenbedingungen für innere Schleifen. Innere Schleifen erzeugen Signale, die äußere Entscheidungen informieren und verändern sollten. Wenn diese abwärts- und aufwärtsgerichtete Kopplung funktioniert, bleiben Rahmenbedingungen adaptiv statt starr. Wenn sie versagt, entsteht ein vertrautes Muster: hohe Transparenz, zahlreiche Kennzahlen, häufige Reports – und dennoch minimale strukturelle Bewegung. Feedback sammelt sich an, wird jedoch nicht in autorisierte Veränderung übersetzt.
\nDiese Dynamik erklärt, warum die Einführung von Flight Levels allein keine Verbesserung garantiert. Das Etablieren von Meetings oder Koordinationsebenen klärt, wo Gespräche stattfinden, stellt aber nicht sicher, dass Feedback in wirtschaftlich tragfähige Maßnahmen übersetzt wird. Die Existenz eines Entscheidungsgremiums bedeutet nicht, dass Entscheidungsrechte klar sind, dass Handlungsoptionen bezahlbar sind oder dass Rahmenbedingungen ohne politische Reibung angepasst werden können. Fehlen diese Eigenschaften, existieren Schleifen formal, aber nicht funktional.
\nVerschachtelte Work–Feedback Loops bieten eine diagnostische Erweiterung zu Flight Levels. Sie erlauben zu prüfen, ob jede Ebene eine definierte Taktung besitzt, ob Feedback systematisch in Optionen übersetzt wird, ob diese Optionen innerhalb akzeptabler Risiken umsetzbar sind und ob Entscheidungsbefugnis mit Verantwortung übereinstimmt. Diese Fragen verschieben den Fokus von Koordinationsritualen hin zu struktureller Fähigkeit. Zugleich wird eine zentrale Einsicht sichtbar: Skalierung bedeutet nicht primär, zusätzliche Koordinationsebenen einzuführen, sondern die Kopplung zwischen Schleifen zu verbessern, sodass Lernen sich über Ebenen hinweg fortpflanzt.
\nWerden Flight Levels als Entscheidungsarchitektur der Organisation verstanden und verschachtelte Work–Feedback Loops als ihre Lernphysik, verändert sich der Fokus. Es geht nicht mehr nur um Alignment oder Transparenz. Es geht um die Erhöhung der Lerngeschwindigkeit über miteinander verbundene Autoritätsebenen hinweg. Dafür muss Feedback aus der operativen Realität strategische Intention ohne übermäßige Verzögerung beeinflussen können, und strategische Anpassungen müssen operative Rahmenbedingungen verändern können, ohne die Ausführung zu destabilisieren. In solchen Systemen wird Anpassungsfähigkeit zur strukturellen Eigenschaft statt zum heroischen Einzelakt.
\nDie praktische Konsequenz ist zugleich einfach und anspruchsvoll. Organisationen leiden nicht an einem Mangel an Feedback. Sie leiden an strukturellen Begrenzungen, die verhindern, dass Feedback zu bezahlbarer Veränderung wird. Betrachtet man Flight Levels durch die Linse verschachtelter Work–Feedback Loops, lässt sich nicht nur erkennen, wo Entscheidungen verortet sind, sondern auch, ob diese Entscheidungen in Schleifen eingebettet sind, die tatsächlich lernen. Erst dann wird aus Koordination echte Fähigkeit – und erst dann unterstützt Struktur nachhaltiges Lernen, statt es zu behindern.
", "image": "https://no-bullshit-agile.de/media/posts/188/scale.png", "author": { "name": "Thomas" }, "tags": [ "Grundlagen" ], "date_published": "2026-02-06T12:11:15+01:00", "date_modified": "2026-02-06T12:11:15+01:00" }, { "id": "https://no-bullshit-agile.de/die-work-feedback-loop.html", "url": "https://no-bullshit-agile.de/die-work-feedback-loop.html", "title": "Die Work–Feedback Loop", "summary": "Wenn Feedback die Arbeit nicht verändert, ist es kein Feedback. Die meisten Organisationen glauben, sie hätten Feedback. Sie führen Retrospektiven durch, sammeln Nutzer:innen-Feedback, verfolgen Kennzahlen und OKRs – und dennoch verändert sich die zugrunde liegende Arbeit nur selten in einer relevanten Weise. Feedback ist keine Information. Es ist nur dann…", "content_html": "Wenn Feedback die Arbeit nicht verändert, ist es kein Feedback.
Die meisten Organisationen glauben, sie hätten Feedback. Sie führen Retrospektiven durch, sammeln Nutzer:innen-Feedback, verfolgen Kennzahlen und OKRs – und dennoch verändert sich die zugrunde liegende Arbeit nur selten in einer relevanten Weise. Feedback ist keine Information. Es ist nur dann Feedback, wenn es das nächste Stück Arbeit verändert. Wenn das Reagieren auf ein Signal langsam, teuer oder strukturell schwierig ist, verhält sich das System rational: Es nimmt das Signal zur Kenntnis – und arbeitet weiter wie zuvor. Das ist kein Mindset-Problem. Es ist ein Kopplungsproblem. Die Work–Feedback Loop ist ein kleines Denkmodell, um diese Dynamik sichtbar zu machen und zu prüfen, ob ein System tatsächlich lernen kann.
Die vollständige Erklärung findest du hier: Die Work–Feedback Loop
Wenn KI so leicht zu nutzen wäre, wie viele Posts suggerieren, bräuchte es nicht so viele Posts, die erklären, wie man sie nutzt.
In den letzten Monaten ist mir ein klares Muster in KI-Artikeln in Blogs, Podcasts und Social-Media-Posts aufgefallen, besonders auf LinkedIn. Der Fokus liegt nicht mehr auf Rechtschreibkorrektur oder Zusammenfassungen. Diese Use Cases sind inzwischen Commodity. Stattdessen hat sich die Aufmerksamkeit auf deutlich größere Versprechen verlagert: KI für Product Management, HR, Marketing, Prozessautomatisierung, sogar Strategie.
Was daran aufschlussreich ist, ist nicht die Ambition hinter diesen Versprechen. Es ist die Menge an Anleitung, die nötig ist, damit sie funktionieren. Es gibt seitenlange Blogartikel und lange YouTube-Videos, die alle notwendigen Schritte und Kontrollen erklären, um KI „erfolgreich“ zu machen – ohne anzuerkennen, was diese Komplexität eigentlich bedeutet. Und die Autor:innen merken es nicht einmal.
Die meisten dieser Artikel beschreiben keine einfachen Tools, die Teams einfach aufnehmen und nutzen können. Sie beschreiben sorgfältig konstruierte Setups, die auf ausgefeilten Prompt-Anweisungen, verketteten Interaktionen, manuellen Validierungsschritten und wiederholtem menschlichem Eingreifen beruhen, um subtile, aber teure Fehler zu vermeiden. Je ambitionierter der Use Case, desto mehr Gerüstbau entsteht um die KI herum.
Diese Details sind wichtig, weil sie etwas Grundlegendes offenlegen. Diese Art der KI-Nutzung ist kein Plug-and-Play-Beschleuniger. Es ist explorative Arbeit. Die Ergebnisse sind unsicher, die Varianz ist hoch, und Feedback kommt verzögert. Fortschritt entsteht nicht durch Ausführungsgeschwindigkeit, sondern durch wiederholtes Prüfen und Korrigieren.
Hier sitzt der eigentliche Kostenblock der KI-Einführung. Nicht primär in Tokens. Nicht in Tool-Lizenzen. Die dominanten Kosten verstecken sich im Work–Feedback-Loop.
Jemand probiert einen Ansatz aus, prüft das Ergebnis, passt den Prompt an, baut eine weitere Absicherung ein, lässt den Prozess erneut laufen und bewertet wieder. Jeder Zyklus wirkt für sich genommen klein. Zusammen ergeben sie einen langsamen und teuren Lernzyklus, den man leicht unterschätzt, besonders wenn die ersten Demos beeindruckend aussehen.
Das Paradox ist: Je mehr Anleitung ein System braucht, desto sorgfältiger sollten wir fragen, wo echtes Feedback überhaupt in das System gelangt. Wer merkt, dass etwas schiefgelaufen ist? Wie schnell beeinflusst diese Information die nächste Entscheidung? Und wie teuer ist die Korrektur, wenn ein Fehler durchrutscht?
Bevor man KI einführt, lohnt es sich, explizit zu machen, was man eigentlich erreichen will. Führst du ein Experiment durch, um einen Problemraum zu erkunden und Erkenntnisse zu gewinnen? Oder versuchst du, einen bestehenden Workflow zu beschleunigen, der bereits einigermaßen gut funktioniert?
Beides sind legitime Ziele, aber sie haben sehr unterschiedliche Ökonomik. In experimentellen Settings sind langsame und teure Feedback-Schleifen oft akzeptabel, weil Lernen selbst das Ziel ist. In operativen Workflows hingegen können genau diese Schleifen die versprochenen Effizienzgewinne still und leise auffressen.
In vielen Fällen reduziert KI die Kosten der Arbeit nicht. Sie verschiebt sie. Und wenn der umgebende Work–Feedback-Loop nicht bewusst gestaltet und gemessen wird, macht diese Verschiebung Arbeit oft teurer, lange bevor sie irgendwann günstiger wird.
KI – oder präziser: LLMs – hat sich etabliert. Alle nutzen sie. Manche gut, manche weniger gut. Aber darum soll es hier nicht gehen. Mir geht es um die ökonomische Seite des KI-Einsatzes.
\nDie OpenAIs dieser Welt haben es seit 2022 geschafft, die Tokenpreise niedrig zu halten (grob in der Größenordnung von $2–$10 pro 1 Million Tokens, je nach Modell). Dadurch waren die Kosten für viele Anwendungsfälle praktisch zu vernachlässigen.
\nIch glaube, das wird sich 2026 ändern. Zeit, sich die Auswirkungen anzusehen.
\nWir werden einen Mix aus Pay-per-Token und Volumenverträgen sehen. Und in diesem Mix werden Kosten relevant werden – so relevant, dass sie Entscheidungen erzwingen. Das ist gut, weil sich der Diskurs verschiebt: weg von „KI kann alles“ hin zu „Lohnt sich dieser KI-Einsatz für uns?“. Erst dann entsteht eine Feedback-Loop.
\nSobald KI Geld kostet, werden Nutzungsmuster sichtbar – und bewertbar.
\nDas Schöne ist: Diese Situation kennen wir bereits. Ich nehme ein anderes Beispiel, um den Punkt klar zu machen: Meetings.
\nMeetings haben geringe Einzelkosten. Die Frequenz ist hoch. Und oft fehlt ein Feedback auf Wirkung. Genau deshalb werden Meetings selten konsequent hinterfragt.
\nWarum ist das so? Meetings vermitteln Aktivität. Koordination fühlt sich nach Arbeit an – und damit nach Wert. Aber nüchtern betrachtet ist ein Meeting nicht automatisch wertvoll.
\nBei KI ist es ähnlich. Jeder einzelne Prompt ist schnell geschrieben. Und die Antworten von LLMs sind so gestaltet, dass sie häufig ein Gefühl von Erfolg und Fortschritt erzeugen. Wir haben den Eindruck, produktiv zu sein.
\nVerschwendung entsteht selten durch große Fehlentscheidungen, sondern durch oft wiederholte, kaum überprüfte Mikro-Kosten.
\nIn jeder Tätigkeit – groß oder klein – steckt eine Work-Feedback-Loop. Ohne Feedback haben wir zwar Arbeit geleistet, wissen aber nicht, ob sie sinnvoll war.
\nBeim Einsatz von KI sehen wir typische Fälle, denen genau dieser Feedback-Teil fehlt:
\nWichtig: Output ist nicht gleich Wirkung. Daran sieht man: KI verstärkt Systeme – sie korrigiert sie nicht.
\nWenn man das präziser formuliert: Tokens erzeugen keinen Wert.
\nWert entsteht erst, wenn eine Entscheidung getroffen wird oder sich ein Systemzustand ändert. Passiert das nicht, sind Tokens eine Kostenstelle ohne Wertschöpfung. Und das passiert oft – gerade weil KI so leicht verfügbar ist. Wir unterliegen der Fehlannahme, dass mehr Information automatisch zu besseren Ergebnissen führt.
\nWert entsteht nicht durch Wissen, sondern durch wirksame Entscheidungen.
\nEs gibt noch eine weitere Ebene: Psychologie.
\nKI wird auch aus psychologischen Gründen gern eingesetzt. Neben dem Mechanismus, dass LLMs häufig Zustimmung und „Fortschrittsgefühl“ liefern, treten Motive wie Kontrolle, Modernität und das Gefühl von Momentum in den Vordergrund. Diese Rückkopplungen kennen wir bereits: Status-Meetings, Dashboards oder agile Rituale – ebenfalls oft ohne echte Wirkung.
\nZu häufig geht es um narrative Arbeit statt Systemarbeit. Viele KI-Anwendungen kaufen Beruhigung, nicht Flow.
\nWas passiert, wenn die Kosten steigen? In dem Moment wird Verschwendung messbar: Wie viele Tokens brauchten wir für diese Ticketbeschreibung? Wie viele für diese Meeting-Zusammenfassung? Wie viele für diese Entscheidung?
\nDann stellt man schnell fest: Unter Budgetdruck fällt die Bewertung des KI-Einsatzes anders aus. Das Flow-Problem – KI als Aktivitätsgenerator ohne Wirkung – war vorher schon da. Durch relevante Kosten wird es nur unübersehbar.
\nÖkonomie diszipliniert nicht – sie entlarvt.
\nWas bedeutet das? Teams müssen klar unterscheiden zwischen Arbeit, die Systeme bewegt, und Arbeit, die Systeme nur beschreibt. Beim KI-Einsatz wird die zentrale Frage lauter werden: Wird unsere Entscheidung dadurch besser oder schneller – oder nur besser begründet?
\nDas ist keine Tool-Frage. Das ist eine Systemfrage.
\nKI zwingt Teams, sich mit Wirkung auseinanderzusetzen – nicht mit Effizienz.
\nKI zerstört keine schlechten Systeme. Sie macht ihre Kosten sichtbar. Wer vorher keinen Flow hatte, bekommt jetzt eine Rechnung.
\nNicht KI wird Unternehmen verändern, sondern die Klarheit darüber, wofür sie Geld verbrennen.
", "image": "https://no-bullshit-agile.de/media/posts/180/ki-verschwendung-2.png", "author": { "name": "Thomas" }, "tags": [ "Grundlagen" ], "date_published": "2026-01-12T17:52:48+01:00", "date_modified": "2026-01-16T16:47:11+01:00" }, { "id": "https://no-bullshit-agile.de/feedback-kommt-zu-spaet.html", "url": "https://no-bullshit-agile.de/feedback-kommt-zu-spaet.html", "title": "Dein Team ist nicht langsam. Euer Feedback kommt nur zu spät.", "summary": "Wenn Software-Teams „langsam“ wirken, liegt das fast nie an der Umsetzungsgeschwindigkeit. Es liegt daran, dass Feedback Wochen oder Monate später kommt – wenn Lernen teuer oder unmöglich geworden ist. Wenn ein Feature Monate bis zum Release braucht, und wir kurz vor Go-Live Überraschungen erleben, gegensteuern müssen oder Releases verschieben bzw.", "content_html": "Wenn Software-Teams „langsam“ wirken, liegt das fast nie an der Umsetzungsgeschwindigkeit. Es liegt daran, dass Feedback Wochen oder Monate später kommt – wenn Lernen teuer oder unmöglich geworden ist.
\nWenn ein Feature Monate bis zum Release braucht, und wir kurz vor Go-Live Überraschungen erleben, gegensteuern müssen oder Releases verschieben bzw. nacharbeiten, ist das Kind in den Brunnen gefallen. Wenn wir erst dann darüber diskutieren ob wir \"das richtige\" gemacht haben, haben wir ein Problem.
\nDie Ursache dafür ist in der Regel, dass das Feature zu groß war, dass Teams Releases als Event und nicht als Routine verstehen und dass das Feedback als ein Event am Ende eines Release verstanden wird.
\nGenau das ist der Denkfehler. Feedback gehört nicht an das Ende - es ist Bestandteil des Zyklus Work-Feedback. Und dieser Zyklus muss klein sein.
\nWenn wir Feedback ans Ende stellen, haben wir keine Möglichkeit zu lernen und gegenzusteuern. Wir spekulieren. Und das ist teuer.
\nDas hat auch nichts mit Disziplin, Mindset oder Motivation zu tun. Es ist ein systemisches Missverständnis darüber, wie agiles Arbeiten funktionieren muss.
\nDie Auswirkungen sind hart aber logisch. Kein Learning. Aktivität wird mit Fortschritt verwechselt. Wer so arbeitet, ist nicht langsam. Er lernt nur zu spät.
\nArbeit ist ein Zyklus. Work → Feedback → Anpassung. Alles, was diesen Zyklus verlängert, erhöht das Risiko.
\nWenn wir nicht in der Lage sind, das zu akzeptieren, vergeben wir unser Potential. Wir haben genug Maßnahmen dafür in unserem Baukasten. Was fehlt ist, die klare Sicht auf diesen Baukasten und der Mut, ihn anzuwenden, auch wenn es weh tut.
\nEs braucht keine neuen Tools, Methoden oder Rollen dafür. Es braucht die Anerkennung, dass der Zyklus Work-Feedback der Kern ist und es braucht den Mut, Maßnahmen aus dem Baukasten umzusetzen.
\n\n\nWenn ihr eure Arbeit nicht releasen könnt, um etwas zu lernen, arbeitet ihr nicht agil – egal wie eure Meetings heißen.
\n
Wenn ihr wissen wollt, wie spät ihr wirklich lernt, beantwortet euch ehrlich diese Fragen.
\nWenn du mehr über den Zyklus Work-Feedback erfahren willst, schau in meinen Artikel Der einzige Kreislauf, der wirklich zählt.
Teams werden nicht langsam, weil sie schlecht arbeiten. Sie werden langsam, weil sie zu spät lernen.