Der 400 Wörter/Minute Vorteil: Wie du die „Unausgesprochene Lücke“ schliesst und Deinem Team Superkräfte verleihst

Szene: Das teuerste Nicken der Welt

Schauplatz: Das Sprint Review, letzte Woche. Protagonisten: Sarah (Product Ownerin) und das Entwicklungsteam.

Sarah erklärt die Vision. Sie malt das Bild des neuen „Super-Features“ aus: Es soll die Kundenbeziehung revolutionieren, alles vereinfachen, die Zahlen durch die Decke jagen. Ihr Gehirn ist ein Feuerwerk aus Strategie, Marktdaten und Usability-Details.

Das Team nickt. Sie haben gelauscht. Sie haben zugehört. Sie haben verstanden.

Zwei Wochen später. Das Feature ist fertig, der Deployment-Button gedrückt. Doch beim ersten Test zeigt sich: Die Kernfunktionalität ist da, aber die Intention fehlt. Der Prozess ist nicht „revolutionär“, sondern nur „anders“.

Sarah stöhnt: „Aber ich habe genau erklärt, dass der Klickpfad für den Kunden intuitiv wie eine Google-Suche sein muss!“

Max, der leitende Entwickler, zuckt mit den Schultern: „Wir haben die Spezifikation exakt umgesetzt. Über die Suchlogik haben wir aber nicht gesprochen, wir sind von einer normalen Datenbankabfrage ausgegangen.“

Kostenpunkt des Nickens: Zwei Wochen verlorene Entwicklungszeit, erneuter Frust und der leise Verdacht, dass das Team nicht zuhört.

A: Attention (Aufmerksamkeit): Der Teuerste Engpass im Business

Achtung, Führungskraft! Wie oft nicken deine besten Leute im Meeting, nickst du selbst im Review – und das Ergebnis ist am Ende doch „irgendwie anders“?

Die bittere Wahrheit: 75% Deiner besten Ideen kommen nie aus dem Kopf Deiner Experten heraus.

Wir nennen es die Unausgesprochene Lücke (The Unsaid Gap). Sie ist der teuerste Engpass in der agilen Produktentwicklung: Dein Gehirn denkt mit bis zu 400 Wörtern pro Minute. Aber wenn du oder Dein Product Owner sprichst, kommen nur 125–150 Wörter/Minute heraus. Was passiert mit den restlichen 75%? Sie verschwinden im Äther – oder schlimmer: Sie werden von Deinem Team falsch interpretiert.

I: Interest (Interesse): Warum Deine Meetings Lücken füllen

Diese Lücke kostet dich Zeit, Geld und vor allem Motivation. Das Team ist nicht dumm; es ist kognitiv überfordert.

  • Der PO denkt in Visionen und Marktschmerzen (400 WpM). Das Team hört Features und Tasks (150 WpM).
  • Der Entwickler denkt in Architektur und Abhängigkeiten (400 WpM). Der PO hört Entschuldigungen (150 WpM).

Die grösste Gefahr ist der Fluch des Wissens (Curse of Knowledge): Wir glauben fälschlicherweise, dass das, was uns klar ist, auch dem Gegenüber klar sein muss. Wenn du diese Lücke nicht aktiv adressierst, füllen Teammitglieder die fehlenden 75% mit Annahmen – und Annahmen sind die Mutter aller Scope-Creeps und Fehlentwicklungen.

D: Desire (Wunsch): Die Superkraft des „Deep Listening“

Die Lösung liegt nicht in besseren Tools, sondern in radikaler Verhaltensänderung. Die erfolgreichsten Führungskräfte sind jene, die gelernt haben, aktiv das Unausgesprochene zu extrahieren.

Das Ziel: Deine Führungskräfte, Product Owner und Scrum Master sollen zu Kontext-Architekten werden, die dem Team die Fähigkeit geben, die ungesagten 75% der Idee selbst zu verbalisieren.

RolleFokus der VerhaltensveränderungGewonnener Vorteil
Product Owner/FührungskraftVulnerability-First-MindsetEchte Klarheit: Die Vision wird vollständig aus dem Kopf „ausgepackt“, indem man Unklarheit zugibt und um Hilfe bittet.
Scrum Master/ModeratorInterventions-FacilitationErhöhte Geschwindigkeit: Das Team verschwendet keine Zeit mit dem Bauen falscher Annahmen (Teach Back und Stille schützen).
Entwickler/TeamIntention-First-NeugierVolle Ownership: Das Team baut das richtige Produkt, weil es das „Warum“ (die unausgesprochene Intention) kennt.

