Agile Reflection

Neulich, in einem Team, das ich begleite. Montagmorgen, Daily. Der Teamleiter verkündet beiläufig: „Übrigens, ab nächster Woche erfassen wir alle Tasks zusätzlich in einem zweiten Tool. Ist so beschlossen.“

Stille. Dann ein vorsichtiges „Warum?“ aus der hinteren Reihe. Der Teamleiter zuckt mit den Schultern. „Kam von oben.“

Ich kenne diesen Moment. Du vielleicht auch. Es ist der Moment, in dem eine Entscheidung im Raum steht, die keinen Sinn ergibt, und niemand sagen kann, wo sie herkommt. Als Coach habe ich in solchen Momenten zwei Reflexe: den Kopf schütteln und Detektiv spielen. Ich habe mich fürs Detektivspielen entschieden.

Ermittlungen

Tatort: ein Quartalsplanungsmeeting, drei Wochen früher. Ich habe nachgefragt, rekonstruiert, mit Leuten gesprochen. Und nach und nach tauchte ein Bild auf, das so absurd war, dass es schon wieder logisch wurde.

Da war ein Bereichsleiter, der sich seit Monaten darüber ärgerte, dass er „nie weiss, woran die Teams gerade arbeiten“. Ein echtes Problem, wenn auch eines, das mit dem Daily des Teams herzlich wenig zu tun hatte. Er trug es seit Wochen mit sich herum.

Da war ein Tool, das ein Anbieter ein paar Tage zuvor in einer Demo vorgeführt hatte. Hübsche Dashboards, viel Grün. Jemand hatte begeistert davon erzählt. Die Lösung lag also schon im Raum, bevor irgendwer eine Frage gestellt hatte.

Da war ein Budgetfenster, das Ende Quartal schloss. Wer bis dahin nichts beantragt, hat im nächsten Jahr nichts.

Und da war eine Handvoll Leute, die zufällig an diesem Dienstagnachmittag Zeit hatten. Die zwei, die das Team wirklich kannten, waren im Urlaub, beziehungsweise in einem anderen Meeting.

Problem, Lösung, Entscheidungsgelegenheit, Teilnehmer. Alle vier im selben Raum, zur selben Zeit. Man muss kein Genie sein, um zu sehen, was passiert ist: Das Problem fand die Lösung. Nicht weil sie zusammenpassten, sondern weil beide gerade da waren und die Zeit drängte. Entscheidung getroffen, Protokoll geschrieben, Haken dran.

Der Mülleimer hat einen Namen

1972 haben die Organisationsforscher Michael Cohen, James March und Johan Olsen genau dieses Phänomen beschrieben, in einem Aufsatz mit dem schönen Titel „A Garbage Can Model of Organizational Choice“. Ihre Beobachtung: In vielen Organisationen laufen Probleme, Lösungen, Teilnehmer und Entscheidungsgelegenheiten als vier weitgehend unabhängige Ströme nebeneinander her. Wie in einen Mülleimer wirft man alles hinein, und was am Ende als Entscheidung herauskommt, hängt stark davon ab, was gerade zufällig gemeinsam im Eimer lag.

Besonders anfällig sind laut den Autoren sogenannte „organisierte Anarchien“: Organisationen mit unklaren Zielen, unklaren Ursache-Wirkungs-Zusammenhängen und wechselnder Beteiligung. Wenn du jetzt an Universitäten denkst, liegst du richtig. Wenn du an deinen letzten Arbeitgeber denkst, auch.

Das Beruhigende daran: Es liegt nicht an dir und auch nicht an den Menschen im Raum. Es ist ein strukturelles Phänomen. Das Beunruhigende: Es passiert ständig.

Wo der Planungshorizont ins Spiel kommt

Hier schliesst sich der Kreis zu etwas, über das ich vor Kurzem geschrieben habe: dem Planungshorizont. Ich habe damals gesagt, dass jedes Meeting einen Planungshorizont haben sollte, und dass viele Meetings aus der Flughöhe geraten, weil niemand fragt, für welchen Zeitraum hier eigentlich geplant wird.

Der Garbage Can liefert die Erklärung dazu, warum das so oft schiefgeht. Eine Entscheidungsgelegenheit ohne klaren Horizont ist wie ein offener Eimer: Alles, was gerade herumliegt, darf hinein. Ein Daily, das zum Reporting wird, ist ein Eimer, in den der Bereichsleiter sein Informationsbedürfnis wirft. Ein Quartalsmeeting ohne Fokus ist ein Eimer, in den der Tool-Anbieter seine Demo wirft. Und weil niemand den Rand des Eimers definiert hat, landet am Ende alles drin.

Man könnte sagen: Teds Büro hatte immerhin ein Poster an der Wand. Viele Meetingräume haben nicht mal das.

Was du als Coach, Scrum Master oder Teamleiterin tun kannst

Gegen den Mülleimer hilft kein Pamphlet und kein weiteres Framework. Es hilft, ihn sichtbar zu machen. Drei Fragen, die ich inzwischen fast reflexartig stelle, wenn eine Entscheidung rätselhaft wirkt:

Welches Problem löst das genau, und wer hat es? Wenn die Antwort lange dauert oder bei jemandem landet, der nicht im Raum war, ist der Eimer verdächtig.

Wann und wo wurde das entschieden, und wer war dabei? Sehr oft erklärt die Teilnehmerliste mehr als jede Strategie.

Gibt es dieses Problem überhaupt noch? Manche Lösungen überleben ihr Problem um Jahre.

Und ein kleiner Trick zum Schluss: Wenn du selbst eine Entscheidungsgelegenheit organisierst, lege zuerst den Rand des Eimers fest. Worüber entscheiden wir heute, für welchen Zeitraum, mit wem? Was nicht dazu passt, darf draussen bleiben, auch wenn es gerade sehr verlockend herumliegt.

Die Auflösung

Zurück zu meinem Team. Ich habe die Geschichte rekonstruiert und beim nächsten Daily kurz erzählt, ohne Schuldzuweisung. Es wurde viel gelacht, und dann ein bisschen still. Am Ende haben wir gemeinsam die Frage geklärt, die hinter der Entscheidung stand: Wie kann der Bereichsleiter erfahren, woran die Teams arbeiten, ohne dass jeder Task doppelt erfasst wird?

Die Antwort war ein kurzes, wöchentliches Update auf Sprintziel-Ebene. Fünf Minuten statt fünfzig Tickets. Das zweite Tool bekam keinen Zuschlag, und das Dashboard-Grün muss der Anbieter anderswo verkaufen.

Das war keine Revolution. Nur ein Eimer, in den diesmal jemand reingeschaut hat, bevor er geleert wurde.

---

Hinweis: Die Geschichte ist eine verdichtete, anonymisierte Zusammenstellung typischer Situationen aus der Beratungspraxis.

Quelle

• Cohen, M. D., March, J. G., & Olsen, J. P. (1972). A Garbage Can Model of Organizational Choice. Administrative Science Quarterly, 17(1), 1–25. https://doi.org/10.2307/2392088

Stell dir vor, wir sitzen im gemütlichen Chalet. Das Fondue blubbert im Caquelon, wir rühren andächtig in der perfekten Käsemischung und klopfen uns gegenseitig auf die Schultern: Endlich haben wir das agile Mantra gemeistert! Entspannt diskutieren wir darüber, in welche Lohnklasse der neue „Release Train Engineer“ aus dem SAFe-Framework gehört und wie wir unsere komplexe Matrix-Organisation noch ein bisschen harmonischer gestalten. Es ist warm, es ist sicher, wir haben den agilen Wandel geschafft.

Was wir beim gemütlichen Rühren im Käse völlig übersehen: Draussen vor der Tür steht bereits der nächste gewaltige Change und ist kurz davor, uns die Chalet-Tür mitsamt Rahmen aus den Angeln zu heben.