Der gewünschte Zustand: Meetings werden kürzer und produktiver, weil sie sich nicht auf das Was, sondern auf das Warum und die Lückenjagd konzentrieren.

A: Action (Handlung): Schliess Deine Lücken noch heute

Die Theorie ist inspirierend, aber das Verhalten zu ändern ist die wahre Herausforderung. Die Muster sind tief verwurzelt.

Wir von Wertwandler sind spezialisiert darauf, agile Teams und Führungskräfte genau in diesen Verhaltenswissenschaften zu coachen. Wir übersetzen komplexe Kognitionspsychologie in alltagstaugliche Methoden und helfen Deinen Schlüsselpersonen, den 400 Wörter/Minute Vorteil zu nutzen.

Willst du herausfinden, wie viele 75%-Lücken Deine Organisation täglich produziert und wie du diese in klare Business-Value verwandeln kannst?

Dein nächster Schritt:

Nimm Dir 15 Minuten Zeit, um mit einem unserer erfahrenen Coaches zu sprechen. In diesem Gespräch analysieren wir Deine aktuellen Kommunikationsmuster und zeigen Dir die konkreten drei Verhaltensänderungen, die in Deinem Team den grössten Impact erzielen. Link zum Beratungsgespräch von Wertwandler

Starte heute. Hör auf, nur das zu hören, was gesagt wird.

Wer sich noch für den Hintergrund interessiert, hier weiterlesen 🙂

Wissenschaftlicher Hintergrund und Quellen zur Überwindung der Lücke

Die Thematik der Unausgesprochenen Lücke fusst auf fundamentalen Erkenntnissen aus der Kognitionspsychologie und der Organisationsforschung, die erklären, warum ein Grossteil der Ideen im Kopf des Sprechers verbleibt und wie dieser Verlust zu Fehlern in der Teamarbeit führt.

1. Kognitionspsychologie und der Fluch des Wissens

Das zentrale Problem beginnt mit der kognitiven Asymmetrie: Studien zur Sprachproduktion zeigen, dass das menschliche Gehirn Gedanken mit einer Geschwindigkeit von bis zu 400 Wörtern pro Minute verarbeitet, während wir nur etwa 125 bis 150 Wörter pro Minute sprechen. Diese Diskrepanz erklärt den Verlust von bis zu 75 Prozent des gedanklichen Kontextes. Eng damit verbunden ist der sogenannte Fluch des Wissens (Curse of Knowledge), wie er unter anderem in den Arbeiten von Chip und Dan Heath (im Buch Made to Stick) popularisiert wurde. Diese kognitive Verzerrung beschreibt die Schwierigkeit von Experten (wie Product Ownern oder leitenden Entwicklern), sich in den Wissensstand eines Laien zurückzuversetzen. Der Sprecher überspringt unbewusst notwendige Erklärungsschritte, weil diese für ihn selbst logisch sind. Die Folge ist ein unvollständiges mentales Modell beim Zuhörer.

2. Deep Listening und die Kunst der Extraktion

Um diese Lücke bewusst zu schliessen, muss das Team von der reinen Faktenverarbeitung zum Deep Listening übergehen. Der Autor und Experte Oscar Trimboli beleuchtet in seinem Werk Deep Listening: Impact Beyond Words explizit, wie man lernt, die „Unausgesprochene Intention“ des Sprechers zu erkennen. Die Verhaltensanweisung für Scrum Master und Führungskräfte liegt hier im aktiven Coaching: Anstatt eigene Lösungen oder Annahmen zu liefern, werden Methoden wie die Sokratische Gesprächsführung (bekannt aus The Coaching Habit von Michael Bungay Stanier) angewandt. Diese erzwingen durch präzise, offene Fragen, dass der Sprecher die fehlenden 75 Prozent seiner Idee selbst verbalisiert. Eine weitere Methode ist die „Teach Back“-Technik aus der Pädagogik, bei der der Zuhörer das Gehörte in eigenen Worten zusammenfassen muss, um Missverständnisse sofort transparent zu machen.

3. Organisationspsychologie und Psychologische Sicherheit

Schliesslich ist die Schliessung der Lücke ohne eine sichere Teamkultur nicht möglich. Die Forscherin Amy Edmondson (Harvard Business School) identifizierte in ihrem Buch The Fearless Organization die Psychologische Sicherheit als Grundvoraussetzung für effektive Teams. Nur wenn Teammitglieder keine Angst haben, „dumme Fragen“ zu stellen oder die Unklarheit der Führungskraft zu adressieren, können die in der Kommunikationslücke verborgenen Annahmen aufgedeckt werden. Patrick Lencioni ergänzt dies mit dem Konzept des Vulnerability-Based Trust (Vertrauen durch Verwundbarkeit), welches verlangt, dass Führungskräfte und Product Owner selbst bereit sind, Unklarheit oder Fehler in der Kommunikation zuzugeben, um dem Team den sicheren Raum für ehrliche Rückfragen zu geben. Die Förderung dieser Verhaltensmuster ist der Schlüssel, um die theoretische Lücke in messbaren Business Value zu verwandeln.

Agilität hat ein Herz

Wenn Agilität nicht das bringt, was man sich erhofft

Ich habe in vielen Organisationen erlebt, wie grosse Erwartungen an Agilität geknüpft werden – mehr Innovation, zufriedenere Kunden, schnellere Ergebnisse. Oft werden neue Teamstrukturen, Rollen, Meetings und Boards eingeführt, und alle machen irgendwie mit. Doch die erhofften Früchte lassen auf sich warten. Stattdessen höre ich immer wieder Klagen über zu viele Meetings, unklare Verantwortlichkeiten oder Tätigkeiten, die von der eigentlichen Arbeit abhalten.

Mir ist dabei immer wieder aufgefallen: Häufig werden Prozesse und Rituale eingeführt – manchmal fast übergestülpt –, ohne dass sich wirklich etwas an der Haltung oder am Miteinander ändert. Für mich zeigte sich: Die Technik oder das Framework allein reicht nicht.

„A fool with a tool is still a fool!“

Ein sehr passender Spruch (leider weiss ich nicht, von wem er stammt). Selbst das beste Werkzeug bringt wenig, wenn man nicht versteht, wofür es da ist – oder wenn die innere Haltung nicht dazu passt. Für mich ist Agilität deshalb weit mehr als Methoden, Rollen und Tools. Sie ist eine Haltung.


Auf der Suche nach dem Kern von Agilität

Früher habe ich mich an den Prinzipien des Agilen Manifests orientiert. Es ist zwar kein ellenlanges Dokument, dennoch ist es schwierig, sich alles zu merken und für alle sich damit zu identifizieren, da es doch aus der Perspektive der Softwareentwicklung entstanden ist.

Vor gut drei Jahren bin ich zufällig auf das Herz der Agilität gestossen. Es ist ein Denkmodell von Dr. Alistair Cockburn (übrigens Co-Autor des Agilen Manifests), der aufgrund der zunehmenden Verwässerung von Agilität durch verschiedene Frameworks und Interpretationen wieder zur Klarheit und Einfachheit der agilen Bewegung zurückkommen wollte. Er hat die Essenz auf das absolut Wesentliche reduziert: vier Worte – nein, Handlungsaufforderungen! – die alles umfassen:

Bildquelle: https://heartofagile.com/

Diese Worte bilden für mich seither so etwas wie einen inneren Kompass. Sie helfen mir, in jeder Situation den Blick aufs Wesentliche zu richten.


Ein gemeinsamer Kompass in der Praxis

Mit dem Heart of Agile schaffe ich es immer, alle ab- und ins gleiche Boot zu holen.

  • Wenn ich Teilnehmende in einem Kickoff-Workshop zu irgendeinem agilen Arbeitsmodell frage, was sie unter Agilität verstehen…kann ich alle Antworten diesen vier Begriffen zuordnen.
  • Wenn sich die Leitenden verschiedener Abteilungen schwer tun, mit einer Abteilung, die mit Kanban arbeitet, anzuknüpfen…finden sie in diesen vier Worten eine gemeinsame Sprache.
  • Wenn ich ein Team in der Umsetzung von Scrum coache, sind sie nicht Betroffene im Widerstand…sondern – vorsichtig aber zunehmend – Beteiligte, die sich mit Fragen und Ideen einbringen, wie sie diesen vier Handlungsaufforderungen in der Organisation noch besser nachkommen können.