Während wir in Europa noch unsere agilen Rollen von gestern polieren, passiert im Silicon Valley gerade ein tektonischer Shift in der Arbeitswelt. Dort explodieren Jobtitel, bei denen unsere klassischen HR-Abteilungen Schnappatmung bekommen, weil sie in keine bestehende Schublade passen. Wer glaubt, die KI-Revolution meistern zu können, indem er einfach ein paar Copilot-Lizenzen verteilt und ansonsten im gemütlichen Setup von 2018 weiterrührt, wird bald ein böses Erwachen haben. Es braucht radikal neue Macher. Konkret: Zwei neue Rollen, die das absolute Bindeglied zwischen abstrakten KI-Modellen und der harten Unternehmenspraxis bilden.

Die neuen Stars im Organigramm

Schauen wir uns an, was in den USA gerade passiert und unweigerlich auf uns zurollt:

1. Der Forward Deployed Engineer (FDE) Vergiss den Klischee-Coder im stillen Kämmerlein. Stellenausschreibungen für „Forward Deployed Engineers“ sind im Jahresvergleich um fast 1’200 % durch die Decke gegangen. Was früher eine Nische bei KI-Pionieren wie Anthropic war, ist heute ein massiver Hebel. Ein FDE sitzt direkt an der Front beim Kunden (oder der internen Fachabteilung) und verschmilzt technische Produktentwicklung mit knallharter Beratung. Warum ist diese Rolle so zentral? Weil KI-Lösungen nicht mehr als Standard-Software „von der Stange“ funktionieren. Sie müssen tief in die spezifischen Prozesse eines Unternehmens reingebaut werden. Mittlerweile suchen grosse Beratungshäuser wie Deloitte, BCG oder Accenture massiv nach genau diesem Profil.

2. Der Context Engineer Erinnerst du dich an den kurzen Hype um den „Prompt Engineer“? Das war gestern. Die neue Kernrolle heisst Context Engineer. Top-Tech-Firmen wie Adobe suchen diese Leute aktuell händeringend für den Aufbau ihrer internen Intelligenz. Was machen die? Sie bauen quasi das Firmen-Gedächtnis für die KI. Ein Sprachmodell ist nur so gut wie der Kontext, den es bekommt. Der Context Engineer sorgt dafür, dass das Modell euer implizites Unternehmenswissen, eure Kultur und eure Datenstrukturen systematisch versteht – ohne dass ein User jedes Mal einen Roman an Instruktionen in den Chat tippen muss. Gartner bezeichnet dieses „Context Engineering“ bereits als absolute Kernkompetenz der Zukunft.

Sind unsere Organisationen bereit dafür?

Sehen wir das schon in Europa? Höchstens in homöopathischen Dosen. Wir hinken wie so oft ein bis zwei Jahre hinterher. Aber der Druck steigt gewaltig.

Warum es essenziell ist, sich jetzt dazu Gedanken zu machen: Diese neuen Rollen brechen alte Silos auf. Sie vereinen Fachwissen, technisches Verständnis und Change Management in einer Person. Wenn du dir heute keine Gedanken machst, wie du diese Schnittstellenkompetenzen in dein Unternehmen holst, bauen andere Firmen mit kleinen, hyper-effizienten „AI-native“ Teams agile Strukturen auf, die deine altgedienten, hochkomplexen Hierarchien mühelos an die Wand spielen. Wir müssen aufhören, die Vergangenheit zu optimieren und anfangen, die Arbeitswelt von morgen zu designen.

Call to Action: Zeit für den Realitätscheck

Schau dir euer Organigramm von heute an. Wie viele Leute arbeiten aktiv daran, die Brücke zwischen euren Daten, den neuen KI-Möglichkeiten und euren Mitarbeitenden zu bauen? Und wie viele verwalten primär Meetings, Tickets und bestehende Prozesse?

Es ist Zeit, die Chalet-Tür aufzumachen und die Diskussion über Lohnbänder für agile Retro-Manager zu beenden.

Wie sieht das bei euch aus? Diskutiert ihr schon über diese neuen Jobprofile oder klebt ihr noch an alten Strukturen? Lass uns in den Kommentaren diskutieren oder schreib mir direkt eine Nachricht – es ist Zeit für ein echtes Organisations-Update!

Quellen & Lesestoff (für alle, die es genau wissen wollen):

• Forward Deployed Engineer:
  • Recruiting-Analysen zu FDE-Hiring-Trends (2025/2026): Paraform: FDE demand quadrupled, Perspective AI, HeroHunt AI
• Context Engineer:
  • Gartner (Frühjahr 2026): Context Engineering als Kernkompetenz
  • Aktuelle Ausschreibungen (z.B. Adobe, April 2026): AI Context Engineer Roles

Ich bin als Coach in vielen Organisationen unterwegs, und wenn man das lange genug macht, fängt man an, Muster zu sehen, ob man will oder nicht. Manche davon sind langweilig, weil sie in jedem Buch stehen. Dieses hier steht in keinem, und deshalb schreibe ich es auf.

Wenn in einer grösseren Organisation etwas hakt, gibt es einen Reflex: Es liegt an der Führung. Genauer, an der mittleren Führung, der berühmten Lehmschicht, die alles aufsaugt und nichts durchlässt. Ich habe diese Diagnose selbst oft genug gestellt. Aber in den letzten Jahren sehe ich etwas anderes, und zwar in Firmen, die sonst wenig gemeinsam haben: Versicherer, Bahnen, Verwaltungen, Maschinenbauer. Der Ärger sitzt nicht in der Führung. Er sitzt in der Koordination.

Konkret: in der Ebene, auf der zehn, zwölf, manchmal fünfzehn Teams gemeinsam etwas liefern sollen. In SAFe heisst diese Ebene Agile Release Train, und weil SAFe im deutschsprachigen Raum das mit Abstand verbreitetste Skalierungsmodell ist, sehe ich sie meistens in dieser Form. Aber ich will gleich zu Beginn sagen: Das ist kein SAFe-Text. Organisationen mit LeSS, mit selbstgebauter Skalierung oder mit gar keinem Modell haben dasselbe Problem, sie haben nur keinen Namen dafür. SAFe hat immerhin einen Namen. Das ist schon mal etwas.

Was ich sehe

Die Szenen ähneln sich so sehr, dass ich inzwischen nach der ersten Stunde in einer neuen Organisation ungefähr weiss, was kommt.

Da ist das Program Board. Zwei Tage lang wurde es im PI Planning mit roten Fäden bespannt, jede Abhängigkeit sauber eingetragen, und alle waren ein bisschen stolz. Drei Wochen später hängt es noch da, aber niemand hat es mehr angefasst. Die Fäden sind noch dieselben, die Realität nicht mehr.

Da ist die Kennzahl, die niemand deuten kann. Der Train meldet eine Predictability von 74 Prozent. Der Business Owner fragt, ob das gut ist. Der RTE sagt, es sei besser als letztes Mal. Ob 74 Prozent Zusagen-Erfüllung ein Erfolg oder ein Alarmsignal ist, kann in dem Raum niemand sagen, und das Erstaunliche ist: Es stört auch niemanden.

Da ist die Durchlaufzeit, die keiner kennt. Ich frage, wie lange es dauert, bis aus einer Feature-Idee ein Release wird. Erst Schweigen, dann Schätzungen, die zwischen „ein PI“ und „kommt drauf an“ liegen. Wenn wir dann gemeinsam nachrechnen, landen wir bei zwei, drei, manchmal vier Planungszyklen. Für ein Feature. Das ist keine Durchlaufzeit, das ist eine Verharzung.

Da ist das Inspect & Adapt, bei dem zum dritten Mal dieselbe Ursache auf dem Flipchart steht. Zu viele Abhängigkeiten zu Team X. Jedes Mal wird eine Massnahme beschlossen, jedes Mal ist beim nächsten Mal dieselbe Ursache wieder da. Nicht, weil die Leute faul wären, sondern weil niemand das Mandat hat, an der Struktur etwas zu ändern.