Agilität jenseits von Frameworks

Überleg mal, inwiefern Scrum, Kanban und andere agile Arbeitsmodelle das Herz von Agilität in sich haben.

Für mich lebt jedes dieser Modelle auf seine Weise die vier Prinzipien: zusammenarbeiten, liefern, reflektieren, verbessern.

Und nun lehne ich mich vielleicht etwas weit aus dem Fenster, aber ich glaube: Eine Organisation kann auch ohne Framework wirklich agil werden – wenn sie sich konsequent an diesen vier einfachen Handlungsaufforderungen orientiert.

Ich selbst hatte bisher noch nicht die Gelegenheit, das auszuprobieren. Gleichzeitig sehe ich in Frameworks und Modellen wie Scrum, Kanban, Flight Levels, LeSS oder unFix wertvolle Impulse – gerade für Organisationen, die nach Stabilität und Sicherheit streben und den Mut brauchen, aus ihrer gewohnten „Box“ auszubrechen und Neues zu wagen.


Mein Fazit: Ohne Herz keine echte Agilität

Ob Scrum, Kanban, Flight Levels oder andere Modelle – jedes bringt eigene Stärken mit, doch alle leben auf ihre Weise die Grundprinzipien des Heart of Agile. Wenn ich Teams und Organisationen unterstütze agil/er zu werden, frage ich regelmässig:

  • Wie gut arbeiten wir wirklich zusammen – als Team, als Führung, mit Kunden und Stakeholdern?
  • Liefern wir wirklich Wert?
  • Reflektieren wir ehrlich, was gut und was weniger gut läuft?
  • Und verbessern wir uns bewusst – Schritt für Schritt?

Ansonsten bleibt auch die beste Struktur nur Fassade. Denn Agilität beginnt für mich nicht mit Tools oder Rollen – sondern mit einer Haltung. Und die hat, wie Cockburn sagt, ein ganz einfaches Herz. ❤️

Schätzen als Lieferversprechen: Deine Story Points als Wahrscheinlichkeits-Garantie

Du schätzt User Stories im Planning Poker. Aber mal ehrlich: Wie oft hältst Du wirklich, was Du in Story Points versprichst?

Viele Teams schätzen den Aufwand (Complexity), doch diese Zahl hilft dem Product Owner (PO) nur bedingt. Was der PO wirklich wissen muss, ist: Wie sicher kann ich meinen Stakeholdern die Lieferung dieses Features versprechen?

Wir drehen die Logik um: Deine Schätzung soll keine Aufwandsangabe sein, sondern ein direktes Commitment-Level für den PO. Deine Story Points messen ab sofort, wie wahrscheinlich die pünktliche Fertigstellung im Sprint oder innerhalb der vereinbarten Lead Time ist.


🎲 Die neue Logik: Kleine Zahl = Hohe Wahrscheinlichkeit

Unter dieser Methode ist der Story Point eine inverse Kennzahl. Er korreliert direkt mit der Klarheit, Kleinheit und Machbarkeit der Aufgabe.

Story PointCommitment-LevelWahrscheinlichkeit der pünktlichen Lieferung
1Sofortiges Commitment95–100% (Standard, Routine, bereits geklärt)
2Sehr hohes Commitment90–95% (Kleine, klare Aufgabe)
3Gutes Commitment75–90% (Die gängige „normale“ Story)
5Bedingtes Commitment50–75% (Muss näher betrachtet werden)
8Unsicher25–50% (Braucht Vorarbeit oder ist zu groß)
13+Kein Commitment möglich0% (Wird im Sprint sicher nicht geliefert!)

Was misst Du jetzt?

Du misst nicht länger nur die Stunden, sondern die Qualität des Backlog-Items. Eine niedrige Zahl bedeutet, dass das Item die Definition of Ready perfekt erfüllt, klein genug geschnitten wurde und Du alle notwendigen Informationen hast, um es als vorhersagbaren Durchsatz zu behandeln.

Eine Schätzung von 13 ist dabei keine gigantische Aufgabe, sondern ein veto gegen die Lieferbarkeit. Es ist die klare Ansage an den PO: Dieses Item in seinem aktuellen Zustand kann nicht im nächsten Sprint versprochen werden.


Die Konsequenzen für Dein Sprint Planning

Diese Logik zwingt Dich und den PO, das Planning und das Refinement mit einem völlig neuen Fokus anzugehen:

1. Der PO bekommt ein direktes Steuerinstrument

Der PO kann im Planning nun Items nicht nur nach Wert, sondern auch nach Zuverlässigkeit auswählen. Wenn Zuverlässigkeit in diesem Sprint entscheidend ist (z.B. vor einem großen Event oder einem Release), wählt der PO Items mit maximaler Wahrscheinlichkeit: viele „1er“, „2er“ und „3er“.

Muss der PO ein „5er“-Item (50–75% Wahrscheinlichkeit) in den Sprint nehmen, weiß er sofort, dass er eine Wette eingeht. Er kann Stakeholder transparent informieren: „Wir arbeiten daran, aber die Chance, dass es platzt, ist 25–50%.“

2. Das Team ist der Hüter der Klarheit

Das Team nutzt hohe Schätzungen („5“ oder „8“), um Klarheit zu erzwingen. Eine hohe Schätzung ist ein automatischer Refinement-Trigger.

  • Team: „Wir müssen diese Story auf 3 schätzen, denn eine 5 ist uns zu unsicher.“
  • PO: „Was fehlt euch für eine 3?“
  • Team: „Wir müssen das Interface mit dem Legacy-System klären.“

Das Planning wird so zur Risikobewertung des Backlogs, bevor Code geschrieben wird. Es eliminiert die frustrierende Situation, dass ein Team ein unklares Item akzeptiert, nur um die Velocity zu füllen.

3. Das Comeback der strategischen Kapazitätsmarge

Hier schließt sich der Kreis zu Donald G. Reinertsens „Design Factory“. Wie wir besprochen haben, ist es tödlich, die Kapazität auf 100 % auszuregen.

Wenn Du Deine Planung unter dem Gesichtspunkt der Lieferwahrscheinlichkeit durchführst, wirst Du instinktiv keine 100% Auslastung anstreben:

  • Keine Überlastung: Du nimmst nur so viele „1er“, „2er“ und „3er“ in den Sprint, bis Deine kollektive Wahrscheinlichkeit der Lieferung ein akzeptables Niveau erreicht.
  • Puffer für die Wette: Wenn Du ein risikoreiches „5er“-Item in den Sprint aufnehmen musst, bleibt idealerweise ein Kapazitäts-Puffer (Deine cross-funktionalen Teams) im Sprintplan. Dieser Puffer ist die Rückversicherung, die Du ziehst, wenn die 5er-Wette schiefgeht und unerwarteter Klärungsbedarf entsteht.

Deine Schätzung wird vom lästigen Erbsenzählen zu einem strategischen Instrument – für Dich, um die Qualität Deiner Arbeit zu sichern, und für Deinen PO, um verlässliche Lieferversprechen abzugeben.

Die Wiedergeburt der Agilität: Warum Mike Beedles Enterprise Scrum heute spannender ist denn je

Letzte Woche hatte ich das Vergnügen, mich mit einer Gruppe von Coaches und Trainern auszutauschen. Ein Highlight war das Gespräch mit Andreas ( Andy) Schliep, den man in der Szene zu Recht als „Agiles Wikipedia“ bezeichnen könnte. Er zeigte mir ein Dokument, das mich sofort fesselte: die Definition von Enterprise Scrum (ES) von Mike Beedle.

Was ich sah, war kein weiteres Skalierungsframework, das die Softwareentwicklung komplizierter macht. Es war ein generisches Management-Framework, das die Essenz von Scrum auf das gesamte Unternehmen ausdehnt. Es liefert die Blaupause für die echte Business Agility, über die wir alle sprechen, die aber oft an den Wänden von Finance, HR oder Marketing scheitert. Dieses Konzept ist zu spannend, um es für mich zu behalten, und ich möchte es hier mit Euch teilen.

Der Visionär: Mike Beedle

Bevor wir in die Details eintauchen, müssen wir dem Kopf hinter der Idee kurz Tribut zollen. Mike Beedle (1962–2018) war nicht nur irgendein Agilist. Er war einer der Original-Unterzeichner des Agile Manifests aus dem Jahr 2001 – ein echter Pionier.