Und da ist der RTE. Meist eine der fähigsten Personen im Raum, verantwortlich für den Fluss von zwölf Teams, und wenn ich frage, ob er Arbeit ablehnen oder stoppen darf, kommt ein Lächeln, das ich inzwischen gut kenne. Servant Leader, sagt das Framework. Was in der Praxis heisst: Verantwortung ja, Entscheidungsbefugnis nein.

Dazu kommen die kleineren Dinge. Zweihundert offene Features in einem Train mit Kapazität für vierzig. Abhängigkeiten, die drei Planungszyklen lang mitgeschleppt werden, weil sie in jedem Zyklus knapp nicht Priorität haben. Prioritäten, die vom Portfolio kommen wie eine Wunschliste, ohne dass je Kapazität zurückgemeldet wird. Sync-Meetings, in denen Status ausgetauscht, aber nichts entschieden wird.

Nichts davon ist ein Führungsproblem im klassischen Sinn. Die Leute wollen. Sie haben nur kein Instrument.

Ist das Zufall?

Ich war lange unsicher, ob ich da ein echtes Muster sehe oder nur meine eigene Brille. Also habe ich nachgelesen. Es gibt inzwischen erstaunlich viel Forschung zu skalierter Produktentwicklung, und sie ist deutlicher, als ich erwartet hatte.

Eine Gruppe um Maria Paasivaara hat eine grosse Finanzorganisation mit vier Release Trains über Jahre begleitet. Ihr zentraler Befund: Die schwierigste Aufgabe war, die Trains an den tatsächlichen Wertströmen auszurichten. Wo das nicht gelang, entstanden Abhängigkeiten zwischen den Trains und ein Koordinationsaufwand, der die Beweglichkeit auffrass. Das Value-Stream-Mapping, das geholfen hätte, wurde nicht gemacht. Grund: interne Machtpolitik.

Zwei Forscher vom Fraunhofer IESE haben das Framework selbst analysiert und einen Satz geschrieben, den ich seither oft zitiere: SAFe schreibt vor, wann synchronisiert wird, sagt aber nichts darüber, wie die Arbeit, die an den Schnittstellen geteilt wird, gemanagt werden soll. Anders gesagt: Es gibt eine Kadenz, aber keinen Fluss.

Und dann gibt es Stimmen aus dem Framework selbst, die ich fairerweise ernster nehme als die üblichen Kritiker. Ein SAFe Fellow schreibt über das Program Board: Zu viele rote Fäden heissen zu viele Abhängigkeiten, und zu viele Abhängigkeiten heissen, dass das Netzwerk falsch konfiguriert ist. Ein Autor auf der offiziellen Scaled-Agile-Seite sagt, nach seiner Erfahrung seien die Iterationspläne aus dem PI Planning etwa zu 60 Prozent genau. Das ist keine Messung, das ist eine Erfahrungsaussage, aber sie kommt aus dem Haus, das das Ritual verkauft.

Damit das nicht zu einseitig wird: Eine Studie mit über viertausend Teams hat 2024 gezeigt, dass es für die Effektivität der Teams praktisch keine Rolle spielt, welches Skalierungsmodell die Organisation nutzt. Die Teams sind unter SAFe nicht schlechter als unter irgendetwas anderem. Ich glaube das sofort. Es bestätigt nur, was ich sehe: Das Problem liegt nicht in den Teams. Es liegt dazwischen.

Die Frage, die mich nicht loslässt

Hier wird es für mich interessant. SAFe gibt es seit über zehn Jahren. Im deutschsprachigen Raum betreiben Dutzende grosser Organisationen Release Trains, manche zwei, manche über hundert. Es gibt Zertifizierungen, Konferenzen, Berichte, Erfolgsgeschichten.

Und es gibt keine einzige öffentliche Zahl darüber, wie diese Koordinationsebene tatsächlich performt.

Keine Verteilung der Zusagen-Erfüllung über echte Trains. Keine Durchlaufzeiten von Feature-Idee bis Release. Keine Zahl dazu, wie viele Abhängigkeiten pro Zyklus entstehen und wie viele davon aufgelöst werden. Nichts über die Belastung der Rolle, die das alles tragen soll. Der Hersteller publiziert einen Zielkorridor (80 bis 100 Prozent Predictability gelten als „verlässlich“), aber keine Ist-Werte. Die Forschung hat Fallstudien, aber keine Messreihen. Und die Firmen selbst messen es entweder nicht oder behalten es für sich.

Ich finde das bemerkenswert. Wir haben eine Ebene, auf der die meiste Koordination stattfindet, auf der die meiste Zeit verloren geht, und über die niemand Zahlen hat. Wenn das in einem Produktionsbetrieb so wäre, würde man von einem blinden Fleck sprechen. Ich nenne es deshalb auch so.

Was man tun könnte

Ich habe keine fertige Antwort, aber ich habe eine Vermutung, und die kommt aus einer Ecke, die mit SAFe nichts zu tun hat.

Klaus Leopold hat vor Jahren beschrieben, dass Organisationen auf drei Höhen fliegen: die Teams unten, die Strategie oben, und dazwischen die Ebene, auf der Ende-zu-Ende koordiniert wird. Er nennt sie Flight Level 2. Sein Punkt war damals schon: Die meisten Organisationen optimieren Teams und wundern sich, dass die Organisation nicht schneller wird. Eine Organisation ist mehr als die Summe ihrer Teams. Ich will nicht, dass gearbeitet wird, sagt er, ich will, dass geliefert wird.

Das ist genau die Ebene, um die es hier geht. Und für diese Ebene gibt es Werkzeuge, die seit zwanzig Jahren funktionieren, nur werden sie fast nie dort eingesetzt: ein Board, das nicht die Teams zeigt, sondern den Fluss der Features durch den ganzen Train. WIP-Limits auf dieser Ebene, also die Entscheidung, dass nicht zweihundert Features gleichzeitig offen sein dürfen. Explizite Regeln, was mit einer Abhängigkeit passiert, wenn sie entsteht, statt sie nur auf ein Board zu pinnen. Und die schlichte, fast peinliche Übung, die Durchlaufzeit zu messen.

Und dann gibt es eine Idee aus dem Lean-Werkzeugkasten, die älter ist als jedes Skalierungsframework und die ich auf dieser Ebene fast nie sehe: der Obeya. Ein Raum, physisch oder digital, in dem alles hängt, was für die Steuerung des Trains wichtig ist. Der Fluss, die Engpässe, die Abhängigkeiten, die Entscheidungen, die anstehen. Nicht als Reporting für oben, sondern als Arbeitsraum für die, die koordinieren. Wer einmal erlebt hat, wie sich ein Sync-Meeting verändert, wenn es vor einer Wand stattfindet, auf der der echte Zustand des Trains sichtbar ist, statt vor einer Jira-Filterliste, versteht, warum Toyota das seit Jahrzehnten macht.

Wenn ich im Bild bleibe, das mir bei diesen Organisationen immer kommt, einem Schiff mit zwölf Ruderbänken, auf denen alle kräftig rudern: Diesen Schiffen fehlen weder Ruderer noch ein Kapitän. Ihnen fehlt die Brücke. Der Ort, von dem aus man sieht, wohin das Schiff fährt und was ihm im Weg liegt. Das klingt banal. In jeder Organisation, in der ich es gesehen habe, war es das nicht.

Wo ich ehrlich sein muss

Ich schreibe das nicht ganz uneigennützig. Wir bei Wertwandler machen genau so etwas beruflich, und wer mir jetzt unterstellt, ich hätte ein Problem beschrieben, für das ich zufällig die Lösung verkaufe, hat nicht ganz unrecht. Ich würde nur sagen: Die Frage, warum nach zehn Jahren niemand diese Ebene misst, ist trotzdem berechtigt. Und sie ist mir wichtiger als die Antwort, die ich darauf habe.

Deshalb ein Vorschlag statt eines Angebots. Ich sammle solche Beobachtungen. Wenn du in einem Train arbeitest, als RTE, als Business Owner, als Product Owner, als jemand, der das Schiff finanziert, und du erkennst etwas von dem wieder, was hier steht, dann schreib mir. Und wenn du in einem Train arbeitest, bei dem es anders ist, bei dem das Board lebt, die Durchlaufzeit bekannt ist und der RTE Nein sagen darf: dann schreib mir erst recht. Das wäre die interessantere Geschichte.

Irgendwann, wenn genug zusammengekommen ist, gibt es Zahlen. Dann wissen wir, ob ich ein Muster gesehen habe oder nur meine Brille.

—

Quellen

1. Putta, A., Paasivaara, M., Lassenius, C. (2023/2024). SAFe transformation in a large financial corporation. Empirical Software Engineering 29. https://link.springer.com/article/10.1007/s10664-023-10420-w

2. Theobald, S., Schmitt, A. (2020). Dependencies of Agile Teams: An Analysis of the Scaled Agile Framework. XP 2020 Workshops. https://link.springer.com/chapter/10.1007/978-3-030-58858-8_22

3. Yeret, Y. (2020). SAFe Program Dependency Board Retrospective. https://yuvalyeret.medium.com/safe-program-dependency-board-retrospective-1c3f0aa0b080

4. Stroman, D. (2022). PI Planning: Plan to Discover. scaledagile.com. https://scaledagile.com/blog/pi-planning-plan-to-discover/

5. Verwijs, C., Russo, D. (2024). Do Agile scaling approaches make a difference? Empirical Software Engineering 29. https://arxiv.org/abs/2310.06599

6. Scaled Agile: ART Predictability Measure (Glossar). https://framework.scaledagile.com/blog/glossary_term/program-predictability-measure/

7. Leopold, K. (2018). Agilität neu denken. Interview: https://agile-unternehmen.de/klaus-leopold-agilitaet-neu-denken/

In den meisten Meetings, in denen geplant, refined, geklärt oder priorisiert wird, fehlt eine einzige, unscheinbare Frage: für welchen Zeitraum planen wir hier eigentlich gerade? Diese Frage wird selten gestellt, obwohl sie fast alles andere bestimmt — wer reden sollte, wie detailliert man werden darf, und ob das Meeting am Ende überhaupt dem Team dient oder nur dem Gefühl, dass etwas passiert ist.

Jedes Meeting hat einen Planungshorizont. Nicht jedes Team ist sich dessen bewusst, aber er ist trotzdem da, und wenn man ihn ignoriert, rutscht ein Meeting fast automatisch in die falsche Flughöhe ab. Am deutlichsten sieht man das im Daily.

Das Daily hat eine sehr kurze Reichweite

Der Planungshorizont eines Daily ist maximal eine Woche, meistens deutlich kürzer. Im Kern geht es darum, die nächsten ein bis drei Tage zu koordinieren: wer braucht was von wem, wo hakt es, wo lohnt sich ein kurzer Austausch, bevor jemand einen halben Tag in die falsche Richtung arbeitet.

In diesen Rahmen passen User Stories, weil sie das ganze Team betreffen — sie sind der gemeinsame Bezugspunkt, an dem sich koordinieren lässt, wer woran arbeitet und wo Abhängigkeiten liegen. Tasks und Subtasks passen grundsätzlich auch rein, aber mit einer wichtigen Einschränkung: sie sind persönliche Planungselemente. Sie müssen im Daily nicht zwingend besprochen werden — es sei denn, sie tragen tatsächlich zur Koordination bei, oder es geht darum, um Hilfe zu bitten, damit der Sprint gelingt. Ein Task ist grundsätzlich Privatsache der Person, die ihn bearbeitet. Er wird erst dann zum Thema fürs Team, wenn er ein Hindernis, eine Abhängigkeit oder einen Hilferuf enthält.

Wenn zu viele Tasks besprochen werden, ist das ein Warnsignal

Werden im Daily trotzdem regelmässig viele einzelne Tasks durchgegangen, ist das meistens kein Zeichen von Gründlichkeit, sondern ein Hinweis, dass sich das Meeting in etwas anderes verwandelt hat: ein Reporting. Ein Statusabgleich, bei dem alle der Reihe nach sagen, was sie gestern gemacht haben und heute machen werden, hilft dem Team nicht dabei, besser zu werden. Es hilft höchstens jemandem im Raum, den Überblick zu behalten — was ein legitimes Bedürfnis sein kann, aber nicht der Zweck eines Daily ist.

Als Scrum Master würde ich an diesem Punkt genauer hinschauen. Die eigentlich interessante Frage lautet dann nicht mehr „wie bringen wir das Daily wieder auf Kurs“, sondern: ist das hier überhaupt ein Team? Oder ist es eine Gruppe von Menschen mit demselben Organisationskürzel, die zufällig gemeinsam an denselben Tickets arbeiten, aber kein gemeinsames Sprintziel verfolgen, für das sie sich gegenseitig brauchen? Ein Reporting-Daily ist oft nicht das Problem, sondern das Symptom eines Teams, das strukturell noch keins ist.

Jede Planungsebene hat ihre eigene Reichweite

Zoomt man raus, zeichnet sich ein klares Muster ab, das weit über das Daily hinausgeht. Epics haben von Natur aus einen langen Planungshorizont, ungefähr ein Quartal — sie beschreiben eine Richtung, kein fixes Ergebnis in zwei Wochen. User Stories bewegen sich auf Sprintlänge, sie sind bewusst so geschnitten, dass ein Team sie in einem überschaubaren Zeitraum gemeinsam abschliessen kann. Tasks und alles darunter sind persönliche Arbeitsstrukturen mit sehr kurzer Lebensdauer — Tage, manchmal Stunden.

Das Problem entsteht immer dann, wenn eine Planungsebene mit dem Detailgrad oder der Reichweite einer anderen behandelt wird. Ein Epic, das wie eine User Story mikromanagt wird, erstickt in Detailplanung, die sich in einem Quartal ohnehin noch mehrfach ändert. Ein Task, der wie ein Epic dokumentiert wird, bindet Energie, die niemand je wieder abrufen wird.

Wo Dokumentationsenergie wirklich hingehört

Aus dieser Logik folgt fast von selbst, wie viel Aufwand welche Ebene verdient. In Epics lohnt es sich, ordentlich zu investieren — sie leben lange, mehrere Leute greifen im Lauf eines Quartals darauf zurück, und eine klare Beschreibung erspart später viele Rückfragen. In User Stories lohnt sich ein Stück weit Dokumentation, aber massvoll — genug, damit das Team weiss, was gemeint ist, nicht mehr. Alles, was kleiner ist als eine User Story, sollte man in der Regel einfach tun. Ein Task, der ausführlicher dokumentiert wird, als er dauert, ist meistens ein Zeichen dafür, dass irgendwo im System Vertrauen fehlt — nicht, dass mehr Dokumentation gebraucht wird.

Die eine Frage, die vieles klärt

Der Planungshorizont ist keine neue Methode und kein zusätzliches Ritual. Es ist eine einzige Frage, die sich vor jedem Meeting stellen lässt: für welchen Zeitraum planen wir hier gerade, und passt das, was gerade besprochen wird, wirklich in diesen Zeitraum? Diese Frage kostet nichts, aber sie sortiert fast automatisch aus, was in ein Daily gehört und was in ein Reporting, was in ein Refinement gehört und was in eine Grundsatzdiskussion, die eigentlich auf Epic-Ebene stattfinden sollte. Wer sie sich regelmässig stellt, muss deutlich seltener Meetings retten, die eigentlich nie hätten aus dem Ruder laufen dürfen.