Beedle erkannte schon früh, dass der wahre Wert von Scrum nicht in den Rollen oder Meetings liegt, sondern im empirischen Prozess der Wertschöpfung. Er verstand, dass Scrum als Framework für die Softwareentwicklung geboren wurde, aber seine Prinzipien — Transparenz, Überprüfung, Anpassung — für jede Unternehmensfunktion universell gültig sind. Enterprise Scrum (ES) ist sein Vermächtnis, der Versuch, diese Verallgemeinerung formal zu definieren.

Enterprise Scrum (ES): Vom Sprint zum Cycle

Was ist nun der Kern von Enterprise Scrum? Es ist die konsequente Übertragung der empirischen Steuerung auf alle Ebenen und Bereiche eines Unternehmens.

1. Generizität: Der universelle Wertstrom

ES ist nicht auf IT beschränkt. Die grundlegenden Artefakte werden umbenannt, um diese Generizität zu betonen:

  • Value List (VL): Ersetzt das Product Backlog. Es enthält VLI (Value List Items), die nicht nur Code oder Features, sondern auch Kampagnen, Compliance-Prüfungen, Geschäftsstrategien oder Finanzentscheidungen sein können.
  • Cycle (Zyklus): Ersetzt den Sprint. Ein Cycle ist eine konfigurierbare, geschachtelte Time-Box (PCRI: Planning, Collaboration, Review, Improve). Ein Quartals-Cycle kann Dutzende von Wochen-Cycles beinhalten. Das erlaubt es Dir, Strategie (lang) und Ausführung (kurz) im Fluss zu halten.

2. Skalierung durch Subsumption

Der wohl revolutionärste Ansatz von ES ist die Skalierungslogik. Statt starrer, zentralisierter Planung (wie in vielen anderen Frameworks) nutzt ES das Subsumption-Prinzip:

  • Entscheidungen werden auf der niedrigsten Ebene getroffen, wo die unmittelbare Realität und das Feedback am besten bekannt sind.
  • Wenn eine Entscheidung (z. B. Budget, Priorität) auf einer höheren Ebene getroffen werden muss, subsumiert die höhere Ebene die Entscheidung, aber sie tut dies, indem sie sich auf die Ergebnisse und Messungen der darunterliegenden Teams stützt. Dies fördert Autonomie und verhindert, dass das Unternehmen von einem zentralen „Command & Control“-System gesteuert wird.

3. Die Balanced Scorecard der Agilität (N-Metrics)

ES bricht mit der alleinigen Fixierung auf die Velocity. Da der Wertbeitrag eines Compliance-Teams oder der Personalabteilung nicht in Story Points gemessen werden kann, führt ES die N-Metrics ein – eine Reihe von balancierten Metriken.

Das Ziel ist es, den Business Value durch die Balance von vier Hauptbereichen zu definieren:

  1. Profit / Finanzen
  2. Kundenzufriedenheit (CX)
  3. Mitarbeiterzufriedenheit (EX)
  4. Zweck (Purpose)

Du kannst nicht mehr nur den Umsatz steigern, während die Mitarbeiterzufriedenheit sinkt. ES zwingt Dich, den gesamten Wertbeitrag im Blick zu behalten und die Agilität gesund zu halten.

Warum Enterprise Scrum heute entscheidend ist

Mike Beedle hat ES entwickelt, um Unternehmen für das 21. Jahrhundert fit zu machen. Angesichts der heutigen Realität – exponentielle technologische Entwicklung, Globalisierung und geopolitische Unsicherheit – ist ES wichtiger denn je:

1. Das Problem der „Agilen Inseln“

Viele Unternehmen haben ihre IT-Abteilung agilisiert, aber der Rest des Unternehmens arbeitet weiterhin im starren Business Waterfall. Das Ergebnis: Der agile Zug muss ständig auf das Marketing-Budget, die Compliance-Freigabe oder die Quartalsplanung warten. ES reißt diese funktionalen Silos ein, indem es alle dazu zwingt, im selben Cycle-Rhythmus zu arbeiten und empirisch zu steuern.

2. Vom Output zum Outcome (und zum Purpose)