Die meisten, die Ted Lasso schauen, sehen einen Coach. Netter Typ, backt Kuchen, sagt „Believe“, am Ende gewinnt die Freundlichkeit. Fertig ist die Assoziation, ab geht’s zum nächsten LinkedIn-Post darüber, wie man „wie Ted“ führt.

Das Problem: wer nur das sieht, verpasst den eigentlich interessanten Teil. Denn zwischen den Gags stecken in der Serie eine ganze Reihe fachlich sauber begründeter Coaching-Techniken — Dinge, die echte Sportpsycholog:innen und Coaching-Forscher:innen im Nachhinein auseinandergenommen haben, weil sie eben nicht nur Wohlfühlkitsch sind, sondern erstaunlich präzise abbilden, wie gute Führung tatsächlich funktioniert. Und ein paar Dinge, bei denen die Serie es sich zu einfach macht. Hier die Liste.

Das Poster hinter Beard, das niemand kommentiert

Im Büro hängt ein Poster mit dem Titel „Pyramid of Success“ — signiert. Die meisten Zuschauer:innen registrieren es nie bewusst, es läuft einfach als Hintergrunddeko durch. Dabei ist das kein erfundenes Serien-Prop, sondern das reale Erfolgsmodell von John Wooden, dem legendären UCLA-Basketballtrainer mit zehn nationalen Meistertiteln. Jason Sudeikis trug privat ein kleines Wooden-Zitatbüchlein mit sich herum und liess sich davon für die Figur inspirieren. Das Poster taucht schon in Folge 1 auf, eine Nahaufnahme gibt’s erst in Folge 8 — als würde die Serie testen, wer wirklich aufpasst.

„Be a goldfish“ ist kein Kalenderspruch

Ted erklärt seinen Spielern, der Goldfisch sei das glücklichste Tier der Welt, weil er nur ein Zehn-Sekunden-Gedächtnis habe. Klingt nach Küchenmagnet-Weisheit. Ist aber sauber verankerte Emotionsregulation: Gefühl kurz zulassen, nicht wegdrücken, dann bewusst loslassen und zurück in die Gegenwart. Genau das Gegenteil von Grübeln — und Grübeln ist einer der zuverlässigsten Leistungskiller, die es gibt, im Büro wie auf dem Platz. Der einzige Haken: Goldfische haben in Wirklichkeit gar kein Zehn-Sekunden-Gedächtnis. Und wie die Serie selbst später zeigt — bei Ted persönlich funktioniert die Technik irgendwann nicht mehr, weil er sie auch benutzt, um eigenen Problemen komplett auszuweichen. Auch das ist eine akkurate Warnung: Dieselbe Technik, die dich resilient macht, kann dich auch vor dir selbst verstecken.

Die Geister-Übung, die eigentlich eine Vertrauensübung ist

Staffel 1: das Team glaubt, die Behandlungskabine sei von einem Geist heimgesucht. Ted macht daraus ein Ritual — jeder bringt einen persönlich wichtigen Gegenstand mit und erzählt die Geschichte dahinter. Wirkt wie ein alberner Nebenplot. Ist strukturell aber eine waschechte Vulnerability-Übung, wie sie im Spitzensport zum Aufbau psychologischer Sicherheit eingesetzt wird. Genau in dieser Szene öffnet sich der bis dahin unnahbare Jamie zum ersten Mal — nicht zufällig, sondern weil die Übung genau dafür gebaut ist.

Warum Ted den Psychologen holt, obwohl er selbst dagegen ist

Als das Team eine Sportpsychologin ins Boot holen will, hat Ted sichtlich Bauchweh damit — er sagt es offen, er misstraut Therapeuten. Trotzdem gibt er grünes Licht. Das ist kein Zufall, sondern lehrbuchmässiges „autonomy-supportive coaching“ nach der Selbstbestimmungstheorie: Menschen brauchen das Gefühl von Autonomie, Kompetenz und Zugehörigkeit, um wirklich motiviert zu sein. Indem Ted seine eigenen Vorbehalte zurückstellt und dem Team die Entscheidung überlässt, sendet er eine klare Botschaft: eure Ideen zählen mehr als mein Ego. Das ist der Unterschied zwischen einem Chef, der zuhört, weil es gut aussieht, und einem, der tatsächlich Macht abgibt.

Die Schwäche, die Vertrauen aufbaut

Ted gibt von Anfang an unumwunden zu, dass er von Fussball keine Ahnung hat. Für eine Führungsperson eigentlich der grösste anzunehmende Fehler. Tatsächlich ist genau das gezielt eingesetzte Verletzlichkeit — und deckt sich mit einem der meistzitierten Vertrauensmodelle der Organisationsforschung: Vertrauen entsteht aus Fähigkeit, Wohlwollen und Integrität. Wer offen zugibt, was er nicht kann, signalisiert Integrität — und macht es dem Team leichter, ihre eigenen Lücken ebenfalls zuzugeben.

Und jetzt die Gegenrede

Nicht alles an der Serie hält der fachlichen Prüfung stand, und genau das macht sie interessanter als die reine Lobhudelei. Ein Sportpsychologe hat öffentlich kritisiert, dass Teds finale „vier Erfolgsschlüssel“ — Kondition, Vielseitigkeit, Wahrnehmung, Selbstglaube — beim vierten Punkt danebenliegen. Selbstglaube ist in der Leistungsforschung umstritten: man braucht ihn nicht zwingend, um gut zu performen, treffender wäre „psychologische Flexibilität“ gewesen. Und die Sportpsychologin der Serie, Dr. Sharon, arbeitet im Grunde durchgehend wie eine Therapeutin in einem Sprechzimmer — echte Sportpsycholog:innen verbringen den Grossteil ihrer Zeit auf dem Trainingsplatz oder in der Kabine, nicht am Schreibtisch.

Fazit

Die Serie feiert Freundlichkeit als Führungsqualität — das stimmt auch. Aber der eigentliche Grund, warum Ted Lasso als Coaching-Fallstudie funktioniert, ist nicht seine gute Laune. Es ist, dass fast jede seiner scheinbar spontanen, herzigen Gesten sauber auf echte Führungsforschung zurückgeführt werden kann. Wer beim nächsten Rewatch also nicht nur auf die Sprüche achtet, sondern auf das, was Ted tatsächlich tut, wenn’s unbequem wird, sieht eine ziemlich präzise Anleitung. Nicht perfekt. Aber besser recherchiert, als man einer Sitcom über einen ahnungslosen American-Football-Coach zutrauen würde.

---

Quellen

• John Wooden – Pyramid of Success (Ted Lasso Wiki)
• A ‚Lasso‘ Around John Wooden (UCLA Newsroom)
• Ted Lasso: What It Means To „Be A Goldfish“ (Screen Rant)
• 5 Things „Ted Lasso“ Got Right About Mental Health (Psychology Today)
• Ted Lasso: Coaching with Heart (SIRC)
• The art of vulnerability – Lessons on coaching with Ted Lasso (Balance is Better)
• Ted Lasso Sport Psychology (Condor Performance)

Anlass für diesen Text: die neue Staffel ist da. Und mit ihr, garantiert, die x-te Welle von „5 Leadership-Lessons von Ted Lasso“-Posts auf LinkedIn. Ted lächelt, Ted backt Biscuits, Ted glaubt an dich. Herzerwärmend. Auch komplett an der Serie vorbei. Zeit für ein paar andere Gedanken zu dieser Coaching-Serie.

Denn Ted Lasso ist keine Anleitung für gute Führung. Es ist eine Serie über Menschen, die ihre eigentlichen Probleme so lange mit guter Laune zukleistern, bis die Laune reisst. Das ist der Teil, den die Linkedin-Zitate immer weglassen. Und genau deshalb lohnt sich ein zweiter Blick — nicht auf Ted, sondern auf dich. Denn irgendeine dieser Figuren sitzt gerade in deinem Meeting. Möglicherweise bist du es.

Ted: der Chef, der so nett ist, dass ihm keiner widerspricht

Was alle sagen: bester Chef aller Zeiten, hört zu, glaubt an sein Team, Wachstumsmentalität in Person.

Was wirklich passiert: Ted witzelt sich durch jede unangenehme Situation, bis er buchstäblich in einer Besenkammer eine Panikattacke hat, weil er nie gelernt hat, ein Problem einfach ein Problem sein zu lassen. Seine Freundlichkeit ist keine Strategie, sie ist ein Fluchtweg.

Kennst du den Kollegen, der jedes Krisenmeeting mit einem Spruch eröffnet und den nie jemand nach seinem eigenen Befinden fragt, weil er selbst nie eine ernste Antwort zulässt? Frag dich: Ist bei dir „positive Kultur“ ein Ort, an dem Probleme gelöst werden — oder einer, an dem sie nur nicht mehr ausgesprochen werden dürfen?

Nate: der Übersehene, dem endlich einer zuhört

Was alle sagen: die traurige Verwandlung vom liebenswerten Underdog zum kleinen Tyrannen.

Was wirklich passiert: Nate wird nicht böse, weil er böse ist. Er wird böse, weil er jahrelang übergangen wurde und beim ersten bisschen Macht sofort dieselbe Härte weitergibt, die er selbst erlitten hat. Das ist keine Charakterschwäche, das ist ein Muster, das in jeder Organisation existiert, die Leute lange ignoriert und sie dann überraschend befördert.

Frag dich: Wer in deinem Team wurde jahrelang übergangen — und was genau erwartest du, dass mit dieser Person passiert, wenn sie plötzlich Verantwortung bekommt, ohne dass sich sonst etwas ändert?

Rebecca: die Chefin, deren Gründungsmotivation längst erledigt ist

Was alle sagen: starke Frau, tolle Entwicklung, übernimmt den Verein aus Rache an ihrem Ex und wird am Ende eine gute Chefin.

Was wirklich passiert: Sie bleibt, nachdem der Racheplan geplatzt ist, die Beziehung zum Ex Geschichte ist und der eigentliche Grund für den Job komplett verschwunden ist. Niemand in der Serie fragt sie, warum eigentlich noch.

Frag dich, ganz ohne Häme: Warum bist du eigentlich noch in deinem Job? Ist der Grund, aus dem du mal angefangen hast, noch derselbe — oder arbeitest du inzwischen aus reiner Trägheit für eine Entscheidung, die eine andere Version von dir getroffen hat?

Roy: der Einzige, der ehrlich flucht, während alle anderen lächeln

Was alle sagen: herrlich grummelig, harte Schale, weicher Kern, running gag mit den Kraftausdrücken.

Was wirklich passiert: Roy ist in einem Umfeld voller höflich verpackter Konflikte der Einzige, der Probleme beim Namen nennt, ohne sie in Wattebausch-Sprache zu wickeln. Er ist unbequem — und meistens der Erste, der recht hat. Sein Fluchen ist kein Temperamentsfehler, es ist die kürzeste Distanz zwischen Wahrnehmung und Aussage, die in diesem Team sonst niemand hinbekommt.

Wer im Meeting die unbequeme Wahrheit ausspricht, während alle anderen sie nur andeuten, wird meistens nicht als der Ehrliche wahrgenommen — sondern als der Schwierige. Falls du dich gerade ertappt fühlst: du bist wahrscheinlich nicht das Problem im Raum. Du bist nur der Einzige, der es benennt. Das macht dich nicht angenehmer in Meetings. Aber es erklärt, warum man dich trotzdem braucht.

Higgins: der Unsichtbare, der den Laden zusammenhält

Was alle sagen: netter Nebencharakter, sorgt fürs Comic Relief mit der Grossfamilie.

Was wirklich passiert: Higgins erledigt in der Verwaltung die eigentliche Arbeit, die den Betrieb am Laufen hält, während Rebecca und Ted die Bühne für sich haben. Er kriegt kaum Anerkennung — obwohl ohne ihn alles zusammenbricht.

Frag dich: Wer bei dir macht die Arbeit, ohne die nichts funktioniert, aber ohne die auch niemand jemals ein Dankeschön verteilt? Und: bist du derjenige, der diese Person mal fragt, wie es ihr geht?

Beard: der Senior, den keiner fragt, bis es zu spät ist

Was alle sagen: schrullig, mysteriös, running gag mit seiner wilden Nacht in Amsterdam.

Was wirklich passiert: Beard weiss fast immer mehr als alle anderen im Raum, wird aber selten aktiv nach seiner Meinung gefragt — er bringt sie nur ein, wenn es kurz vor knapp ist. Stilles, unterschätztes Senior-Wissen, das erst auffällt, wenn es fehlt.

Was bleibt

Die Serie feiert am Ende Empathie und Zusammenhalt — das stimmt. Aber ihre eigentliche, unbequemere Lektion ist eine andere: Freundlichkeit, die echte Konflikte vermeidet statt sie zu klären, ist keine Kultur. Sie ist nur ein netter verpackter Rückstau. Ted lernt das erst, als seine Vermeidung ihn körperlich einholt. Die Frage ist nicht, welcher Charakter am sympathischsten ist. Die Frage ist, welcher Charakter du bist, wenn es in deinem Team mal nicht um Fussball geht — und ob dir das eigentlich gefällt.

PS: Ich bin übrigens voll der Ted Fan, Ich denke es lohnt sich mal einen Blog zu schreiben mit allen den kleinen Coaching-Geheimnissen die in der Serie vorkommen aber keiner sieht sie. 🙂

Nicht jedes Gespräch gehört in jedes Meeting.

Du kennst das Meeting. Es beginnt auf Höhe. Es geht um die Richtung des nächsten Quartals, um den Wertstrom, um die Frage, was strategisch wirklich zählt. Zehn Minuten später sagt jemand: „Aber in der Story mit dem Login ist der Button auf der falschen Seite.“ Und plötzlich diskutiert der ganze Raum über einen Button. Das strategische Gespräch kommt nicht mehr zurück. Alle gehen leicht unzufrieden raus, ohne genau zu wissen, warum.

Was passiert ist: Ihr habt im Flug die Höhe gewechselt.

Drei Flughöhen, nicht drei Wichtigkeiten

Klaus Leopold hat mit den Flight Levels ein schönes Bild geprägt: Eine Organisation arbeitet auf verschiedenen Flughöhen, und es lohnt sich, Strategie und operative Koordination nicht in denselben Raum zu zwängen. Genau dieser Instinkt lässt sich auf die Arbeitsobjekte übertragen, die bei uns auf dem Tisch liegen.

Epics, User Stories und Tasks sind keine Rangliste von Wichtigkeit. Sie sind drei Flughöhen des Denkens. Und unser Kopf wechselt zwischen ihnen nicht gratis. Auf 10’000 Metern verschaffst du dir Überblick. Am Boden siehst du das Detail. Beides gleichzeitig geht schlecht – und genau das verlangen wir uns in vielen Meetings ab.

Epics – Reiseflughöhe

Wenn ihr über Epics sprecht, seid ihr in einem Koordinationsmeeting. Mehrere Teams, ein Wertstrom, eine strategische Komponente. Der Raum ist grösser, ihr plant und entscheidet gemeinsam, wohin die Reise geht. User Stories tauchen hier durchaus auf – aber als Beispiel, kurz, zur Illustration. Wenn ihr anfangt, eine einzelne Story im Detail auszugestalten, seid ihr zu tief abgesunken.

User Stories – die Arbeitshöhe deines Teams

Wenn ihr mit eurem Team das nächste Inkrement plant, sollten sich die Gespräche um User Stories drehen. Das ist die taktische, umsetzungsorientierte Ebene: Was liefern wir, und wie schneiden wir es sinnvoll?