In einer Welt, in der Unternehmen schnell auf gesellschaftliche und klimatische Veränderungen reagieren müssen, reicht es nicht, nur auf kurzfristigen Profit zu schauen. Die N-Metrics sind das notwendige Steuerungsinstrument, um nachhaltiges Wachstum zu sichern. Sie garantieren, dass die Agilität nicht zur rücksichtslosen Maximierung, sondern zur resonananten Anpassung genutzt wird.

3. Skalierung ohne Starrheit

Frameworks müssen heute die Geschwindigkeit der Entscheidung erhöhen, nicht verlangsamen. Die Subsumption-Logik und die konfigurierbaren Cycles erlauben es einem Unternehmen, sowohl die langfristige Vision (Big Cycle) zu verfolgen als auch sekündliche Entscheidungen (Small Cycle) dezentral zu treffen, ohne dass das Top-Management zum Flaschenhals wird. ES ist ein generisches Gerüst, das sich der Komplexität des jeweiligen Unternehmens anpasst, anstatt eine Einheitslösung aufzuzwingen.

Enterprise Scrum ist für mich die logische, konsequente und visionärste Weiterentwicklung der agilen Philosophie. Es ist kein Framework für Entwickler, sondern für moderne Führungskräfte, die verstehen, dass Agilität eine Haltung und ein Managementprinzip für die gesamte Organisation sein muss.

Ich bin dankbar für den Austausch, der mir dieses Juwel wieder ins Gedächtnis gerufen hat.

Anmerkung: Das Originaldokument (Enterprise Scrum Definition) sowie eine deutsche Übersetzung findest Du hier zum Download und zur Vertiefung. (Version 3.3 und Version 4.0)


Hier eine übersetzte Version.

Vom 100%-Mythos zur smarten Überkapazität: Warum Auslastung in der Produktentwicklung Dein Feind ist

Der Drang, jede Ressource maximal auszulasten, ist tief in unserem betriebswirtschaftlichen Denken verwurzelt. Wer kennt es nicht? Wenn Dein Team oder eine Maschine nur zu 80% ausgelastet ist, fühlt sich das intuitiv nach „Verschwendung“ an. Doch in der hochkomplexen und variablen Welt der Produktentwicklung und des modernen Designs führt dieses Streben nach 100% Auslastung direkt in die Katastrophe.

Du musst Dein Denken ändern. Wie der Produktentwicklungsexperte Donald G. Reinertsen in seinem wegweisenden Buch „Managing the Design Factory“ argumentiert: Überschüssige Kapazität ist keine Verschwendung, sondern die lebenswichtige Marge, die Deinen Entwicklungsprozess vor dem Stillstand bewahrt.

Stell dir vor du bist Product Owner von einem coolen Team aber Kundenwünsche kannst du nur alle 3 Monate umsetzen und wenn so früh, dann auch nur unter sehr grosser Unsicherheit zum Liefertermin. Genau hier macht es Sinn den Blog genau zu lesen. 🙂


Die Falle der 100%-Auslastung

In einer Fabrik, in der immer wieder die gleichen Schrauben produziert werden, ist die Auslastungsrate ein valides Mass. Die Produktentwicklung, oder, wie Reinertsen es nennt, die „Design Factory“, funktioniert jedoch völlig anders.

1. Die Variabilitätsfalle: Entwicklungsarbeit ist inhärent variabel. Die Dauer einer Design- oder Codierungsaufgabe ist unvorhersehbar, weil sie auf die Generierung neuer Informationen abzielt. Versuchst Du, ein System mit hoher Variabilität – wie Deine Entwicklung – maximal auszulasten, explodieren die Warteschlangen (Queues) vor Deinen Engpass-Stationen.

2. Verdoppelte Zykluszeit: Die Warteschlangentheorie, auf die Reinertsen verweist, liefert einen harten, quantifizierbaren Beweis: Fügst Du einem Prozess, der bereits zu 90% ausgelastet ist, nur 5% mehr Arbeit hinzu, verdoppelst Du im schlimmsten Fall die Zykluszeit. Das bedeutet: Deine Projekte dauern doppelt so lange, bis sie fertig sind.

Dein Fokus auf 100% Auslastung erzeugt das, was er als „Projektüberlastung“ beschreibt. Das gesamte System gerät in einen konstanten Zustand des Stillstands. Statt schneller zu werden, weil „alle beschäftigt sind“, wird Deine gesamte Organisation langsam, unzuverlässig und verpasst alle Termine.