Hier dreht das Epic seine Rolle um. Es wird zum Prüfstein: Liefern unsere Stories den strategischen Wert, den das Epic verspricht? Enthalten sie die Funktionalität, die dort gewünscht ist? Das Epic gibt die Richtung, die Stories tragen sie. Ein Task darf mal kurz aufblitzen – aber besser bleibt es dabei.

Tasks und Subtasks – Bodenhöhe

Und dann gibt es die Ebene, auf der du als Teammitglied überlegst, wie du deinen Beitrag zerlegst. Tasks, Subtasks, deine persönliche Art, dir die Arbeit zu ordnen. Das ist nützlich und oft nötig – aber es ist persönliche Arbeitsmethodik.

In dem Moment, in dem ein ganzes Team gemeinsam über einen Subtask diskutiert, seid ihr sehr im Detail. Wahrscheinlich ist das nicht die Flughöhe, für die man ein Meeting ansetzt. Dieses Gespräch ist häufig besser aufgehoben mit einer Kaffeetasse in der Hand vor dem Automaten – zu zweit, in zwei Minuten.

Der Check

Daraus wird kein Regelwerk. Es wird eine einzige Frage, die jeder im Raum laut stellen darf:

Auf welcher Flughöhe sind wir gerade – und ist das die, für die wir hier sitzen?

Keine Schiedsrichterpfeife, kein erhobener Zeigefinger. Nur ein leiser Stupser, der dem Raum erlaubt zu merken, dass er abgedriftet ist, und wieder zu steigen. Erstaunlich oft reicht das schon.

Und nein – das heisst nicht, dass in einem Planungsmeeting nie ein Task fallen darf. Das wäre nur das nächste Dogma. Es geht nicht um Disziplin um ihrer selbst willen. Es geht darum, jedem Gespräch die Höhe zu geben, auf der es wirklich wirkt. Strategie braucht Luft. Ein Detail braucht zwei Leute und einen Kaffee.

Wenn die Ebenen zusammenpassen, werden Meetings kürzer und besser zugleich. Und ehrlich – wer will das nicht?

Im Sommer 2025 hatte ich ein Problem, das man als Dozent eigentlich nicht haben sollte: Meine Prüfungen waren zu gut.

Ich unterrichte seit Jahren an der Berner Fachhochschule in Biel das Thema Requirements Engineering, eingebettet in ein CAS, rund fünfundzwanzig Lektionen. Vor mir sitzen meist angehende oder gestandene Führungskräfte, die künftig IT-Projekte verantworten oder darin eine Rolle spielen – und die wissen wollen, wie Software eigentlich entsteht. Anspruchsvolle, neugierige Menschen. Genau die Klassen, auf die man sich freut.

Und das Fach selbst war über Jahre ein Geschenk. Requirements ist anfassbar. Jedes Beispiel lebt, jedes Missverständnis zwischen Auftraggeber und Entwicklung lässt sich greifen, jeder schlecht formulierte Anspruch rächt sich sichtbar. Man kann als Dozent kaum etwas falsch machen, weil der Stoff so dankbar ist.

Meine Prüfungen waren immer Open Book. 2024 durften die Teilnehmenden zum ersten Mal auch KI nutzen. Im Jahr darauf waren die Ergebnisse dann so stark, dass ich mich hinsetzen und mir eine unbequeme Frage stellen musste: Wenn jeder mit dem richtigen Werkzeug glänzt – was bringe ich diesen Menschen eigentlich noch bei? Und vor allem: Welche Rolle spielt Requirements in einer Welt, in der die Maschine mitschreibt, mitdenkt, mitformuliert?

Ich habe das Konzept radikal umgeschrieben

Dieses Jahr habe ich den Kurs zum ersten Mal anders aufgebaut. Statt zu dozieren, gebe ich einen Impuls. Ich formuliere ein Beispiel, ein Problem, eine Spannung – und übergebe. Die Teilnehmenden ergründen das Thema in kleinen Gruppen, lösen es, und erarbeiten sich die nötige Methodik gleich mit. Sie lernen nicht zuerst die Theorie, um sie dann irgendwann anzuwenden. Sie brauchen sie, also holen sie sie sich.

Schon am ersten Tag haben sie nicht nur das Problem gelöst. Sie haben einen klickbaren Prototypen gebaut. Wir haben über Anforderungen nicht nur geredet – wir konnten sie ansehen und anklicken. Das hat sich durch sämtliche Lektionen gezogen. Anforderungen wurden vom Papierobjekt zum erlebbaren Ding.

Am Ende stand die Abschlusspräsentation, und auch da war ich schlicht begeistert von dem, was entstanden ist.

Mit derselben Menge an Lektionen haben wir deutlich mehr Themen verarbeitet als je zuvor. Und – das ist mir wichtig, ehrlich zu sein – es waren die Teams, die diese Leistung erbracht haben, nicht zwingend jede einzelne Person für sich. Die Gruppen haben Requirements so tief verstanden wie keine Klasse vorher. Ob das auch heisst, dass jeder Einzelne den Stoff alleine genauso beherrscht, weiss ich nicht. Vielleicht ist das die falsche Frage. Software entsteht ohnehin nicht im stillen Kämmerlein, sondern im Zusammenspiel. Wir haben in diesem Kurs nicht Einzelkönner ausgebildet, sondern Menschen, die mit anderen und mit der Maschine zusammen zu guten Ergebnissen kommen.

Brauchen wir die alten Konzepte noch?

Das ist die Frage, die mich seither begleitet. Lehren wir noch die Konzepte? Lernen wir noch die alten Themen?

Meine Antwort ist ein klares Sowohl-als-auch. Wer die Grundlagen versteht, versteht den Prozess besser. Wer weiss, warum eine Anforderung mehrdeutig wird, wo Annahmen versteckt liegen, wie aus einem Wunsch ein Kriterium wird, der stellt der KI bessere Fragen und erkennt schneller, wenn ihre Antwort nur gut klingt, aber nicht gut ist. Das Fundament verschwindet nicht. Es wandert nur an eine andere Stelle.

Denn das eigentlich Spannende war zu beobachten, was passiert, wenn eine Gruppe Menschen gemeinsam mit der KI an einem echten Problem arbeitet und die richtigen Fragen stellt. Dann wird das Ergebnis nicht nur gut – es wird in kürzerer Zeit besser. Und ehrlich: Wie cool ist das eigentlich?

Denken auslagern, ja. Urteilen, nein.

Hier liegt für mich der Kern. Wir können das Denken auslagern – aber nicht das Urteil.

Was die Maschine übernimmt, ist das Generieren, das Entwerfen, das Heranschaffen von Varianten. Sie produziert. Was bei uns bleibt, ist das Unterscheiden, das Beurteilen, der Geschmack. Die KI liefert zwanzig Lösungen, der Mensch erkennt, welche taugt – und warum die anderen neunzehn nicht. Sie schreibt das Anforderungsdokument, wir spüren, dass darin der eine Satz fehlt, an dem das ganze Projekt hängt.

Wir gestalten die Interaktionen. Wir sehen die Probleme. Und wir tragen den Wunsch – oder den Auftrag –, eine Lösung zu gestalten. Das ist nichts, was sich an ein Werkzeug delegieren lässt.

Requirements rückt nach vorne

Wenn ich das ernst nehme, dann wird Requirements in Zukunft nicht weniger wichtig, sondern mehr. Wir bewegen uns weg vom reinen Anforderungsverwalter. Mit Kunden reden, Probleme verstehen, Lösungen erarbeiten, Hypothesen aufstellen und validieren – das rückt in den Mittelpunkt des Entstehungsprozesses, nicht an dessen Rand.

Ich glaube, wir werden ganz neue, spannende Arbeitsweisen sehen. Die KI wird zum Kollegen, zum Sparringpartner. Sie ist schnell, geduldig und nie um eine Variante verlegen. Aber die Kreativität geht deshalb nicht auf sie über. Sie bleibt bei uns – und mit ihr die Freude am Bauen.

Genau diese Energie habe ich bei den Studierenden gesehen. Wie sie mit der KI an ihren Problemen gearbeitet haben, wie schnell aus einer Idee etwas Klickbares wurde, wie sichtbar der Spass war. Das kann die Maschine so nicht. Sie hat keine Freude daran, ein Produkt entstehen zu sehen. Wir schon.

Deshalb bin ich zuversichtlich. Die Zukunft wird anders sein, mit der KI als Arbeitskollegen. Aber ich glaube, wir werden die besseren und die schöneren Produkte bauen. Nicht obwohl wir das Denken teilen, sondern weil wir das behalten, worauf es ankommt: das Urteil, die Gestaltung – und die Freude am Bauen.

Solange etwas WIP ist, ist es kein ROI.

---

Es gibt diesen Moment in jedem Teammeeting. Das Board ist voll. Überall Karten. Überall Bewegung. Jemand sagt stolz: „Wir haben gerade 42 Dinge in Arbeit.“ Und alle nicken.

Ich nicke nicht mehr.

42 Dinge in Arbeit bedeutet: 42 Dinge, die noch keinen Wert geliefert haben. 42 Versprechen, die noch nicht eingelöst wurden. 42 halbfertige Ideen, die Aufmerksamkeit fressen, Koordination kosten, und — das ist der entscheidende Punkt — deinem Kunden noch keinen einzigen Franken wert sind.

WIP ist kein Fortschritt. WIP ist Illusion.

---

Der Valuestream lügt nicht

Stell dir einen Fluss vor. Oben rein fliesst Arbeit. Unten raus fliesst Wert — also das, wofür dein Kunde bereit ist zu zahlen. Alles, was in der Mitte steckt, ist kein ROI. Es ist Wasser, das nicht fliesst.

Und Wasser, das nicht fliesst, wird irgendwann stinkig.

Ein Feature, das zu 80% fertig ist, hat einen ROI von 0. Nicht von 80%. Von null. Kein Kunde zahlt für „fast fertig“. Kein Nutzer profitiert von „läuft bald“. Die letzten 20% sind nicht das Problem — das Problem ist, dass du die ersten 80% investiert hast, ohne auch nur einen Franken zurückzubekommen.

while (WIP) { ROI = 0; } ist keine Metapher. Das ist Buchhaltung.

---

Warum aus WIP nie ROI wird — eine ehrliche Liste

Goldplating. Das Feature ist „eigentlich fertig“, aber dann fällt jemandem noch etwas ein. Und noch etwas. Und plötzlich ist aus einer einfachen Lösung ein Architektenwunder geworden, das niemand bestellt hat. Der Kunde wollte einen Schalter. Ihr baut ein Cockpit.

Multitasking-Theater. Alle sind beschäftigt, niemand ist fertig. Jeder jongliert fünf Bälle. Fünf Bälle in der Luft sind beeindruckend anzuschauen — aber kein Ball landet. Und am Ende des Sprints schaut man sich an und fragt sich, warum wieder nichts deployed wurde.

Der endlose Review-Loop. Fertig? Fast. Nur noch schnell durch’s Approval. Dann durch den nächsten. Dann warten auf Feedback. Dann Feedback einarbeiten. Dann nochmals reviewen. Das Feature altert im Staging-System, während der Markt weiterzieht.

Priorisierungsangst. „Wir können noch nicht deployen, es fehlt noch Feature X.“ Warum? „Weil der Stakeholder das erwartet.“ Hat der Stakeholder das gesagt? „Nicht direkt, aber…“ Und schon hat das Bauchgefühl eines Meetings dein Deployment um drei Wochen verschoben.

Das halbfertige Feature als Sicherheitsnetz. Solange es nicht fertig ist, kann es auch nicht scheitern. WIP ist manchmal kein Organisations-problem — es ist ein psychologisches. Wer nie deployed, wird nie enttäuscht. Und wer nie enttäuscht wird, lernt auch nie.

---

Was ihr stattdessen nicht tut

Hier ist das, worüber niemand redet, wenn das Board voll ist.

Während ihr 42 Dinge gleichzeitig halb fertig habt, liegt etwas anderes brach. Etwas, das keine Karte auf dem Board hat, weil es nie dringend genug war um angefangen zu werden — aber wichtig genug, um euch jeden Monat ein bisschen langsamer zu machen.

Eure technische Schuld. Die wächst still. Jeder weiss, wo die Problemstellen sind. Jeder hat sie im Hinterkopf. Und jeder schiebt sie vor sich her, weil „gerade kein Platz ist“. Der Platz ist aber nie da, wenn das System immer voll läuft.

Oder KI. Euer Team spürt, dass sich gerade etwas fundamental verändert — wie Teams arbeiten, wie Wissen verarbeitet wird, wie schnell man von Idee zu Ergebnis kommt. Aber ihr habt nie die Ruhe gehabt, euch als Team hinzusetzen und ernsthaft zu fragen: Was bedeutet das für uns? Wie machen wir das nutzbar? Nicht als Hype, sondern als Werkzeug, das uns wirklich schneller macht.

Das ist das eigentliche Paradox von zu viel WIP: Ihr seid zu beschäftigt damit, langsam zu sein, um schneller zu werden.

Ein System das nie Luft hat, kann sich nicht verbessern. Es kann nur reagieren. Und Organisationen die nur reagieren, werden irgendwann von denen überholt, die sich die Zeit genommen haben, ihr System zu verbessern — weil die nämlich mal fünf Dinge fertig gemacht haben, anstatt fünfundzwanzig anzufangen.

---

10x deployen schlägt 1x perfektionieren

Hier ist das Gegenbild. Nicht das grosse Release nach sechs Monaten Arbeit, auf das alle gewartet haben und das dann — trotz allem — nicht ganz passt. Sondern zehn kleine Deployments, jedes ein Lernmoment, jedes ein Rückfluss, jedes eine Chance, den nächsten Schritt besser zu machen.

Das erste Deployment bringt dir Feedback, das du nicht antizipiert hattest. Das zweite zeigt dir, was die Nutzer wirklich brauchen. Das dritte ist bereits besser als das, was du nach sechs Monaten gebaut hättest — weil du jetzt weisst, was zählt.

Wer früh deployed, lernt früh. Wer früh lernt, baut das Richtige. Wer das Richtige baut, hat ROI.

Der Rest hat WIP.

---

An alle Coaches, POs und SMs da draussen

Ja, ich meine euch.

Ihr sitzt in diesem Meeting. Ihr seht das Board. Ihr wisst, was „42 Dinge in Arbeit“ bedeutet. Und trotzdem sagt ihr nichts — oder ihr habt es gesagt, aber es hat niemanden interessiert.

Hier sind drei Fragen, die ich euch für diese Woche mitgebe:

Was ist das älteste WIP-Item auf eurem Board — und warum ist es noch nicht fertig? Schaut es euch an. Wirklich anschauen. Nicht „wir arbeiten dran“, sondern: Was hält es auf? Was muss weg, damit es durchfliesst?

Was wäre, wenn ihr morgen deployen müsstet — was wäre dann wirklich fertig? Alles andere ist kein WIP. Es ist ein Wunsch.

Wann habt ihr das letzte Mal nein gesagt zu einer neuen Anfrage, weil zuerst etwas abgeschlossen werden muss? Wenn euch keine Antwort einfällt, habt ihr euer WIP-Limit gefunden. Es ist: unendlich.

---

Finishen ist eine Haltung. Nicht ein Zufall.

Euer Board wird nicht kürzer, weil ihr mehr anfangt. Es wird kürzer, weil ihr aufhört anzufangen — und anfangt, fertig zu werden.

while (WIP) { ROI = 0; } lässt sich nur auf eine Art auflösen: den Loop beenden.

Deploy. Lernen. Wiederholen.

---

Ruedi Gysi ist Senior Agile Coach bei Wertwandler GmbH. Er schreibt über Flow, Führung und funktionierende Organisationen auf agile-reflection.org.