Flexibilität als strategische Überkapazität

Wenn Du die Kapazitätssteuerung als den wichtigsten Hebel zur Reduzierung von Warteschlangen und zur Beschleunigung der Entwicklung erkennst, entsteht eine spannende neue Perspektive: Leerlauf ist eine bewusste Investition in Deine Reaktionsfähigkeit.

Wenn Du Deine Kapazität nur zu 70% oder 80% auslastest, schaffst Du Raum für das, was Reinertsen das „echte Leben“ nennt:

  • Umgang mit unvorhergesehenen Engpässen (Bottlenecks): Im komplexen Entwicklungsprozess tauchen Engpässe unerwartet auf. Mit einer strategischen Überkapazität kannst Du diese Engpässe sofort entlasten, anstatt das gesamte Programm wochenlang warten zu lassen.
  • Reaktion auf Kundenwünsche: Die Flexibilität erlaubt es Dir, kurzfristige, wertvolle Änderungen von Kunden oder dem Markt sofort einzuarbeiten, ohne andere kritische Pfade komplett zu blockieren.
  • Risikominderung durch schnelles Scheitern: Im Designprozess ist das Scheitern von Tests eine wertvolle Quelle für Informationen. Ein System mit Marge kann die durch ein Scheitern notwendige, zusätzliche Schleife schnell bewältigen – das „Zurück zum Zeichenbrett“ kostet keine Wochen Wartezeit.

🤝 Cross-funktionale Teams: Die neue flexible Einheit

Deine Beobachtung, dass freie Kapazitäten plötzlich den strategischen Wert cross-funktionaler Teams maximieren, ist der wichtigste Punkt.

Viele Unternehmen wollen zwar cross-funktionale Teams, aber managen sie so, als wären sie spezialisierte, starre Ressourcen: Sie werden maximal mit Arbeit „vollgestopft“, um die Effizienz zu steigern.

Der Fehler: Ein voll ausgelastetes cross-funktionales Team kann nicht mehr cross-funktional agieren, weil ihm der Spielraum für Flexibilität fehlt.

Die Lösung (nach Reinertsen): Du brauchst Mitarbeiter, die nicht nur Spezialisten (Tiefe der Fähigkeiten) sind, sondern auch generalistische Fähigkeiten (Breite der Fähigkeiten) besitzen.

Altes Management (100% Auslastung)Smartes Management (Kapazitätsmarge)
Spezialisten sind maximal ausgelastet.Cross-Trainierte Generalisten sorgen für Flexibilität.
Engpass tritt auf – das Team steht still, wartet.Engpass tritt auf – die Generalisten greifen ein.
Folge: Verzögerung und mangelnde Anpassung.Folge: Der Flow wird aufrechterhalten, Zykluszeit bleibt kurz.

Indem Du bewusst Kapazität freihältst, wird das cross-funktionale Team zur flexiblen Einheit, die Du wirklich brauchst. Statt in der Landschaft herumzustehen, kann dieses Team:

  1. Engpässe ausgleichen: Ein cross-trainierter Ingenieur kann sofort einspringen, wenn der einzige Tester krank wird (wie in Reinertsens Beispiel), anstatt vier Wochen Wartezeit zu riskieren.
  2. Lernkurven beschleunigen: Sie können ihre freie Zeit nutzen, um sich weiterzubilden, Wissen zu dokumentieren oder andere Teammitglieder zu schulen (ein weiterer Produktivitätshebel aus dem Buch).
  3. Prozesse optimieren: Sie arbeiten proaktiv an der Verbesserung des Wertstroms, anstatt nur reaktiv Aufgaben abzuarbeiten.

Fazit: Wenn Du Deine cross-funktionalen Teams nicht maximal auslastest, machst Du sie nicht ineffizient. Du machst sie agil, schnell und widerstandsfähig gegen die unvermeidliche Variabilität und die Überraschungen, die das Leben (und der Markt) für Deine Entwicklung bereithalten.

Dein wahrer Fokus liegt nicht auf der Effizienz der Einzelressource, sondern auf der Geschwindigkeit und Zuverlässigkeit des gesamten Prozesses. Gib Deinen Teams den Raum, den sie brauchen, um grossartig zu sein!