Any framework gives you structure. Agility is what happens when teams can actually use it. Jedes Framework gibt dir Struktur. Agil wird es erst, wenn Teams auch den Raum haben, damit zu arbeiten.
Most teams follow the process correctly. The ceremonies run. The tickets move. But the space to act on what actually matters — that is defined from above.
Capability Spaces shows you where that space is blocked, and what only you can change.
Die meisten Teams machen alles richtig — auf dem Papier. Die Zeremonien laufen. Die Tickets bewegen sich. Aber der Raum, um das zu tun, was wirklich zählt — der wird von oben definiert.
Capability Spaces zeigt dir, wo dieser Raum blockiert ist, und was nur du verändern kannst.
Agile frameworks – Scrum, Kanban, SAFe, OKR – were all designed to move decision-making closer to the work: to give teams the autonomy to solve real problems. Their manifestos and guides still say so. What happened instead is well documented. Agile Frameworks – Scrum, Kanban, SAFe, OKR – wurden alle mit demselben Ziel entwickelt: Entscheidungen näher an die Arbeit bringen und Teams die Autonomie geben, echte Probleme selbst zu lösen. Ihre Manifeste und Guides sagen das bis heute. Was stattdessen passiert ist, ist gut belegt.
Capability Spaces identifies a critical gap between how leadership perceives its own involvement and the actual capacity of teams to act — teams that are often trapped inside rigid hierarchies. Its three core components — Map, Boundaries, and Compass — make visible whether teams are allowed to solve real problems or merely execute predefined tasks. Boundaries describes artificial barriers like fixed roles and processes; the Compass strengthens psychological forces like trust and knowledge. The model integrates seamlessly into existing frameworks like Scrum or OKR by shifting the focus from pure output to measurable changes in user behaviour. Ultimately, it calls on leaders to take active responsibility for removing organisational obstacles. Das Modell Capability Spaces macht sichtbar, warum agile Transformationen scheitern — und zwar an den strukturellen Rahmenbedingungen, nicht an der Methode. Es zeigt eine kritische Lücke zwischen dem, was Führungskräfte über ihr eigenes Engagement glauben, und dem, was Teams tatsächlich erleben. Teams, die oft in starren Hierarchien feststecken. Die drei Kernkomponenten Map, Boundaries und Compass zeigen, ob Teams echte Probleme lösen dürfen oder nur vorgegebene Aufgaben abarbeiten. Boundaries beschreiben künstliche Barrieren wie starre Rollen oder Prozesse; der Compass stärkt psychologische Kräfte wie Vertrauen und Wissen. Das Modell lässt sich nahtlos in bestehende Frameworks wie Scrum oder OKR integrieren, indem es den Fokus von reinem Output auf messbare Verhaltensänderungen bei Nutzern verschiebt. Letztlich fordert es Führungskräfte auf, organisatorische Hindernisse aktiv aus dem Weg zu räumen.
The data points in the same direction, year after year: the gap between how leadership perceives its own involvement and how teams experience it is the single most consistent predictor of agile failure. Frameworks don't fail because of the method. They fail because the structural preconditions for agile work — empowered teams, problem-oriented work, real leadership presence — are absent. Capability Spaces makes exactly those preconditions visible and diagnosable.
Die Daten zeigen seit Jahren in dieselbe Richtung: Die Lücke zwischen der Selbstwahrnehmung von Führungskräften und der Erfahrung der Teams ist der zuverlässigste Frühindikator für das Scheitern agiler Transformationen. Frameworks scheitern nicht an der Methode. Sie scheitern, weil die strukturellen Voraussetzungen für agiles Arbeiten fehlen – befähigte Teams, problemorientiertes Arbeiten, echte Führungspräsenz. Capability Spaces macht genau diese Voraussetzungen sichtbar und diagnostizierbar.
Clean Agile: Back to Basics (2019) — Martin, one of the original signatories of the Agile Manifesto, describes how Agile started as a developer-led movement: "It was coming from the developers, but project managers flooded into the Agile community, and the developers were left behind – second class citizens in a community we created." The divide between those doing the work and those managing it was never resolved. Capability Spaces names that divide structurally – and gives leaders a format to close it.
Clean Agile: Back to Basics (2019) — Martin, einer der Unterzeichner des Agilen Manifests, beschreibt, wie Agile als Bewegung der Entwickler begann: „Es kam von den Entwicklern – aber Project Manager strömten in die Agile-Community, und die Entwickler wurden zurückgelassen: als Bürger zweiter Klasse in einer Community, die wir selbst geschaffen hatten." Die Trennung zwischen denen, die die Arbeit tun, und denen, die sie managen, wurde nie aufgelöst. Capability Spaces benennt diese Trennung strukturell – und gibt Führungskräften ein Format, sie zu schließen.
You approve, resource, support.
And yet your teams don't deliver.
Read these situations. See how many you recognise.
Your teams work in sprints – but at the sprint review, you're still surprised by what was built.
Your teams run retrospectives – but there is no format where you directly experience what is blocking them. Boundaries stay invisible to you.
Your teams have a product owner – but priorities still come from above. The product owner coordinates, not decides.
The impediments get escalated to you. You solve them. The same impediments come back next sprint.
Your developers are busy. Tickets are being closed. But you don't see the impact in the product or the numbers.
Your teams know exactly what the problem is. They just can't solve it – because they're not allowed to.
Your teams are labelled unmotivated. But they weren't unmotivated to begin with. They were demotivated – by structures that took away their ability to act, to decide, to matter. That is not a people problem. It is what broken pseudo-agile does to people.
Lean UX & Sense & Respond — "Our goal is not to create a deliverable, it's to change something in the world — to create an outcome." Teams that only receive tickets never get the chance to ask the right question: what behaviour are we actually trying to change? Capability Spaces diagnoses why this question structurally never gets asked.
Capability Spaces shows you exactly where the organisation is standing in its own way – and what only you can change. The coaching question comes second: once teams can set their own goals, the work becomes: how do they reach what they committed to themselves?
Du genehmigst, investierst, unterstützt.
Und trotzdem liefern deine Teams nicht.
Lies diese Situationen. Schau, wie viele du wiedererkennst.
Deine Teams arbeiten in Sprints – aber beim Sprint Review überrascht dich trotzdem, was gebaut wurde.
Deine Teams machen Retrospektiven – aber es gibt kein Format, in dem du direkt erlebst, was sie blockiert. Boundaries bleiben für dich unsichtbar.
Deine Teams haben einen Product Owner – aber Prioritäten kommen trotzdem von oben. Der Product Owner koordiniert, entscheidet nicht.
Impediments werden zu dir eskaliert. Du löst sie. Dieselben Impediments tauchen im nächsten Sprint wieder auf.
Deine Entwickler sind beschäftigt. Tickets werden geschlossen. Aber die Wirkung siehst du nicht – weder im Produkt noch in den Zahlen.
Deine Teams wissen genau, was das Problem ist. Lösen können sie es nicht – weil sie es nicht dürfen.
Deine Teams gelten als unmotiviert. Aber sie waren es nicht von Anfang an. Sie wurden demotiviert – durch Strukturen, die ihnen die Fähigkeit genommen haben, zu handeln, zu entscheiden, etwas zu bewirken. Das ist kein Personenproblem. Das ist, was kaputtes Pseudo-Agile mit Menschen macht.
Lean UX & Sense & Respond — „Unser Ziel ist nicht, etwas zu liefern – es ist, etwas in der Welt zu verändern: einen Outcome zu erzeugen." Teams, die nur Tickets bekommen, kommen nie dazu, die richtige Frage zu stellen: Welches Verhalten wollen wir eigentlich verändern? Capability Spaces diagnostiziert, warum diese Frage strukturell nie gestellt wird.
Capability Spaces zeigt dir genau, wo die Organisation sich selbst im Weg steht — und was nur du verändern kannst. Die Coaching-Frage kommt danach: Sobald Teams eigene Ziele setzen können, lautet die eigentliche Frage: Wie erreichen sie, was sie sich selbst vorgenommen haben?
Agile isn't delivering. Teams aren't motivated. The framework feels like overhead. Leadership wonders whether the whole thing was a mistake. These are the symptoms – but none of them is a diagnosis. And without a diagnosis, the only available move is to try a different framework, hire a coach, or quietly give up.
Agilität liefert nicht. Die Teams wirken unmotiviert. Das Framework fühlt sich wie Overhead an. Die Führung fragt sich, ob das Ganze ein Fehler war. Das sind Symptome – aber keine Diagnose. Und ohne Diagnose bleibt nur: ein anderes Framework ausprobieren, einen Coach holen oder still aufgeben.
The question Capability Spaces asks is different: what does the team actually need in order to work the way agile assumes it can? That answer doesn't come from consultants or frameworks. It comes from the teams closest to the work – from what they can and cannot do, what they know and don't know, what they're allowed to decide and what gets decided for them.
Die Frage, die Capability Spaces stellt, ist eine andere: Was braucht das Team tatsächlich, um so zu arbeiten, wie Agilität es voraussetzt? Diese Antwort kommt nicht von Beratern oder Frameworks. Sie kommt von den Teams selbst – davon, was sie können und nicht können, was sie wissen und nicht wissen, was sie entscheiden dürfen und was für sie entschieden wird.
Capability Spaces gives that answer a structure. It describes the space in which a team can actually work – and what expands or shrinks it. Three components. One diagnostic lens.
Capability Spaces gibt dieser Antwort eine Struktur. Es beschreibt den Raum, in dem ein Team tatsächlich arbeiten kann – und was ihn vergrößert oder verkleinert. Drei Komponenten. Ein Diagnosewerkzeug.
Imagine your team starts on an unknown world. At first it only knows its immediate surroundings – the small area where it can act safely. The more problems it solves, the larger that area grows. Unless something keeps it artificially small.
Stell dir vor, dein Team startet auf einer unbekannten Welt. Es kennt zunächst nur seine direkte Umgebung – den kleinen Bereich, in dem es sicher handeln kann. Je mehr Probleme es löst, desto größer wird dieser Bereich. Außer: etwas hält ihn künstlich klein.
The Map shows where a team can move – defined by the product outcomes it can independently pursue. Every business has one goal: growth. How to get there is answered by product outcomes: measurable changes in user behaviour that drive business results. Outputs – features, tickets, deliverables – are the team's hypotheses for how to reach those outcomes.
Die Map zeigt, wo sich ein Team bewegen kann – definiert durch die Product Outcomes, die es eigenständig ansteuern kann. Jedes Business hat ein Ziel: Wachstum. Wie man dorthin kommt, beschreiben Product Outcomes: messbare Verhaltensänderungen bei Nutzern, die Business-Ergebnisse erzeugen. Outputs – Features, Tickets, Lieferungen – sind die Hypothesen des Teams, wie es diese Outcomes erreichen könnte.
Besides the natural boundary (time), there are unnatural boundaries – they artificially slow the growth of the action space. They are diagnostic signals, not team failures.
Neben der natürlichen Boundary (Zeit) gibt es unnatürliche Boundaries – sie bremsen das Wachstum des Handlungsraums künstlich. Sie sind Diagnosezeichen, keine Teamfehler.
The Compass answers one question: how does a team know it's doing the right thing? Each of the four forces is a different feedback signal – validated assumptions, earned trust, growing knowledge, and new problems that find their way to the team.
Der Compass beantwortet eine Frage: Woran merkt ein Team, dass es etwas richtig macht? Jede der vier Kräfte ist ein anderes Feedback-Signal – validierte Annahmen, gewonnenes Vertrauen, wachsendes Wissen und neue Probleme, die ihren Weg zum Team finden.
Every team has an area in which it can independently identify and pursue opportunities. That is its Capability Space – its action space.
The larger this space, the more effective the team. It doesn't grow through more processes – it grows by removing what's in the way.
A small Capability Space looks like this: the team sees an opportunity – a user need, a pain point – but isn't allowed to decide whether to address it. It waits for a ticket from above. The opportunity stays unaddressed. A large Capability Space looks like this: the team spots the opportunity, is allowed to prioritise it, and solves it.
In Continuous Discovery Habits (2021), Torres defines opportunities as "the customer needs, pain points, and desires that, if addressed, will drive your desired outcome." Problems and opportunities are the same thing – seen from different angles. Capability Spaces uses both terms interchangeably, in the spirit of Torres' work.
When a team doesn't reach its goals, Capability Spaces first asks: who set those goals, and was the team in a position to set ones it believed were realistic? If not, the question shifts to the organisation. If a team misses self-set goals, that is where coaching becomes genuinely effective – helping the team understand and reach what it committed to itself.
Capability Spaces identifies four typical obstacles – Boundaries – that prevent teams from working on the problems that truly matter:
People cannot work on the problems they have the right skills for – because their role doesn't permit it.
Tasks arrive as ready-made outputs – features, solutions, specifications. The team is not asked what outcome to achieve, but what to build. This bypasses the team's ability to form and test hypotheses entirely.
Existing workflows prevent teams from making independent decisions or running experiments – regardless of how sensible the goal is.
Implicit norms constrain the space without anyone having consciously decided so. They're just "how things are".
In User Story Mapping (2014), Patton shows that outputs without outcome context produce no impact. When requirements arrive as ready-made features, the team loses the ability to map user behaviour to business results. Capability Spaces diagnoses why this context structurally never gets created – and where the lever is.
Boundaries are not excuses. They are diagnostic points. Name them and you can work on them. Ignore them and you keep turning the dial on a problem that isn't in the team at all. And once boundaries are cleared: if a team then misses goals it set itself, that is the starting point for real coaching – not judgement, but a question: what does this team need to reach its own commitments?
Capability Spaces comes with a simple tool: the traffic light system. It answers one single question: can the team currently work on its most important opportunities?
The traffic light works in any format – a weekly team meeting, a retrospective, or a dedicated session where leaders participate and experience boundaries first-hand.
The team is independently working on its most important opportunities. Maximum impact possible.
The team is working on the most important opportunity, but also serving a boundary in parallel. Impact is reduced.
Boundaries dominate. The team is mainly working on assigned tasks, not on opportunities it has identified itself.
Amber or Red doesn't trigger blame – it triggers diagnosis. Which boundary is it? Who can resolve it? Does it sit inside or outside the team? These questions lead to structural decisions, not to finger-pointing.
Green, Amber, Red is what you see. What produces that signal is a structured analysis across three dimensions – each with its own layers.
The Map is not a single yes or no. It is examined across multiple layers: Where does the problem come from? Is the team's goal outcome-oriented or feature-oriented? Can the team trace the chain from business goal to user problem itself? Each layer can be green, amber or red – and the overall picture emerges from the combination.
Boundaries are not counted – they are named. Which type is it: a role, a requirement, a process, or an unwritten rule? Who would need to change it? And how many boundaries stack up against what the Compass can absorb?
The Compass score is not absolute. A 3 out of 5 is healthy in a team with few boundaries – and insufficient in a team with many. The diagnosis reads all three dimensions together. That is where the interpretation requires experience.
The diagnosis is not the destination – it is the starting point. Once the layers are visible, the work begins: leaders know where structural decisions are needed. Coaches know where the team can grow. Both require experienced guidance – not a checklist, but someone who knows what they are looking at.
Boundaries diagnose what's in the way. The Compass diagnoses what's missing — by answering one question from the team's perspective: how do we know we're doing the right thing? Each of the four forces is a different feedback signal. A team can have zero boundaries and still stay small, if these signals are absent.
When these four conditions are present, something shifts: teams stop waiting to be told what to do next. That is the turning point — when coaching becomes genuinely effective, and when the Compass stops being a diagnostic signal and becomes a growth engine. In the retrospective, teams actively reflect on all four:
A Capability Space doesn't grow by removing obstacles alone. It grows when the team receives signals that its work matters. Each force is one such signal: Assumption Testing tells the team whether its direction is right. Trust tells it that others believe in its judgement. Knowledge tells it that it's getting better at what it does. Connection tells it that new problems are finding their way to the team — because its space has earned them. Together, the four forces answer the question that boundaries cannot: not what's in the way, but whether the team is on the right track. The capacity for each force lives within the team — but the organisation must make them possible.
We had a hypothesis about which user behaviour would change — and we tested it. Not by asking users what they think, but by observing whether their behaviour actually changed. A test requires a hypothesis, a method, and a result that can prove the hypothesis wrong.
Through our work we learned about new problems from stakeholders that we are able to solve. Good work opens new doors.
We built new knowledge that directly helps solve the problems in our area better. Learning with impact.
We received positive feedback from leaders or stakeholders. External trust strengthens the space to act.
Assumption Testing is not feedback collection. Showing a prototype to users and asking "do you like this?" produces opinions — not evidence. Opinions tell you what people say they prefer. Evidence tells you what people actually do.
A test requires four things: a stated hypothesis — before building anything, the team writes down what it expects to happen and why; a falsifiable prediction — "users will like it" is not falsifiable, "checkout completion rate increases by 15%" is; a method that measures behaviour, not opinion — clicks, completions, return visits, not self-reported preferences; and a result that changes the next decision — if the result doesn't change what the team does next, the test served no purpose.
The method does not need to be an A/B test at scale. It can be a prototype test with five users, a concierge experiment, or a paper sketch in an interview. What matters is that the team had a belief, designed something to challenge that belief, and learned whether it was right. A team that collects feedback will always feel like it is testing assumptions. But if the team has no hypothesis — if it cannot state, before showing anything, what it expects to happen — then what it calls "testing" is confirmation seeking. The result will almost always be positive. This is not a signal. It is noise that feels like a signal.
In Trustworthy Online Controlled Experiments (Cambridge University Press, 2020), Kohavi, Tang & Xu — experimentation leaders at Google, LinkedIn, and Microsoft — document the scientific infrastructure required to establish causal relationships between product changes and user behaviour. Their core argument: controlled experiments are the only reliable mechanism to determine whether a change actually caused the observed outcome. Everything else — including user interviews, surveys, and uncontrolled observation — produces correlations that can mislead. The book introduces the concept of an Overall Evaluation Criterion (OEC): a metric that is measurable in the short term but causally connected to long-term strategic goals. Without an OEC, teams cannot distinguish between a change that users liked and a change that produced a real outcome. This is the infrastructure most organisations lack — and its absence is why feedback collection is routinely mistaken for assumption testing.
Jedes Team hat einen Bereich, in dem es eigenständig Opportunities erkennen und bearbeiten kann. Das ist sein Capability Space – sein Handlungsraum.
Je größer dieser Raum, desto wirksamer ist das Team. Er wächst nicht durch mehr Prozesse – sondern wenn Hindernisse wegfallen.
Ein kleiner Capability Space bedeutet zum Beispiel: Das Team erkennt eine Opportunity – ein Nutzerbedürfnis, einen Schmerzpunkt – darf aber nicht eigenständig entscheiden, ob es diese adressiert. Es wartet auf ein Ticket von oben. Die Opportunity bleibt unbearbeitet. Ein großer Capability Space bedeutet: Das Team erkennt die Opportunity, darf sie priorisieren, und löst sie.
In Continuous Discovery Habits (2021) definiert Torres Opportunities als „die Bedürfnisse, Schmerzpunkte und Wünsche von Kunden, die – wenn sie adressiert werden – den gewünschten Outcome erzeugen." Probleme und Opportunities sind dasselbe – aus unterschiedlichen Blickwinkeln betrachtet. Capability Spaces verwendet beide Begriffe im Sinne von Torres' Arbeit.
Wenn ein Team seine Ziele nicht erreicht, fragt Capability Spaces zuerst: Wer hat diese Ziele gesetzt — und konnte das Team überhaupt Ziele setzen, die es selbst für erreichbar hielt? Wenn nicht, verlagert sich die Frage an die Organisation.
Capability Spaces benennt vier typische Hindernisse — Boundaries — die Teams daran hindern, an den wirklich wichtigen Problemen zu arbeiten:
Menschen können nicht an den Problemen arbeiten, für die sie die richtigen Fähigkeiten hätten — weil ihre Rolle es nicht zulässt.
Aufgaben kommen als fertige Outputs an – Features, Lösungen, Spezifikationen. Das Team wird nicht gefragt, welchen Outcome es erzeugen soll, sondern was es bauen soll. Damit wird dem Team die Möglichkeit genommen, eigene Hypothesen zu bilden und zu testen.
Bestehende Abläufe verhindern eigenständige Entscheidungen und Experimente — egal wie sinnvoll das Ziel wäre.
Implizite Normen schränken den Handlungsraum ein, ohne dass jemand das bewusst entschieden hat. Es ist einfach „so".
In User Story Mapping (2014) zeigt Patton, dass Outputs ohne Outcome-Kontext keine Wirkung erzeugen. Wenn Requirements als fertige Features ankommen, verliert das Team die Fähigkeit, Nutzerverhalten mit Business-Ergebnissen zu verknüpfen. Capability Spaces diagnostiziert, warum dieser Kontext strukturell nie entsteht – und wo der Hebel liegt.
Boundaries sind keine Entschuldigungen. Sie sind Diagnosepunkte. Wer sie benennt, kann an ihnen arbeiten. Wer sie ignoriert, dreht weiter an einem Problem, das gar nicht im Team liegt. Und sobald Boundaries beseitigt sind: Wenn ein Team dann selbstgesetzte Ziele verfehlt, ist das der Einstiegspunkt für echtes Coaching – keine Bewertung, sondern eine Frage: Was braucht dieses Team, um seine eigenen Commitments zu erreichen?
Aus Capability Spaces stammt ein einfaches Werkzeug: das Ampel-System. Es beantwortet eine einzige Frage: Kann das Team gerade an seinen wichtigsten Opportunities arbeiten?
Die Ampel funktioniert in jedem bestehenden Format — ob wöchentliches Team-Meeting, Retrospektive oder ein eigenes Format, bei dem Führungskräfte dabei sind und Boundaries direkt miterleben.
Das Team arbeitet eigenständig an seinen wichtigsten Opportunities. Maximale Wirkung möglich.
Das Team arbeitet an der wichtigsten Opportunity, muss aber parallel eine Boundary bedienen. Wirkung eingeschränkt.
Boundaries dominieren. Das Team arbeitet hauptsächlich an vorgegebenen Aufgaben, nicht an eigenen Opportunities.
Gelb oder Rot ist kein Anlass für Kritik — sondern für eine Diagnose. Welche Boundary ist es? Wer kann sie lösen? Liegt sie im Team oder außerhalb? Diese Fragen führen zu strukturellen Entscheidungen, nicht zu Schuldzuweisungen.
Grün, Gelb, Rot ist das, was du siehst. Was dieses Signal erzeugt, ist eine strukturierte Analyse über drei Dimensionen – jede mit eigenen Layern.
Die Map ist kein einzelnes Ja oder Nein. Sie wird über mehrere Layer betrachtet: Woher kommt das Problem? Ist das Ziel des Teams outcome-orientiert oder feature-orientiert? Kann das Team die Kette von Business Goal bis Nutzerproblem selbst herstellen? Jeder Layer kann grün, gelb oder rot sein – das Gesamtbild entsteht aus der Kombination.
Boundaries werden nicht gezählt – sie werden benannt. Welche Art ist es: eine Rolle, ein Requirement, ein Prozess oder eine ungeschriebene Regel? Wer müsste sie verändern? Und wie viele Boundaries stapeln sich gegen das, was der Compass auffangen kann?
Der Compass-Wert ist nicht absolut. Ein 3 von 5 ist gesund in einem Team mit wenigen Boundaries – und unzureichend in einem Team mit vielen. Die Diagnose liest alle drei Dimensionen zusammen. Genau dort braucht die Interpretation Erfahrung.
Die Diagnose ist nicht das Ziel – sie ist der Ausgangspunkt. Sobald die Layer sichtbar sind, beginnt die eigentliche Arbeit: Führungskräfte wissen, wo strukturelle Entscheidungen nötig sind. Coaches wissen, wo das Team wachsen kann. Beides braucht erfahrene Begleitung — keine Checkliste, sondern jemanden, der weiß, worauf er schaut.
Boundaries diagnostizieren, was im Weg steht. Der Compass diagnostiziert, was fehlt — indem er eine Frage aus der Perspektive des Teams beantwortet: Woran merken wir, dass wir das Richtige tun? Jede der vier Kräfte ist ein anderes Feedback-Signal. Ein Team kann null Boundaries haben und trotzdem klein bleiben, wenn diese Signale fehlen.
Wenn diese vier Bedingungen gegeben sind, passiert etwas: Teams hören auf zu warten, dass ihnen jemand sagt, was als Nächstes zu tun ist. Das ist der Wendepunkt — wo Coaching wirklich wirksam wird, und wo der Compass aufhört, ein Diagnosesignal zu sein, und zum Wachstumsmotor wird. In der Retrospektive reflektieren Teams alle vier aktiv:
Ein Capability Space wächst nicht allein dadurch, dass Hindernisse beseitigt werden. Er wächst, wenn das Team Signale bekommt, dass seine Arbeit wirkt. Jede Kraft ist ein solches Signal: Assumption Testing zeigt dem Team, ob seine Richtung stimmt. Trust zeigt, dass andere seinem Urteil vertrauen. Knowledge zeigt, dass es in dem, was es tut, besser wird. Connection zeigt, dass neue Probleme den Weg zum Team finden — weil sein Space sie verdient hat. Zusammen beantworten die vier Kräfte die Frage, die Boundaries nicht beantworten können: nicht was im Weg steht, sondern ob das Team auf dem richtigen Weg ist. Das Potenzial für jede dieser Kräfte liegt im Team — aber die Organisation muss es ermöglichen.
Wir hatten eine Hypothese darüber, welches Nutzerverhalten sich ändern würde — und wir haben sie getestet. Nicht indem wir Nutzer gefragt haben, was sie denken, sondern indem wir beobachtet haben, ob sich ihr Verhalten tatsächlich verändert hat. Ein Test braucht eine Hypothese, eine Methode und ein Ergebnis, das die Hypothese widerlegen kann.
Durch unsere Arbeit haben wir neue Probleme von Stakeholdern erfahren, die wir lösen können. Gute Arbeit öffnet neue Türen.
Wir haben neues Wissen aufgebaut, das direkt hilft, die Probleme in unserem Bereich besser zu lösen. Lernen mit Wirkung.
Wir haben positives Feedback von Führungskräften oder Stakeholdern bekommen. Vertrauen von außen stärkt den Handlungsspielraum.
Assumption Testing ist keine Feedback-Sammlung. Nutzern einen Prototyp zu zeigen und zu fragen „Findest du das gut?" erzeugt Meinungen — keine Evidenz. Meinungen sagen dir, was Menschen sagen, dass sie bevorzugen. Evidenz sagt dir, was Menschen tatsächlich tun.
Ein Test braucht vier Dinge: Eine formulierte Hypothese — bevor das Team etwas baut, schreibt es auf, was es erwartet und warum; eine falsifizierbare Vorhersage — „Nutzer werden es mögen" ist nicht falsifizierbar, „Checkout-Abschlussrate steigt um 15%" schon; eine Methode, die Verhalten misst, nicht Meinungen — Klicks, Abschlüsse, Rückkehrbesuche, nicht selbstberichtete Präferenzen; und ein Ergebnis, das die nächste Entscheidung verändert — wenn das Ergebnis nicht verändert, was das Team als Nächstes tut, hatte der Test keinen Zweck.
Die Methode muss kein A/B-Test im großen Maßstab sein. Es kann ein Prototyp-Test mit fünf Nutzern sein, ein Concierge-Experiment oder eine Papierskizze in einem Interview. Was zählt ist, dass das Team eine Überzeugung hatte, etwas entworfen hat um diese Überzeugung zu prüfen, und gelernt hat ob sie richtig war. Ein Team, das Feedback sammelt, wird immer das Gefühl haben, Annahmen zu testen. Aber wenn das Team keine Hypothese hat — wenn es nicht vor dem Zeigen sagen kann, was es erwartet — dann ist das, was es „Testen" nennt, Bestätigungssuche. Das Ergebnis wird fast immer positiv sein. Das ist kein Signal. Es ist Rauschen, das sich wie ein Signal anfühlt.
In Trustworthy Online Controlled Experiments (Cambridge University Press, 2020) dokumentieren Kohavi, Tang & Xu — Experimentier-Verantwortliche bei Google, LinkedIn und Microsoft — die wissenschaftliche Infrastruktur, die nötig ist, um kausale Zusammenhänge zwischen Produktänderungen und Nutzerverhalten herzustellen. Ihr Kernargument: Kontrollierte Experimente sind der einzige zuverlässige Mechanismus, um festzustellen, ob eine Änderung tatsächlich das beobachtete Ergebnis verursacht hat. Alles andere — einschließlich Nutzerinterviews, Umfragen und unkontrollierte Beobachtung — erzeugt Korrelationen, die in die Irre führen können. Das Buch führt das Konzept eines Overall Evaluation Criterion (OEC) ein: eine Metrik, die kurzfristig messbar ist, aber kausal mit langfristigen strategischen Zielen verbunden. Ohne OEC kann ein Team nicht unterscheiden, ob eine Änderung den Nutzern gefallen hat oder ob sie ein echtes Outcome erzeugt hat. Das ist die Infrastruktur, die den meisten Organisationen fehlt — und ihre Abwesenheit ist der Grund, warum Feedback-Sammlung routinemäßig mit Assumption Testing verwechselt wird.
Innovation is not a process, a workshop, or a roadmap item. It is a specific outcome: a change in user behaviour that drives business results. Only one group in your organisation can produce that – the teams who interact with users, test hypotheses, and learn from what actually happens.
Innovation ist kein Prozess, kein Workshop und kein Roadmap-Eintrag. Sie ist ein konkretes Ergebnis: eine Veränderung im Verhalten von Nutzern, die Business-Ergebnisse erzeugt. Nur eine Gruppe in deiner Organisation kann das leisten – die Teams, die mit Nutzern interagieren, Hypothesen testen und aus dem lernen, was wirklich passiert.
The energy in early-stage startups is not a mystery. Product teams work directly with customers. Developers move freely in the user's problem space – they talk to users, see the friction firsthand, decide what to try next, and learn whether it worked. No Map is handed down from above. The Map emerges from proximity to the problem. No Compass needs to be installed. Trust, shared knowledge, and constant assumption testing are simply how the work gets done.
Warum frühe Startups so viel Energie haben, ist leicht zu erklären. Produktteams arbeiten direkt mit Kunden. Entwickler bewegen sich frei im Problemraum des Nutzers – sie sprechen mit Nutzern, erleben die Reibung selbst, entscheiden, was sie als Nächstes ausprobieren, und lernen, ob es funktioniert hat. Keine Map wird von oben vorgegeben. Die Map entsteht aus der Nähe zum Problem. Kein Compass muss erst installiert werden. Vertrauen, gemeinsames Wissen und ständiges Testen von Annahmen sind einfach die Art, wie die Arbeit läuft.
Then the startup gets acquired. Or it scales. Or it fails and the team disperses into larger organisations. What changes is not the people – it is the structure around them.
Dann wird das Startup aufgekauft, oder es skaliert, oder es scheitert und das Team verteilt sich in größere Organisationen. Was sich verändert, sind nicht die Menschen — es ist die Struktur um sie herum.
Suddenly there are roles that weren't there before. Requirements that arrive pre-defined. Processes that need sign-off. Rules no one wrote down but everyone follows. The freedom to move in the problem space contracts.
Plötzlich gibt es Rollen, die vorher nicht da waren. Anforderungen, die vordefiniert ankommen. Prozesse, die Freigaben brauchen. Regeln, die niemand aufgeschrieben hat, aber alle befolgen. Die Freiheit, sich im Problemraum zu bewegen, schrumpft.
The team no longer identifies user problems and opportunities. A backlog of tickets replaces proximity to users. Work becomes execution of someone else's hypothesis – and whether that hypothesis was right is rarely checked.
Das Team identifiziert keine Nutzerprobleme und Opportunities mehr selbst. Ein Ticket-Backlog ersetzt die Nähe zu Nutzern. Arbeit wird zur Ausführung einer fremden Hypothese – und ob diese Hypothese richtig war, wird selten überprüft.
The trust that enabled fast decisions is replaced by approval chains. Shared knowledge fragments across silos. Assumption testing gives way to roadmap delivery. The team still shows up – but the conditions that made them innovative no longer exist.
Das Vertrauen, das schnelle Entscheidungen ermöglichte, wird durch Freigabeketten ersetzt. Gemeinsames Wissen fragmentiert über Silos. Assumption Testing weicht der Roadmap-Lieferung. Das Team ist noch da – aber die Bedingungen, die sie innovativ gemacht haben, existieren nicht mehr.
This is not an anecdote. M&A research consistently finds that innovation rates decline after acquisition – and that the primary driver is the structural loss of autonomy for the acquired team. Paruchuri, Nerkar & Hambrick (Organization Science, 2006) showed that integrated acquisitions produce measurably fewer innovations than non-integrated ones. Puranam et al. (Strategic Management Journal, 2006) named the core tension: acquirers must integrate to exploit capabilities – but integration destroys the autonomy that made those capabilities possible in the first place. The mechanism is structural, not motivational.
Das ist keine Anekdote. M&A-Forschung zeigt konsistent, dass Innovationsraten nach Akquisitionen sinken – und dass die Hauptursache der strukturelle Verlust von Autonomie im akquirierten Team ist. Paruchuri, Nerkar & Hambrick (Organization Science, 2006) zeigten, dass integrierte Akquisitionen messbar weniger Innovationen produzieren als nicht-integrierte. Puranam et al. (Strategic Management Journal, 2006) benannten die Kernspannung: Käufer müssen integrieren, um die erworbenen Kompetenzen zu nutzen – aber Integration zerstört genau die Autonomie, die diese Kompetenzen erst hervorgebracht hat. Der Mechanismus ist strukturell, nicht motivationsbedingt.
The people didn't change. The Capability Space did. That is what Capability Spaces makes visible – before the team stops delivering, before the retrospectives become frustrating, before leadership concludes the team simply isn't good enough.
Die Menschen haben sich nicht verändert — ihr Capability Space schon. Genau das macht Capability Spaces sichtbar – bevor das Team aufhört zu liefern, bevor die Retrospektiven frustrierend werden, bevor die Führung zum Schluss kommt, das Team sei einfach nicht gut genug.
New features shipped. Roadmaps delivered. Sprints completed on time. Quarterly objectives checked off.
Neue Features geliefert. Roadmaps abgearbeitet. Sprints pünktlich abgeschlossen. Quartalsziele abgehakt.
A measurable change in how users behave – engagement, retention, decisions made differently. Everything else is output.
Eine messbare Veränderung darin, wie Nutzer sich verhalten – Engagement, Retention, anders getroffene Entscheidungen. Alles andere ist Output.
When teams receive tickets instead of problems, they ship outputs without ever learning whether user behaviour changed. When Boundaries block them from choosing what to work on, hypothesis testing stops entirely. The team cannot innovate – not because of lack of skill or motivation, but because the conditions for innovation are structurally absent. A Capability Space that is too small doesn't just slow delivery. It makes real innovation impossible.
Wenn Teams Tickets statt Probleme erhalten, liefern sie Outputs, ohne je zu erfahren, ob sich das Nutzerverhalten verändert hat. Wenn Boundaries sie davon abhalten, selbst zu wählen, woran sie arbeiten, endet jedes Testen von Hypothesen. Das Team kann nicht innovieren – nicht wegen mangelnder Kompetenz oder Motivation, sondern weil die Bedingungen für Innovation strukturell fehlen. Ein zu kleiner Capability Space verlangsamt nicht nur die Lieferung. Er macht echte Innovation unmöglich.
This idea is not new. The Agile Manifesto already stated it in 2001: "Working software over comprehensive documentation. Customer collaboration over contract negotiation." The intended measure of progress was always real impact on users – not process compliance, not delivery velocity. Eighteen years later, Josh Seiden felt compelled to repeat it in Outcomes Over Outputs (2019): "Customer behavior is the key metric for business success." Two years after that, Teresa Torres sharpened it once more in Continuous Discovery Habits (2021): "An outcome is a change in human behavior that drives business results." Three authors. Twenty years. The same sentence. The industry still hasn't heard it. Capability Spaces diagnoses why – and where the structural lever is.
Diese Idee ist nicht neu. Das Agile Manifesto hat sie bereits 2001 formuliert: „Working software over comprehensive documentation. Customer collaboration over contract negotiation." Das beabsichtigte Maß für Fortschritt war immer echte Wirkung auf Nutzer – nicht Prozesstreue, nicht Liefergeschwindigkeit. Achtzehn Jahre später wiederholte Josh Seiden es in Outcomes Over Outputs (2019): „Kundenverhalten ist die entscheidende Kennzahl für unternehmerischen Erfolg." Zwei Jahre danach schärfte Teresa Torres es erneut in Continuous Discovery Habits (2021): „Ein Outcome ist eine Veränderung im menschlichen Verhalten, die Business-Ergebnisse erzeugt." Drei Autoren. Zwanzig Jahre. Derselbe Satz. Die Industrie hat ihn noch immer nicht gehört. Capability Spaces diagnostiziert, warum – und wo der strukturelle Hebel liegt.
The distinction between output and outcome is not a modern invention. It reaches back to the foundations of innovation economics. Joseph Schumpeter, in The Theory of Economic Development (1911), defined innovation not as an idea, but as the Durchsetzung neuer Kombinationen — the carrying out of new combinations. An idea that is never implemented, a product that is never adopted, is not an innovation. It is an unrealised combination. Innovation exists only in the moment it changes economic reality.
Peter Drucker made the same point in economic language: innovation is not invention — it is a term of economics, not of technology (Innovation and Entrepreneurship, 1985). His McDonald's example is instructive: McDonald's invented nothing. But by asking "what is value to the customer?" and reorganising every process around the answer, it created a new market and a new customer. That is innovation — not because something was built, but because behaviour changed at scale.
Everett Rogers arrived at the same insight from the demand side. In Diffusion of Innovations (1962, 5th ed. 2003), he defined adoption as the moment when a person does something differently than before. Without adoption, there is no diffusion. Without diffusion, there is no innovation — only output.
The iPhone is the clearest modern illustration: it was not an innovation because it was designed, engineered, or announced. It was an innovation because people used it — and the way they used it transformed how entire industries operate. Had nobody adopted it, it would have remained an invention: impressive, perhaps, but economically inert.
This is why Capability Spaces insists on outcomes. Not as a judgement of teams, but as a diagnosis of the organisation. The question is not whether a team is "good enough" to produce innovation. The question is whether the organisation has built the conditions under which the team's work can become an outcome at all — the chain from business goal to user problem to measurable behaviour change. Without that chain, even excellent work remains structurally invisible: output without outcome, invention without innovation.
Die Unterscheidung zwischen Output und Outcome ist keine moderne Erfindung. Sie reicht zurück zu den Grundlagen der Innovationsökonomik. Joseph Schumpeter definierte in der Theorie der wirtschaftlichen Entwicklung (1911) Innovation nicht als Idee, sondern als Durchsetzung neuer Kombinationen. Eine Idee, die nie umgesetzt wird, ein Produkt, das nie genutzt wird, ist keine Innovation. Es ist eine unrealisierte Kombination. Innovation existiert erst in dem Moment, in dem sie die ökonomische Realität verändert.
Peter Drucker formulierte denselben Punkt ökonomisch: Innovation ist nicht Erfindung — es ist ein Begriff der Ökonomie, nicht der Technologie (Innovation and Entrepreneurship, 1985). Sein McDonald's-Beispiel ist aufschlussreich: McDonald's hat nichts erfunden. Aber indem es fragte „Was ist Wert für den Kunden?" und jeden Prozess um die Antwort herum reorganisierte, schuf es einen neuen Markt und einen neuen Kunden. Das ist Innovation — nicht weil etwas gebaut wurde, sondern weil sich Verhalten im großen Maßstab veränderte.
Everett Rogers kam von der Nachfrageseite zur selben Erkenntnis. In Diffusion of Innovations (1962, 5. Aufl. 2003) definierte er Adoption als den Moment, in dem eine Person etwas anders tut als zuvor. Ohne Adoption gibt es keine Diffusion. Ohne Diffusion gibt es keine Innovation — nur Output.
Das iPhone ist die klarste moderne Illustration: Es war keine Innovation, weil es designt, entwickelt oder angekündigt wurde. Es war eine Innovation, weil Menschen es nutzten — und die Art, wie sie es nutzten, die Funktionsweise ganzer Industrien veränderte. Hätte es niemand genutzt, wäre es eine Erfindung geblieben: beeindruckend vielleicht, aber ökonomisch wirkungslos.
Deshalb besteht Capability Spaces auf Outcomes. Nicht als Bewertung von Teams, sondern als Diagnose der Organisation. Die Frage ist nicht, ob ein Team „gut genug" ist, um Innovation hervorzubringen. Die Frage ist, ob die Organisation die Bedingungen geschaffen hat, unter denen die Arbeit des Teams überhaupt ein Outcome werden kann — die Kette von Business-Ziel zu Nutzerproblem zu messbarer Verhaltensänderung. Ohne diese Kette bleibt selbst exzellente Arbeit strukturell unsichtbar: Output ohne Outcome, Erfindung ohne Innovation.
Not every organisation can be innovative — and that is not a failure. If every output were an innovation, the term would be meaningless. Innovation is rare by definition, because it requires real behaviour change, and real behaviour change requires scientific work: hypotheses, tests, measurement, learning. But here is the strategic question every leadership team must answer: does your organisation need to be innovative to survive? In a tightening market with increasing competition, the answer is almost always yes.
A Feature Factory is an organisation that produces output without ever asking whether that output changes anything. It ships, but it does not learn. For decades, this was a viable model. It no longer is. AI can produce output faster, cheaper, and more reliably than any human team. Code generation, design automation, content creation — the output layer is being commoditised. An organisation that competes on output speed is competing against a force it cannot outrun.
What AI cannot do is the work that comes before the output: understanding the problem, framing the hypothesis, designing the experiment, interpreting the result, and deciding what to do next. That is scientific work. It requires judgement, context, empathy, and the ability to navigate ambiguity — exactly the capabilities that a Capability Space is designed to protect and grow. The Feature Factory doesn't break. It simply becomes irrelevant.
Nicht jede Organisation kann innovativ sein — und das ist kein Versagen. Wenn jeder Output eine Innovation wäre, wäre der Begriff bedeutungslos. Innovation ist per Definition selten, weil sie echte Verhaltensänderung erfordert, und echte Verhaltensänderung erfordert wissenschaftliche Arbeit: Hypothesen, Tests, Messung, Lernen. Aber hier ist die strategische Frage, die jedes Führungsteam beantworten muss: Muss eure Organisation innovativ sein, um zu überleben? In einem enger werdenden Markt mit zunehmender Konkurrenz lautet die Antwort fast immer Ja.
Eine Feature Factory ist eine Organisation, die Output produziert, ohne je zu fragen, ob dieser Output etwas verändert. Sie liefert, aber sie lernt nicht. Jahrzehntelang war das ein tragfähiges Modell. Das ist es nicht mehr. KI kann Output schneller, günstiger und zuverlässiger produzieren als jedes menschliche Team. Code-Generierung, Design-Automatisierung, Content-Erstellung — die Output-Ebene wird zur Commodity. Eine Organisation, die auf Output-Geschwindigkeit setzt, konkurriert gegen eine Kraft, die sie nicht überholen kann.
Was KI nicht kann, ist die Arbeit, die vor dem Output kommt: das Problem verstehen, die Hypothese formulieren, das Experiment designen, das Ergebnis interpretieren und entscheiden, was als Nächstes zu tun ist. Das ist wissenschaftliche Arbeit. Sie erfordert Urteilsvermögen, Kontext, Empathie und die Fähigkeit, mit Ambiguität umzugehen — genau die Fähigkeiten, die ein Capability Space schützen und wachsen lassen soll. Die Feature Factory bricht nicht zusammen. Sie wird einfach irrelevant.
A dedicated UX/UI team works with the Lean UX Canvas, builds proto-personas, and frames every conversation around user needs. The intent is genuinely user-centred. But the product team around them consistently reverts to anti-patterns: the sprint review becomes a status report — "here's what we built" — users are invited but can't actually test anything, and the Jira backlog is filled with pre-defined solutions rather than problems to explore.
Ein dediziertes UX/UI-Team arbeitet mit dem Lean UX Canvas, baut Proto-Personas und richtet jedes Gespräch an Nutzerbedürfnissen aus. Der Anspruch ist aufrichtig nutzerzentriert. Aber das umgebende Produktteam verfällt immer wieder in dieselben Fehlmuster: Das Sprint Review wird zur Statusmeldung — „Das haben wir gebaut" — Nutzer*innen sind eingeladen, können die Anwendung aber nicht ausprobieren, und der Jira-Backlog ist voll mit vordefinierten Lösungen statt zu erkundender Probleme.
The audience in the review room makes this worse. Most participants have no relationship to the product and no ability to evaluate whether the work produced real value. For them, software development is a black box. They nod. They approve. Nobody learns anything — because learning was never the purpose of the room.
Das Publikum im Review-Raum verstärkt das. Die meisten Teilnehmenden haben keinen Bezug zum Produkt und können nicht beurteilen, ob die Arbeit wirklich etwas gebracht hat. Für sie ist Softwareentwicklung eine Blackbox. Also nicken sie und genehmigen. Niemand lernt etwas — weil Lernen nie der Zweck des Raums war.
This is a Requirements boundary: work arrives as pre-defined features, not as problems worth solving. As long as the backlog is filled from above, no Lean UX Canvas creates the space for genuine discovery. The Compass force of Assumption Testing is structurally blocked — not from lack of skill or will, but because the team is never handed a real user problem to test against. The review format is a symptom of exactly this: as long as learning doesn't come first, the framing will always drift toward output.
Das ist eine Requirements-Boundary: Arbeit kommt als vordefiniertes Feature an, nicht als Problem, das es zu lösen gilt. Solange der Backlog von oben befüllt wird, schafft kein Lean UX Canvas den Raum für echte Discovery. Die Compass-Kraft Assumption Testing ist strukturell blockiert — nicht aus Mangel an Kompetenz oder Willen, sondern weil dem Team nie ein echtes Nutzerproblem zum Testen gegeben wird. Das Review-Format ist genau dafür ein Symptom: Solange Lernen nicht an erster Stelle steht, wird es immer eine Output-Präsentation bleiben.
The review question changes from "What did we build?" to "What did we learn — and what outcomes did we observe?" This doesn't mean every sprint must show a measurable change in user behaviour. That is an unrealistic expectation for a two- or four-week cycle. But if the team's culture is oriented around learning and user feedback, every review can answer at least one question: what did we learn? A negative finding — a hypothesis that failed, a user who couldn't complete a flow — is a legitimate result. It is evidence. It moves the work forward.
Die Review-Frage verändert sich von „Was haben wir gebaut?" zu „Was haben wir gelernt — und welche Outcomes haben wir beobachtet?" Das bedeutet nicht, dass jeder Sprint eine messbare Veränderung im Nutzerverhalten zeigen muss. Das wäre eine unrealistische Erwartung für einen zwei- oder vierwöchigen Zyklus. Aber wenn die Kultur des Teams wirklich auf Lernen und Nutzerfeedback ausgerichtet ist, kann jedes Review mindestens eine Frage beantworten: Was haben wir gelernt? Ein negatives Ergebnis — eine Hypothese, die nicht bestätigt wurde, ein Nutzer, der einen Flow nicht abschließen konnte — ist ein legitimes Ergebnis. Es ist ein Beleg, und es bringt die Arbeit voran.
Leaders are not needed in the review as approvers — they are needed as diagnostic partners. The question after each review is: "Are there boundaries in what we just heard — and which category are they?" Naming the category is what makes the boundary actionable.
Führungskräfte werden im Review nicht als Genehmigende gebraucht — sondern als Diagnosepartner. Die Frage nach jedem Review lautet: „Stecken in dem, was wir gerade gehört haben, Boundaries — und wenn ja, welcher Kategorie?" Erst die Kategorie macht eine Boundary bearbeitbar.
Is the Product Owner actually empowered to talk to users — or does their role definition stop at backlog management? If user research sits exclusively with a separate UX team and the PO has no mandate to conduct conversations themselves, discovery stays structurally siloed.
Ist der Product Owner so ausgestattet, dass er selbst Gespräche mit Nutzer*innen führen kann — oder endet seine Rollendefinition beim Backlog-Management? Wenn User Research ausschließlich bei einem separaten UX-Team liegt und der PO kein Mandat für eigene Gespräche hat, bleibt Discovery strukturell isoliert.
User interviews require a legal sign-off that takes three weeks. · Recruiting users for a test needs a procurement process — by the time approval arrives, the sprint is over. · Every prototype must pass a brand review before it can be shown to anyone outside.
Nutzerinterviews benötigen ein rechtliches Freigabeverfahren, das drei Wochen dauert. · Nutzer*innen für einen Test zu rekrutieren erfordert einen Einkaufsprozess — bis zur Genehmigung ist der Sprint vorbei. · Jeder Prototyp muss ein Brand-Review durchlaufen, bevor er irgendjemandem außerhalb gezeigt werden darf.
"We don't show unfinished things to customers." · "The sprint review is an internal meeting — users aren't part of that." · "Feedback comes through the account manager, not directly from users."
„Wir zeigen Kunden keine unfertigen Dinge." · „Das Sprint Review ist ein internes Meeting — Nutzer*innen gehören da nicht dazu." · „Feedback kommt über den Account Manager, nicht direkt von Nutzer*innen."
Most agile transformations don't fail because of the wrong framework. They fail because the structural preconditions for agile work are missing. Capability Spaces makes those preconditions explicit – and diagnosable.
Die meisten agilen Transformationen scheitern nicht am falschen Framework. Sie scheitern, weil die strukturellen Voraussetzungen für agiles Arbeiten fehlen. Capability Spaces macht diese Voraussetzungen explizit – und damit diagnostizierbar.
The model identifies the structural conditions that cause failure – while they are still visible and changeable. Both are structural. Both are visible – if you know what to look for.
Das Modell macht die strukturellen Bedingungen sichtbar, die zum Scheitern führen – solange sie noch veränderbar sind. Beide Bedingungen sind struktureller Natur, und beide sind sichtbar – wenn man weiß, wonach man schauen muss.
Teams are not allowed to work problem-oriented. Developer teams, product teams, ops teams receive pre-defined solutions – not problems to solve. The Capability Space cannot grow because there is no space to explore.
Teams dürfen nicht problemorientiert arbeiten. Developer-Teams, Produktteams, Ops-Teams erhalten vordefinierte Lösungen – keine Probleme zum Lösen. Der Capability Space kann nicht wachsen, weil es keinen Raum zum Erkunden gibt.
The structural constraints – role definitions, processes, rules, requirements – are permanently larger than what the Compass (Trust, Knowledge, Connection, Assumption Testing) can absorb. The team cannot compensate organisational friction through internal cohesion.
Die strukturellen Einschränkungen – Rollendefinitionen, Prozesse, Regeln, Requirements – sind dauerhaft größer als das, was der Compass (Trust, Knowledge, Connection, Assumption Testing) auffangen kann. Das Team kann die Reibung aus der Organisation nicht durch inneren Zusammenhalt kompensieren.
When no Map exists (teams work on solutions, not problems) and Boundaries > Compass persistently — agile transformation will fail. Not because of the method. Because the structural preconditions are absent.
Wenn keine Map existiert (Teams arbeiten an Lösungen, nicht an Problemen) und Boundaries > Compass dauerhaft — wird die agile Transformation scheitern. Nicht wegen der Methode. Weil die strukturellen Voraussetzungen fehlen.
Capability Spaces gives you a diagnostic while the transformation is underway – and a shared language to name what's missing. The goal isn't to predict failure in order to give up. It's to see the conditions clearly enough to change them.
Capability Spaces liefert eine Diagnose, während die Transformation läuft – und eine gemeinsame Sprache, um zu benennen, was fehlt. Das Ziel ist nicht, Scheitern vorherzusagen, um aufzugeben. Sondern die Bedingungen klar genug zu sehen, um sie zu verändern.
Structural Comfort is the state where a system has stabilised so thoroughly that nobody experiences friction anymore – not because friction has been resolved, but because it has been made invisible.
Structural Comfort ist der Zustand, in dem sich ein System so stabilisiert hat, dass niemand mehr Reibung erlebt – nicht weil Reibung beseitigt wurde, sondern weil sie unsichtbar gemacht wurde.
The team is satisfied because someone absorbs the pressure. Leadership is satisfied because results are delivered. The person in between is satisfied because they are needed. All three sides have an interest in nothing changing. The system rewards itself for staying small.
Das Team ist zufrieden, weil jemand den Druck absorbiert. Die Führung ist zufrieden, weil Ergebnisse geliefert werden. Die Person dazwischen ist zufrieden, weil sie gebraucht wird. Alle drei Seiten haben ein Interesse daran, dass sich nichts ändert. Das System belohnt sich selbst dafür, klein zu bleiben.
Imagine a product team. Five developers, a designer, a Product Owner. They work in sprints, they have a board, they do reviews. Every two weeks they show what they built. Stakeholders nod, say it looks great, suggest a few things for next sprint. The team feels valued. The PO feels effective. Leadership sees a functioning team.
Now zoom out. The team has never spoken to a user. It has never defined a product outcome. It has never asked: why are we building this, and how will we know if it worked? Every feature it ships was decided by someone else — translated into a ticket by the PO, who saw that the raw requirements from leadership would overwhelm the team. So the PO filtered, reformulated, prioritised. A service. A kindness.
But here is what the kindness cost: the team never learned to navigate. It has no mental model of who its users are, what problems they face, or how its work connects to business results. If you asked the team to set its own goals tomorrow, it wouldn't know where to start. Not because it lacks intelligence — but because its Capability Space never grew. The PO kept it small, with the best of intentions.
And leadership? Leadership never asked the question, because there was no signal to ask it. No complaints, no missed deadlines, no visible friction. The system looked healthy. It was, in fact, fragile — held together by a single person's capacity to absorb complexity that should have been shared.
This is Structural Comfort. Not a failure. Not incompetence. A stable equilibrium that prevents growth — invisible to everyone inside it, and durable enough to persist for years. It does not break on its own. It requires a diagnostic that asks a question nobody inside the system is asking: is this team's Capability Space connected to outcomes that matter?
Stell dir ein Produktteam vor. Fünf Entwickler, eine Designerin, ein Product Owner. Sie arbeiten in Sprints, haben ein Board, machen Reviews. Alle zwei Wochen zeigen sie, was sie gebaut haben. Stakeholder nicken, sagen, das sieht toll aus, schlagen ein paar Dinge für den nächsten Sprint vor. Das Team fühlt sich wertgeschätzt. Der PO fühlt sich wirksam. Die Führung sieht ein funktionierendes Team.
Jetzt der Blick von außen. Das Team hat nie mit einem Nutzer gesprochen. Es hat nie ein eigenes Product Outcome definiert. Es hat nie gefragt: Warum bauen wir das — und woran werden wir erkennen, ob es gewirkt hat? Jedes Feature, das es ausliefert, wurde von jemand anderem entschieden — vom PO in ein Ticket übersetzt, weil er sah, dass die rohen Anforderungen der Führung das Team überfordern würden. Also hat der PO gefiltert, umformuliert, priorisiert — aus Fürsorge, als Service für das Team.
Aber die Fürsorge hat ihren Preis: Das Team hat nie gelernt, sich selbst zu orientieren. Es hat kein mentales Modell davon, wer seine Nutzer sind, welche Probleme sie haben oder wie seine Arbeit mit Business-Ergebnissen zusammenhängt. Wenn man das Team bitten würde, morgen eigene Ziele zu setzen, wüsste es nicht, wo es anfangen soll. Nicht weil es nicht klug genug wäre — sondern weil sein Capability Space nie gewachsen ist. Der PO hat ihn klein gehalten, mit den besten Absichten.
Und die Führung? Die Führung hat die Frage nie gestellt, weil es kein Signal gab, sie zu stellen. Keine Beschwerden, keine verpassten Deadlines, keine sichtbare Reibung. Das System sah gesund aus. In Wirklichkeit war es fragil — zusammengehalten durch die Kapazität einer einzelnen Person, Komplexität zu absorbieren, die eigentlich geteilt werden müsste.
Das ist Structural Comfort — kein Versagen, keine Inkompetenz, sondern ein stabiles Gleichgewicht, das Wachstum verhindert. Unsichtbar für alle, die darin stecken, und dauerhaft genug, um Jahre zu bestehen. Es bricht nicht von allein. Es braucht eine Diagnostik, die eine Frage stellt, die niemand im System stellt: Ist der Capability Space dieses Teams mit Outcomes verbunden, die zählen?
The most common path into Structural Comfort is a leadership intervention that solved the wrong problem. Der häufigste Weg in Structural Comfort ist eine Führungsintervention, die das falsche Problem gelöst hat.
Not every team in Structural Comfort started passive. Some of the most capable teams arrive there through a specific sequence — one that begins with real autonomy and ends with its withdrawal.
Consider a product team that talks to users, runs experiments, and frames its work around real problems. The team is trying to work in an outcome-oriented way. It identifies user needs, tests hypotheses, builds solutions based on what it learns. The team's satisfaction is high, and for good reason.
But the company's goal framework doesn't match. OKRs describe activities, not outcomes. The goals the team receives are output-oriented: ship this feature, launch this module, complete this migration. The team knows this. It sees the gap between what it is trying to do — change user behaviour — and what it is being asked to deliver — finished features. So it works around the gap. Internally, it does discovery. Externally, it reports outputs.
Here is the structural problem the team cannot solve alone: outcomes are an organisational achievement, not a team achievement. A team can identify a user problem. It can build a solution. It can test whether users respond differently. But whether user behaviour actually changes at scale — whether retention improves, whether adoption increases, whether a workflow is truly transformed — depends on whether the entire organisation supports that change. Marketing needs to reach the right users. Sales needs to set the right expectations. Service needs to support the new workflow. Operations needs to enable it. A single team can run an experiment. Only the organisation can produce an outcome.
This means that even a team doing excellent discovery work cannot prove that its work generates outcomes — because the infrastructure to measure and attribute outcomes does not exist. The team works outcome-oriented in a system that only measures outputs. Its best work is structurally invisible.
The Compass appears active — and that is part of what makes this state so difficult to diagnose. The team collects user feedback. It shows prototypes. It runs what it calls experiments. But there is a critical difference between feedback collection and assumption testing. Feedback collection asks users what they think. Assumption testing states a hypothesis about what users will do, designs an intervention, and measures whether the predicted behaviour change occurs. Most teams in this state do the former and call it the latter — not because they lack rigour, but because the organisation has never built the infrastructure that real testing requires. Without outcome-oriented goals, there is no hypothesis to test against. Without a chain from business goal to user behaviour, there is no metric that would tell the team whether its experiment actually mattered. The Compass looks strong because the team is busy doing things that resemble testing. But the signal is noise. The direction is unvalidated.
Leadership, meanwhile, senses a discrepancy. The team is engaged, productive, talking about users and experiments — and yet the results don't seem to align with the goals leadership has defined. This perception is correct, but the diagnosis is wrong. The team is not working "past" the goals. The goals are not outcome-oriented. Leadership has never learned to define measurable outcomes, because the organisation has never built the capability to think that way. So the gap feels like a team problem — not a structural one.
Without a diagnostic language that separates direction from autonomy, leadership reaches for the only lever it knows: direct intervention. Requirements appear. Features get specified from above. Approval processes are introduced. "Can you build X — we need it for Y." The intervention is not malicious. It is an attempt to create alignment. But it conflates two different problems. To point the team in the right direction, leadership takes away its ability to navigate.
What happens next depends on the team's stability and how long it has existed. If the team has a Product Owner who begins to absorb the pressure — filtering requirements, translating them into tickets, shielding the team from the raw demands — the system stabilises. The team stops fighting. The PO becomes the buffer. Leadership sees calm. Within months, the pattern has crystallised into the buffer equilibrium described above. Structural Comfort has formed — not because anyone planned it, but because the intervention created the exact conditions for it.
If the team has no buffer, or if it is too experienced to accept the constraint silently, the result is different: frustration, conflict, attrition. The team knows it is being restricted and pushes back. This is painful — but it is the more addressable outcome, because the friction is visible. Visible friction can be diagnosed and resolved. The silent equilibrium of Structural Comfort requires a different kind of diagnostic — one that asks the question the system has stopped asking.
Nicht jedes Team in Structural Comfort hat passiv angefangen. Einige der fähigsten Teams landen dort über eine bestimmte Abfolge — eine, die mit echter Autonomie beginnt und mit ihrem Entzug endet.
Stell dir ein Produktteam vor, das mit Nutzern spricht, Experimente durchführt und seine Arbeit um echte Probleme herum aufbaut. Das Team versucht, outcome-orientiert zu arbeiten. Es identifiziert Nutzerbedürfnisse, testet Hypothesen, baut Lösungen auf Basis dessen, was es lernt. Die Zufriedenheit im Team ist hoch, und das aus gutem Grund.
Aber das Ziel-Framework des Unternehmens passt nicht dazu. OKRs beschreiben Aktivitäten, keine Outcomes. Die Ziele, die das Team erhält, sind output-orientiert: dieses Feature liefern, dieses Modul launchen, diese Migration abschließen. Das Team weiß das. Es sieht die Lücke zwischen dem, was es versucht zu tun — Nutzerverhalten verändern — und dem, was es liefern soll — fertige Features. Also arbeitet es um die Lücke herum. Intern betreibt es Discovery. Nach außen berichtet es Outputs.
Das strukturelle Problem, das das Team allein nicht lösen kann: Outcomes sind eine organisatorische Leistung, keine Team-Leistung. Ein Team kann ein Nutzerproblem identifizieren. Es kann eine Lösung bauen. Es kann testen, ob Nutzer anders reagieren. Aber ob sich Nutzerverhalten tatsächlich im großen Maßstab verändert — ob Retention steigt, ob Adoption zunimmt, ob ein Workflow wirklich transformiert wird — hängt davon ab, ob die gesamte Organisation diesen Wandel unterstützt. Marketing muss die richtigen Nutzer erreichen. Sales muss die richtigen Erwartungen setzen. Service muss den neuen Workflow unterstützen. Operations muss ihn ermöglichen. Ein einzelnes Team kann ein Experiment durchführen. Nur die Organisation kann ein Outcome erzeugen.
Das bedeutet: Selbst ein Team, das exzellente Discovery-Arbeit leistet, kann nicht beweisen, dass seine Arbeit Outcomes erzeugt — weil die Infrastruktur, um Outcomes zu messen und zuzuordnen, nicht existiert. Das Team arbeitet outcome-orientiert in einem System, das nur Outputs misst. Seine beste Arbeit ist strukturell unsichtbar.
Der Compass wirkt aktiv — und genau das macht diesen Zustand so schwer zu diagnostizieren. Das Team sammelt Nutzerfeedback. Es zeigt Prototypen. Es führt durch, was es Experimente nennt. Aber es gibt einen entscheidenden Unterschied zwischen Feedback-Sammlung und Assumption Testing. Feedback-Sammlung fragt Nutzer, was sie denken. Assumption Testing formuliert eine Hypothese darüber, was Nutzer tun werden, designt eine Intervention und misst, ob die vorhergesagte Verhaltensänderung eintritt. Die meisten Teams in diesem Zustand tun Ersteres und nennen es Letzteres — nicht weil ihnen die Sorgfalt fehlt, sondern weil die Organisation die Infrastruktur, die echtes Testen erfordert, nie aufgebaut hat. Ohne outcome-orientierte Ziele gibt es keine Hypothese, gegen die getestet werden kann. Ohne eine Kette vom Business-Ziel zum Nutzerverhalten gibt es keine Metrik, die dem Team sagen würde, ob sein Experiment tatsächlich relevant war. Der Compass sieht stark aus, weil das Team aktiv Dinge tut, die wie Testen aussehen. Aber das Signal ist Rauschen. Die Richtung ist unvalidiert.
Die Führung spürt unterdessen eine Diskrepanz. Das Team ist engagiert, produktiv, spricht über Nutzer und Experimente — und trotzdem scheinen die Ergebnisse nicht mit den Zielen übereinzustimmen, die die Führung definiert hat. Diese Wahrnehmung ist richtig, aber die Diagnose ist falsch. Das Team arbeitet nicht „an den Zielen vorbei". Die Ziele sind nicht outcome-orientiert. Die Führung hat nie gelernt, messbare Outcomes zu definieren, weil die Organisation die Fähigkeit, so zu denken, nie aufgebaut hat. Also fühlt sich die Lücke wie ein Team-Problem an — nicht wie ein strukturelles.
Ohne eine diagnostische Sprache, die Richtung von Autonomie trennt, greift die Führung zum einzigen Hebel, den sie kennt: direkte Intervention. Anforderungen tauchen auf. Features werden von oben spezifiziert. Freigabeprozesse werden eingeführt. „Könnt ihr mal X bauen — wir brauchen das für Y." Die Intervention ist nicht böswillig. Sie ist ein Versuch, Alignment herzustellen. Aber sie vermischt zwei verschiedene Probleme. Um das Team in die richtige Richtung zu lenken, nimmt die Führung ihm die Fähigkeit zu navigieren.
Was dann passiert, hängt von der Stabilität des Teams ab und davon, wie lange es schon existiert. Wenn das Team einen Product Owner hat, der beginnt, den Druck zu absorbieren — Anforderungen filtert, sie in Tickets übersetzt, das Team vor den rohen Demands abschirmt — stabilisiert sich das System. Das Team hört auf zu kämpfen. Der PO wird zum Puffer. Die Führung sieht Ruhe. Innerhalb von Monaten hat sich das Muster zum oben beschriebenen Buffer-Gleichgewicht verfestigt. Structural Comfort ist entstanden — nicht weil irgendjemand es geplant hat, sondern weil die Intervention genau die Bedingungen dafür geschaffen hat.
Wenn das Team keinen Puffer hat, oder wenn es zu erfahren ist, um die Einschränkung still zu akzeptieren, ist das Ergebnis ein anderes: Frustration, Konflikte, Fluktuation. Das Team weiß, dass es eingeschränkt wird, und wehrt sich. Das ist schmerzhaft — aber es ist das adressierbarere Ergebnis, weil die Reibung sichtbar ist. Sichtbare Reibung kann diagnostiziert und gelöst werden. Das stille Gleichgewicht von Structural Comfort braucht eine andere Art von Diagnostik — eine, die die Frage stellt, die das System aufgehört hat zu stellen.
A team believes it is doing Scrum. It has sprints, a Product Owner, reviews, retrospectives. The reviews show what the team built. Stakeholders say "great work" and contribute ideas — which are, in reality, new requirements disguised as collaboration. Nobody asks whether anything the team delivered changed user behaviour. Nobody asks whether the team is working on the right problem. The traffic light would show Green — if you asked the team. But the question that Capability Spaces asks goes deeper: is the team working on opportunities, or on tickets that someone else identified as opportunities?
In many cases, this pattern did not start here. The team may once have worked with real user contact, real experiments, real discovery — and lost it through a well-intentioned intervention that replaced direction with control. The comfort is the end state. The origin is a structural decision that nobody recognised as such.
Ein Team glaubt, es mache Scrum. Es hat Sprints, einen Product Owner, Reviews, Retrospektiven. Die Reviews zeigen, was das Team gebaut hat. Stakeholder sagen „toll gemacht" und bringen Ideen ein — die in Wirklichkeit neue Requirements sind, verpackt als Zusammenarbeit. Niemand fragt, ob irgendetwas, das das Team geliefert hat, Nutzerverhalten verändert hat. Niemand fragt, ob das Team am richtigen Problem arbeitet. Das Ampel-System würde Grün zeigen — wenn man das Team fragt. Aber die Frage, die Capability Spaces stellt, geht tiefer: Arbeitet das Team an Opportunities, oder an Tickets, die jemand anders als Opportunities identifiziert hat?
In vielen Fällen hat dieses Muster nicht hier angefangen. Das Team hatte möglicherweise einmal echten Nutzerkontakt, echte Experimente, echte Discovery — und hat sie durch eine gut gemeinte Intervention verloren, die Richtung durch Kontrolle ersetzt hat. Der Comfort ist der Endzustand. Der Ursprung ist eine strukturelle Entscheidung, die niemand als solche erkannt hat.
Feels safe and productive. Delivers consistently. Has never been confronted with the question of whether its outputs generate outcomes. Measures itself by velocity, not by impact.
Fühlt sich sicher und produktiv, liefert zuverlässig. Wurde nie mit der Frage konfrontiert, ob seine Outputs auch Outcomes erzeugen. Misst sich an Velocity, nicht an Wirkung.
Often the Product Owner. Absorbs all external pressure, translates everything into tickets, and shields the team from complexity. Their identity depends on being the indispensable translator between organisation and team.
Oft der Product Owner. Absorbiert den gesamten externen Druck, übersetzt alles in Tickets und schirmt das Team vor Komplexität ab. Die eigene Identität hängt davon ab, der unverzichtbare Übersetzer zwischen Organisation und Team zu sein.
Receives results, sees no complaints, asks no questions. Has no signal that would trigger action. The absence of friction is mistaken for the presence of health.
Erhält Ergebnisse, sieht keine Beschwerden, stellt keine Fragen. Hat kein Signal, das Handlung auslösen würde. Die Abwesenheit von Reibung wird mit Gesundheit verwechselt.
Shows demos, not outcomes. Stakeholders applaud and contribute ideas. The team feels seen. Nobody asks: did what we built last sprint solve the problem we were trying to solve? The review is not a review. It is a presentation with applause culture.
Zeigt Demos, keine Outcomes. Stakeholder applaudieren und bringen Ideen ein. Das Team fühlt sich gesehen. Niemand fragt: Hat das, was wir letzten Sprint gebaut haben, das Problem gelöst, das wir lösen wollten? Das Review ist kein Review. Es ist eine Präsentation mit Beifallskultur.
A healthy team with a small Capability Space knows its space is small — and can name why. A team in Structural Comfort does not know. It has no reference point. And leadership doesn't either, because it never asked: what could this team achieve if we gave it the room? In many cases, leadership once had the right instinct — the team wasn't aligned — but addressed it by removing autonomy instead of building the connection. The diagnostic question was never asked. A structural decision was made in its place.
Ein gesundes Team mit einem kleinen Capability Space weiß, dass sein Space klein ist — und kann benennen, warum. Ein Team in Structural Comfort weiß es nicht. Es hat keinen Referenzpunkt. Und die Führung auch nicht, weil sie nie gefragt hat: Was könnte dieses Team leisten, wenn wir ihm den Raum gäben? In vielen Fällen hatte die Führung den richtigen Instinkt — das Team war nicht aligned — aber hat ihn adressiert, indem sie Autonomie entzogen hat, statt die Verbindung herzustellen. Die diagnostische Frage wurde nie gestellt. Eine strukturelle Entscheidung wurde an ihrer Stelle getroffen.
Structural Comfort creates a feedback loop that protects itself. Results are "good enough", the team doesn't complain, so there is no signal that would trigger action. This is not a leadership failure in the classic sense — it is a structural pattern in which the organisation's own diagnostic ability is constrained. Leadership has its own Capability Space — and in this area, it is small too.
Structural Comfort erzeugt eine Rückkopplungsschleife, die sich selbst schützt. Die Ergebnisse sind „gut genug", das Team beschwert sich nicht, also gibt es kein Signal, das Handlung auslösen würde. Das ist kein Führungsversagen im klassischen Sinne — es ist ein strukturelles Muster, in dem die Diagnosefähigkeit der Organisation selbst eingeschränkt ist. Führung hat ihren eigenen Capability Space — und der ist in diesem Bereich ebenfalls klein.
It can persist for years — not only until an external shock makes it visible, but precisely because no external shock arrives. The intervention that created the comfort also removed the signals that would reveal it. The team no longer pushes back, because it has stopped trying. The PO no longer escalates, because absorbing complexity has become their identity. Leadership no longer questions, because silence looks like health. The system is stable. That is its danger.
Es kann Jahre bestehen bleiben — nicht nur bis ein externer Schock es sichtbar macht, sondern gerade weil kein externer Schock kommt. Die Intervention, die den Comfort erzeugt hat, hat auch die Signale beseitigt, die ihn sichtbar machen würden. Das Team wehrt sich nicht mehr, weil es aufgehört hat, es zu versuchen. Der PO eskaliert nicht mehr, weil das Absorbieren von Komplexität zu seiner Identität geworden ist. Die Führung hinterfragt nicht mehr, weil Stille nach Gesundheit aussieht. Das System ist stabil. Das ist seine Gefahr.
Map: Extremely small. The team sees tickets, not outcomes. All problem recognition, prioritisation and outcome connection has been absorbed by a single person.
Boundaries: Invisible — because the buffer absorbs them. The dominant boundary is Requirements, packaged as care. This is the most dangerous state: a boundary that feels like service.
Compass: Weak on all four axes. The team has no hypotheses to test, no direct stakeholder connection, and trust exists only as "being left alone" — not as being trusted to identify the right problems.
Map: Extrem klein. Das Team sieht Tickets, keine Outcomes. Die gesamte Problemerkennung, Priorisierung und Outcome-Verknüpfung wurde von einer einzelnen Person absorbiert.
Boundaries: Unsichtbar — weil der Puffer sie absorbiert. Die dominante Boundary ist Requirements, verpackt als Fürsorge. Das ist der gefährlichste Zustand: eine Boundary, die sich wie Service anfühlt.
Compass: Schwach auf allen vier Achsen. Das Team hat keine Hypothesen zum Testen, keine direkte Stakeholder-Verbindung, und Trust existiert nur als „man lässt uns in Ruhe" — nicht als Vertrauen in eigenständige Problemerkennung.
You don't break Structural Comfort by telling the team its review is wrong. The team will not understand, because from its perspective, everything works. You break it by making the structural shape of the comfort visible — through a diagnostic that reads Map, Boundaries and Compass together.
But there is a deeper question: how do you prevent the response to the diagnosis from repeating the pattern that created the comfort in the first place? Leadership's instinct, when confronted with a gap between team output and organisational goals, is to intervene directly — to specify, to require, to control. This instinct is well-documented. Gerwin & Moffat (Management Science, 1997) showed that the withdrawal of team autonomy is negatively correlated with both task and process performance — and that its primary drivers are a lack of shared process understanding and managers' discomfort with delegated authority. The intervention that creates alignment by removing autonomy destroys the conditions that made the team capable in the first place.
The reason this instinct is so persistent is that leadership typically lacks the ability to define the connection it wants. If an organisation has never learned to think in outcomes — if it has no practice of defining business goals as changes in user behaviour, no infrastructure to measure whether those changes occur — then leadership cannot provide direction without providing control. It does not know how to say "here is the outcome we need" and let the team figure out how to get there. It only knows how to say "build this feature."
What Capability Spaces provides is the diagnostic language that separates these two problems. The direction problem — the team's work is not connected to business outcomes — is solved by building the chain: outcome-oriented goals, a clear connection from business goal to stakeholder problem to team objective. This is not just a team-level fix. It requires the organisation to learn something it has never practised: defining success as a change in behaviour, not as a list of deliverables. And it requires acknowledging that outcomes are an organisational achievement — a single team can test a hypothesis, but only the organisation can produce the sustained change in user behaviour that constitutes a real outcome. The autonomy problem — the team needs the freedom to navigate within that chain — is solved by removing Boundaries, not by adding them.
The insight must come from experience, not from instruction. The contrast between what the team does now and what outcome-orientation demands will surface the gap on its own. The role of the diagnostic is to ensure that when the gap becomes visible, the response is a structural connection — not a structural restriction.
Man bricht Structural Comfort nicht auf, indem man dem Team sagt, dass sein Review falsch ist. Das Team wird es nicht verstehen, weil aus seiner Perspektive alles funktioniert. Man bricht es auf, indem man die strukturelle Form des Comforts sichtbar macht — durch eine Diagnostik, die Map, Boundaries und Compass zusammen liest.
Aber es gibt eine tiefere Frage: Wie verhindert man, dass die Reaktion auf die Diagnose genau das Muster wiederholt, das den Comfort überhaupt erzeugt hat? Der Instinkt der Führung, wenn sie mit einer Lücke zwischen Team-Output und Organisationszielen konfrontiert wird, ist direkte Intervention — spezifizieren, anfordern, kontrollieren. Dieser Instinkt ist gut dokumentiert. Gerwin & Moffat (Management Science, 1997) zeigten, dass der Entzug von Team-Autonomie negativ mit Aufgaben- und Prozess-Performance korreliert — und dass seine Haupttreiber fehlendes gemeinsames Prozessverständnis und das Unbehagen von Managern mit delegierter Autorität sind. Die Intervention, die Alignment durch Autonomie-Entzug herstellt, zerstört die Bedingungen, die das Team überhaupt fähig gemacht haben.
Der Grund, warum dieser Instinkt so beständig ist: Die Führung kann die Verbindung, die sie will, typischerweise selbst nicht definieren. Wenn eine Organisation nie gelernt hat, in Outcomes zu denken — wenn sie keine Praxis hat, Business-Ziele als Veränderungen im Nutzerverhalten zu definieren, keine Infrastruktur, um zu messen, ob diese Veränderungen eintreten — dann kann die Führung keine Richtung geben, ohne Kontrolle auszuüben. Sie weiß nicht, wie man sagt „hier ist das Outcome, das wir brauchen" und das Team den Weg finden lässt. Sie weiß nur, wie man sagt „baut dieses Feature."
Was Capability Spaces liefert, ist die diagnostische Sprache, die diese beiden Probleme trennt. Das Richtungsproblem — die Arbeit des Teams ist nicht mit Business-Outcomes verbunden — wird gelöst, indem man die Kette baut: outcome-orientierte Ziele, eine klare Verbindung von Business-Ziel über Stakeholder-Problem zu Team-Objective. Das ist nicht nur ein Fix auf Team-Ebene. Es erfordert, dass die Organisation etwas lernt, das sie nie geübt hat: Erfolg als Verhaltensänderung zu definieren, nicht als Liste von Deliverables. Und es erfordert die Anerkennung, dass Outcomes eine organisatorische Leistung sind — ein einzelnes Team kann eine Hypothese testen, aber nur die Organisation kann die nachhaltige Veränderung im Nutzerverhalten erzeugen, die ein echtes Outcome darstellt. Das Autonomieproblem — das Team braucht die Freiheit, innerhalb dieser Kette zu navigieren — wird gelöst, indem man Boundaries entfernt, nicht indem man sie hinzufügt.
Die Erkenntnis muss aus der Erfahrung kommen, nicht aus Belehrung. Der Kontrast zwischen dem, was das Team jetzt tut, und dem, was Outcome-Orientierung verlangt, macht die Lücke von selbst sichtbar. Die Rolle der Diagnostik ist sicherzustellen, dass wenn die Lücke sichtbar wird, die Reaktion eine strukturelle Verbindung ist — keine strukturelle Einschränkung.
In Overcoming Organizational Defenses (1990) and his earlier HBR article Skilled Incompetence (1986), Argyris describes how organisations develop defensive routines — systematic patterns that make problems invisible, and make the invisibility itself undiscussable. His core insight: the most important problems in organisations are the ones that cannot be talked about, and the fact that they cannot be talked about is also undiscussable. Structural Comfort is what happens when these defensive routines succeed completely: not a single actor experiences friction, so no one initiates diagnosis. Argyris explains why the pattern stays hidden. Capability Spaces provides the diagnostic to make it visible — by reading Map, Boundaries and Compass together, the structural shape of the comfort becomes nameable.
The formation pattern adds a layer to Argyris's analysis: the defensive routine can be created by a leadership intervention. When the organisation withdraws autonomy to enforce alignment, it installs precisely the boundaries that make the resulting constraint undiscussable. The team adapts. The PO absorbs. The discomfort disappears. What remains is a system in which the original problem — the missing connection between team and organisation — has been replaced by a new problem that is harder to see: a team that no longer tries to connect.
In Overcoming Organizational Defenses (1990) und seinem früheren HBR-Artikel Skilled Incompetence (1986) beschreibt Argyris, wie Organisationen Defensive Routines entwickeln — systematische Muster, die Probleme unsichtbar machen und die Unsichtbarkeit selbst undiskutierbar. Seine zentrale Erkenntnis: Die wichtigsten Probleme in Organisationen sind die, über die nicht gesprochen werden kann — und die Tatsache, dass nicht darüber gesprochen werden kann, ist ebenfalls undiskutierbar. Structural Comfort ist das, was passiert, wenn diese Defensive Routines vollständig gelingen: Kein einziger Akteur erlebt Reibung, also initiiert niemand eine Diagnose. Argyris erklärt, warum das Muster verborgen bleibt. Capability Spaces liefert die Diagnostik, um es sichtbar zu machen — indem Map, Boundaries und Compass zusammen gelesen werden, wird die strukturelle Form des Comforts benennbar.
Das Entstehungsmuster fügt Argyris' Analyse eine Ebene hinzu: Die Defensive Routine kann durch eine Führungsintervention erzeugt werden. Wenn die Organisation Autonomie entzieht, um Alignment zu erzwingen, installiert sie genau die Boundaries, die die resultierende Einschränkung undiskutierbar machen. Das Team passt sich an. Der PO absorbiert. Das Unbehagen verschwindet. Was bleibt, ist ein System, in dem das ursprüngliche Problem — die fehlende Verbindung zwischen Team und Organisation — durch ein neues Problem ersetzt wurde, das schwerer zu sehen ist: ein Team, das nicht mehr versucht, sich zu verbinden.
In Channeled Autonomy (Journal of Management, 2016), Gonzalez-Mulé, Courtright, DeGeest, Seong & Hong studied 110 teams in a manufacturing firm and found that the effect of autonomy on team performance is not linear — it depends entirely on whether the team has clarity about the organisation's goals. Autonomous teams with high performance feedback outperformed all other configurations, because the feedback channeled their autonomy toward organisational goals. Autonomous teams without that feedback performed at the lowest levels — worse than teams with low autonomy — because they lacked the reference point to connect their work to what the organisation needed.
This maps directly onto Capability Spaces. The chain from business goal to stakeholder problem to team objective is the feedback mechanism that Gonzalez-Mulé describes. When it is missing, the team has autonomy without direction — and the predictable management response, documented by Gerwin & Moffat (Management Science, 1997), is to withdraw autonomy rather than build the chain. Capability Spaces diagnoses whether the chain exists, where it breaks, and what needs to change — so that leadership can channel the team's autonomy instead of withdrawing it.
In Channeled Autonomy (Journal of Management, 2016) untersuchten Gonzalez-Mulé, Courtright, DeGeest, Seong & Hong 110 Teams in einem Industrieunternehmen und fanden, dass die Wirkung von Autonomie auf Team-Performance nicht linear ist — sie hängt vollständig davon ab, ob das Team Klarheit über die Organisationsziele hat. Autonome Teams mit hohem Performance-Feedback übertrafen alle anderen Konfigurationen, weil das Feedback ihre Autonomie in Richtung der Organisationsziele kanalisierte. Autonome Teams ohne dieses Feedback performten am schlechtesten — schlechter als Teams mit niedriger Autonomie — weil ihnen der Referenzpunkt fehlte, um ihre Arbeit mit dem zu verbinden, was die Organisation brauchte.
Das überträgt sich direkt auf Capability Spaces. Die Kette von Business-Ziel über Stakeholder-Problem zu Team-Objective ist der Feedback-Mechanismus, den Gonzalez-Mulé beschreibt. Wenn sie fehlt, hat das Team Autonomie ohne Richtung — und die vorhersagbare Management-Reaktion, dokumentiert von Gerwin & Moffat (Management Science, 1997), ist der Entzug von Autonomie statt des Aufbaus der Kette. Capability Spaces diagnostiziert, ob die Kette existiert, wo sie bricht und was sich ändern muss — damit die Führung die Autonomie des Teams kanalisieren kann, statt sie zu entziehen.
"But some people just don't want to change. They want tickets, not problems. They want to clock in, execute, clock out." — This is a real observation. The question is what it means. Three layers:
Layer 1: Learned helplessness. Most people who "just want tickets" didn't start that way. They were shaped by years in structures that neither rewarded nor permitted independent thinking. When a system prevents someone from making decisions long enough, they stop trying. Seligman called this learned helplessness. Reading it as a character trait rather than a system outcome is the classic attribution error — and it protects the structure from scrutiny.
Layer 2: Fit, not failure. Some people genuinely prefer executing clearly defined tasks. That is a legitimate preference — but it is not the profile a product team needs. A team that is expected to produce outcomes needs people who want to think about problems. This is not a moral judgement. It is a staffing question. That person might thrive in a well-defined operations or support role — and be happier there too.
Layer 3: The structural signal. When multiple people in a team think this way, it is almost never a hiring problem. It is a signal that the organisation has rewarded the opposite of ownership for a long time. The question "are they good employees?" distracts from the actual problem: what did the structure do to them?
„Aber manche Leute wollen sich gar nicht verändern. Die wollen Tickets, keine Probleme. Die wollen reinkommen, abarbeiten, Feierabend." — Das ist eine reale Beobachtung. Die Frage ist, was sie bedeutet. Drei Ebenen:
Ebene 1: Erlernte Hilflosigkeit. Die meisten Menschen, die „einfach nur Tickets wollen", haben nicht so angefangen. Sie wurden durch Jahre in Strukturen geprägt, die eigenständiges Denken weder belohnt noch zugelassen haben. Wenn ein System lange genug verhindert, dass jemand eigene Entscheidungen trifft, hört die Person auf, es zu versuchen. Seligman nannte das erlernte Hilflosigkeit. Das als Charaktereigenschaft zu lesen statt als Systemergebnis ist der klassische Attributionsfehler — und er schützt die Struktur vor jeder Überprüfung.
Ebene 2: Passung, nicht Versagen. Manche Menschen bevorzugen tatsächlich klar definierte Aufgaben. Das ist eine legitime Präferenz — aber nicht das Profil, das ein Produktteam braucht. Ein Team, das Outcomes erzeugen soll, braucht Menschen, die über Probleme nachdenken wollen. Das ist kein moralisches Urteil. Es ist eine Besetzungsfrage. Diese Person wäre in einem klar strukturierten Betriebs- oder Supportteam möglicherweise hervorragend aufgehoben — und dort auch zufriedener.
Ebene 3: Das strukturelle Signal. Wenn mehrere Menschen in einem Team so denken, ist das fast nie ein Recruiting-Problem. Es ist ein Signal, dass die Organisation über längere Zeit das Gegenteil von Eigenverantwortung belohnt hat. Die Frage „Sind das gute Mitarbeiter?" lenkt vom eigentlichen Problem ab: Was hat die Struktur mit diesen Menschen gemacht?
Outcomes are always changes in human behaviour. A user who completes a registration without confusion — that is an outcome. A customer who changes how they make decisions because of your product — that is also an outcome. The first is expected. The second might be innovative. Both require user-centred work. But they require different levels of organisational maturity, and they carry different levels of risk.
Outcomes sind immer Veränderungen im menschlichen Verhalten. Ein Nutzer, der eine Registrierung ohne Verwirrung abschließt — das ist ein Outcome. Ein Kunde, der aufgrund deines Produkts anders entscheidet — das ist auch ein Outcome. Das Erste wird erwartet. Das Zweite könnte innovativ sein. Beides erfordert nutzerzentriertes Arbeiten. Aber beides erfordert unterschiedliche organisatorische Reife und birgt unterschiedliches Risiko.
Login, registration, navigation, profile settings — these are industry-standard interactions. Every user has seen them a thousand times. Building them well is outcome-oriented work: the goal is an intuitive experience where pain points, desires, and usability problems never make it into the product in the first place. The team builds closely with users — not to innovate, but to eliminate friction before it exists.
The purpose is also economic: by building the foundation in close collaboration with users, the team minimises the need to react later — to rework, to fix, to rebuild what should have been right from the start. The goal is to push technical debt toward zero, so that when the product reaches the point where its core hypothesis can be tested, the team is free to do that work.
Every product rests on a hypothesis — a belief that a specific change in user behaviour is possible and valuable. But this hypothesis is not testable until the foundation is solid. A closed beta is typically the first moment where the organisation can observe whether the product idea works — whether users actually do something differently because the product exists.
This is also the moment of highest risk. The organisation has invested significantly — in design, engineering, infrastructure — before it has evidence that the core hypothesis holds. Eric Ries called the unit of progress in this phase validated learning: not features shipped, but truths discovered about whether the business model is viable (The Lean Startup, 2011). The risk of burning capital before product-market fit is not avoidable — it is the defining characteristic of product development. What is avoidable is burning it without learning.
If the validation phase confirms the hypothesis — users do something differently, and that difference creates business value — the product enters the phase where innovation becomes possible. This is scientific work: observation, measurement, experimentation, and the willingness to be wrong. The outcomes being pursued are not yet established, not yet proven, and not yet a pattern anyone can copy.
Not every product reaches this phase. And not every product needs to. An application whose core experience consists entirely of established interactions may deliver outcomes without ever being innovative. That is not a failure — but it is a strategic choice that should be made consciously, not by default.
The product is established. Customers are reasonably satisfied. The team delivers. Leadership sees no signal to act. This is where Structural Comfort becomes most dangerous — because there is no visible crisis that would trigger a diagnosis.
The common objection at this stage is: "We don't have room for innovation anymore." Research tells a different story. Dougherty & Hardy studied 15 firms averaging 96 years of age and found that the primary obstacle to sustained innovation was not lack of ideas — it was the inability to connect new products with organisational resources, processes, and strategy (Academy of Management Journal, 1996). The innovators lacked the power to make these connections. That is a Capability Space problem.
Christensen's The Innovator's Dilemma (1997) showed that the threat to established products does not come from within. It comes from below — from simpler, cheaper alternatives that mature organisations dismiss until it is too late. A product in Structural Comfort is not safe because it has no competitors. It is exposed precisely because it has stopped asking the question that would reveal them.
The question is not whether a mature product should pursue outcomes. The question is whether it still can — or whether technical debt, Structural Comfort, and years of output-oriented work have made outcome-oriented thinking structurally impossible. Capability Spaces answers that question.
There is a common reflex at this stage that feels like a response to competition but accelerates the problem: copying features from competitors. A rival launches a new capability. Leadership says "we need that too." The team builds it. The feature ships. Nobody asks whether the competitor's feature actually worked — whether it changed user behaviour, whether it drove retention, whether it solved a real problem. The team has no data on the competitor's outcomes, only on their output. By copying the output, the organisation imports someone else's hypothesis without testing it — and deepens its own Feature Factory pattern. Worse: the one advantage a mature product has over its competitors — deep knowledge of its own users — is the one thing this reflex never activates. The team copies what it can see (features) and ignores what it already has (user understanding). Each copied feature adds complexity, increases technical debt, and moves the team further from the work that would actually differentiate the product. The competitive response that looks like action is, structurally, the opposite of it.
Login, Registrierung, Navigation, Profil-Einstellungen — das sind Industrie-Standard-Interaktionen. Jeder Nutzer hat sie tausendmal gesehen. Sie gut zu bauen ist outcome-orientierte Arbeit: Das Ziel ist ein intuitives Erlebnis, bei dem Pain Points, Desires und Usability-Probleme gar nicht erst ins Produkt gelangen. Das Team baut eng mit Nutzern — nicht um zu innovieren, sondern um Reibung zu eliminieren, bevor sie entsteht.
Der Zweck ist auch ökonomisch: Indem man die Grundlage in enger Zusammenarbeit mit Nutzern baut, minimiert das Team die Notwendigkeit, später zu reagieren — nachzuarbeiten, zu reparieren, neu zu bauen. Das Ziel ist, technische Schulden gegen Null zu drücken, damit das Team frei ist für die eigentliche Arbeit, wenn die Kernhypothese testbar wird.
Jedes Produkt basiert auf einer Hypothese — der Überzeugung, dass eine bestimmte Veränderung im Nutzerverhalten möglich und wertvoll ist. Aber diese Hypothese ist erst testbar, wenn die Grundlage steht. Eine Closed Beta ist typischerweise der erste Moment, in dem die Organisation beobachten kann, ob die Produktidee funktioniert — ob Nutzer tatsächlich etwas anders machen, weil das Produkt existiert.
Das ist auch der Moment des höchsten Risikos. Die Organisation hat erheblich investiert — in Design, Engineering, Infrastruktur — bevor sie Evidenz hat, dass die Kernhypothese trägt. Eric Ries nannte den Fortschrittsmaßstab in dieser Phase Validated Learning: nicht gelieferte Features, sondern entdeckte Wahrheiten darüber, ob das Geschäftsmodell tragfähig ist (The Lean Startup, 2011). Das Risiko, Kapital vor dem Product-Market Fit zu verbrennen, ist nicht vermeidbar — es ist das definierende Merkmal von Produktentwicklung. Was vermeidbar ist, ist es ohne Lernen zu verbrennen.
Wenn die Validierungsphase die Hypothese bestätigt — Nutzer tun etwas anders, und dieser Unterschied erzeugt Business-Wert — tritt das Produkt in die Phase ein, in der Innovation möglich wird. Das ist wissenschaftliche Arbeit: Beobachtung, Messung, Experimentation und die Bereitschaft, falsch zu liegen. Die angestrebten Outcomes sind noch nicht etabliert, noch nicht bewiesen und noch nicht als Pattern kopierbar.
Nicht jedes Produkt erreicht diese Phase. Und nicht jedes muss es. Eine Anwendung, deren Kernerlebnis vollständig aus etablierten Interaktionen besteht, kann Outcomes liefern, ohne je innovativ zu sein. Das ist kein Versagen — aber es ist eine strategische Entscheidung, die bewusst getroffen werden sollte, nicht aus Versehen.
Das Produkt ist etabliert. Kunden sind einigermaßen zufrieden. Das Team liefert. Die Führung sieht kein Signal zum Handeln. Hier wird Structural Comfort am gefährlichsten — weil es keine sichtbare Krise gibt, die eine Diagnose auslösen würde.
Der häufigste Einwand in dieser Phase: „Wir haben keinen Raum mehr für Innovation." Die Forschung erzählt eine andere Geschichte. Dougherty & Hardy untersuchten 15 Unternehmen mit durchschnittlich 96 Jahren und fanden, dass das Haupthindernis für nachhaltige Innovation nicht fehlende Ideen waren — sondern die Unfähigkeit, neue Produkte mit den Ressourcen, Prozessen und der Strategie der Organisation zu verbinden (Academy of Management Journal, 1996). Die Innovatoren hatten nicht die Macht, diese Verbindungen herzustellen. Das ist ein Capability-Space-Problem.
Christensens The Innovator's Dilemma (1997) zeigte, dass die Bedrohung für etablierte Produkte nicht von innen kommt. Sie kommt von unten — von einfacheren, günstigeren Alternativen, die reife Organisationen so lange ignorieren, bis es zu spät ist. Ein Produkt in Structural Comfort ist nicht sicher, weil es keine Konkurrenten hat. Es ist exponiert, weil es aufgehört hat, die Frage zu stellen, die sie sichtbar machen würde.
Die Frage ist nicht, ob ein reifes Produkt Outcomes verfolgen sollte. Die Frage ist, ob es das noch kann — oder ob technische Schulden, Structural Comfort und Jahre output-orientierter Arbeit outcome-orientiertes Denken strukturell unmöglich gemacht haben. Capability Spaces beantwortet diese Frage.
Es gibt einen verbreiteten Reflex in dieser Phase, der sich wie eine Reaktion auf Konkurrenz anfühlt, das Problem aber beschleunigt: Features von Wettbewerbern kopieren. Ein Konkurrent launcht eine neue Funktion. Die Führung sagt „Das brauchen wir auch." Das Team baut es. Das Feature wird ausgeliefert. Niemand fragt, ob das Feature beim Konkurrenten tatsächlich funktioniert hat — ob es Nutzerverhalten verändert, Retention getrieben oder ein echtes Problem gelöst hat. Das Team hat keine Daten über die Outcomes des Konkurrenten, nur über dessen Output. Indem es den Output kopiert, importiert die Organisation die Hypothese eines anderen, ohne sie zu testen — und vertieft das eigene Feature-Factory-Muster. Schlimmer noch: Der eine Vorteil, den ein reifes Produkt gegenüber seinen Wettbewerbern hat — tiefes Wissen über die eigenen Nutzer — wird durch diesen Reflex nie aktiviert. Das Team kopiert, was es sehen kann (Features), und ignoriert, was es bereits hat (Nutzerverständnis). Jedes kopierte Feature erhöht die Komplexität, vergrößert die technischen Schulden und entfernt das Team weiter von der Arbeit, die das Produkt tatsächlich differenzieren würde. Die Wettbewerbsreaktion, die nach Handeln aussieht, ist strukturell das Gegenteil davon.
Every product is somewhere on this curve. Capability Spaces does not prescribe where a product should be — it diagnoses where it is, and whether the organisation's structure matches the demands of that phase. A team in Phase 1 needs user proximity and freedom from unnecessary process. A team in Phase 2 needs the right to fail. A team in Phase 3 needs outcome-oriented goals and the infrastructure to measure them. A team in Phase 4 needs a diagnostic that asks the question it has stopped asking itself. The structural requirements change. Capability Spaces makes the mismatch visible.
Jedes Produkt befindet sich irgendwo auf dieser Kurve. Capability Spaces schreibt nicht vor, wo ein Produkt sein sollte — es diagnostiziert, wo es ist, und ob die Struktur der Organisation zu den Anforderungen dieser Phase passt. Ein Team in Phase 1 braucht Nutzernähe und Freiheit von unnötigem Prozess. Ein Team in Phase 2 braucht das Recht zu scheitern. Ein Team in Phase 3 braucht outcome-orientierte Ziele und die Infrastruktur, um sie zu messen. Ein Team in Phase 4 braucht eine Diagnostik, die die Frage stellt, die es selbst nicht mehr stellt. Die strukturellen Anforderungen ändern sich. Capability Spaces macht den Mismatch sichtbar.
There is a widespread belief that agile ends at the product team. That platform teams, security teams, or infrastructure teams work differently – by nature, by necessity, or by choice. This belief is wrong.
Every team has stakeholders. Every team is expected to solve problems for those stakeholders. And every solved problem contributes to a product goal – whether that product is a customer-facing application, a developer platform, or a company-wide security posture. The moment you accept this, the question changes: not are we agile? but can we work on the problems that actually matter to the people we serve?
With this mindset, every team that touches a product organisation is itself a product team. And that means Capability Spaces applies everywhere – not just in the stream-aligned team, but in the platform team, the enabling team, the security function.
Their problem: slow deployment cycles, brittle pipelines, dependency on operations. The platform team solves this – and their product goal is developer productivity and autonomy.
Outcome: teams ship independently, without waiting for ops.Their problem: vulnerabilities that reach production, compliance risk, teams that bypass security because it slows them down. The security team's product goal is a secure organisation that doesn't trade speed for safety.
Outcome: security is embedded in delivery, not a gate after it.Their problem: teams lack a specific capability – testing, accessibility, data literacy. The enabling team closes that gap and works itself out of the dependency.
Outcome: stream-aligned teams operate autonomously with the new capability.Platform and security teams often struggle not because their people lack skill – but because their organisational structure prevents them from working on the right problems. They receive tickets instead of problem statements. They are measured on output, not on whether the problems they solve actually change anything for their stakeholders. That is a Boundary problem. And Capability Spaces can name it.
Apply Capability Spaces to a typical security function and a clear pattern emerges. The security team has a Map: there are real problems to solve. But their Space is narrow – role definitions restrict what they can act on, processes require sign-off chains that slow everything down, requirements arrive as compliance checklists rather than problem statements. Their Compass is weak: the team doesn't see how their work connects to what the organisation is actually trying to achieve.
The result is predictable. Security becomes a gate, not a capability. Teams route around it. Vulnerabilities compound. Leadership blames culture. But the diagnosis is structural: the security team was never in a position to solve the actual problems it was created to solve.
Security is only consulted at the end of a release cycle. The team has no mandate to intervene earlier, even when they see the risk forming.
→ Vulnerabilities that could have been caught in design reach production.Every security requirement requires a formal risk assessment sign-off. The process was designed for annual audits, not continuous delivery.
→ Teams bypass security reviews to hit their release dates.Work arrives as compliance tasks ("implement MFA for all users") with no problem statement attached. The team builds features, not solutions.
→ MFA gets shipped. The actual attack vector it was meant to close remains open.When Capability Spaces is used to develop the security team into a genuine enabling team – one that embeds capability into product teams rather than acting as a gate – something unexpected happens. Security gets better. But more importantly: the real boundaries in the rest of the organisation become visible for the first time.
Once security can actually offer help, the product teams' response reveals the underlying dynamic. Security topics don't disappear from backlogs – they get deprioritised. Features get "re-prioritised in" by leadership. Security work is repeatedly displaced by what the organisation signals is more important right now.
This is a Requirements Boundary – but it sits with the product team, not the security team. Leadership's prioritisation decisions override what the team itself identified as the right problem to work on. Security is not blocked by its own structure anymore. It is blocked by how the organisation values security relative to feature delivery. Capability Spaces makes this shift of accountability visible: the constraint is no longer in the security function – it is in the product organisation and the decisions made above it.
This is what real organisational development looks like. Not a security initiative. Not a training programme. A diagnosis that shows where decisions are actually being made – and whether those decisions align with what the organisation says it values.
Es gibt einen weit verbreiteten Irrglauben: dass agiles Arbeiten beim Produktteam aufhört. Dass Platform Teams, Security Teams oder Infrastructure Teams von Natur aus anders arbeiten — oder es zumindest müssen. Das stimmt nicht.
Jedes Team hat Stakeholder. Jedes Team soll für diese Stakeholder Probleme lösen. Und jedes gelöste Problem zahlt auf ein Produktziel ein – ob dieses Produkt eine kundenseitige Anwendung ist, eine Developer-Plattform oder eine unternehmensweite Security-Posture. Wer das akzeptiert, stellt die Frage anders: nicht sind wir agil? sondern arbeiten wir an dem, was für unsere Nutzer wirklich zählt?
Mit diesem Verständnis ist jedes Team, das Teil einer Produktorganisation ist, selbst ein Produktteam. Und das bedeutet: Capability Spaces gilt überall – nicht nur im stream-aligned Team, sondern auch im Platform Team, im Enabling Team, in der Security-Funktion.
Ihr Problem: langsame Deployment-Zyklen, brüchige Pipelines, Abhängigkeit von Operations. Das Platform Team löst das – ihr Produktziel ist Entwicklerproduktivität und Autonomie.
Outcome: Teams liefern eigenständig, ohne auf Ops zu warten.Ihr Problem: Schwachstellen, die in Produktion gelangen, Compliance-Risiken, Teams, die Security umgehen, weil sie verlangsamt werden. Das Produktziel des Security Teams ist eine sichere Organisation, die Geschwindigkeit nicht gegen Sicherheit tauscht.
Outcome: Security ist Teil der Lieferung, kein Gate danach.Ihr Problem: Teams fehlt eine spezifische Fähigkeit – Testing, Accessibility, Datenkompetenz. Das Enabling Team schließt diese Lücke und arbeitet sich selbst aus der Abhängigkeit heraus.
Outcome: Stream-aligned Teams operieren eigenständig mit der neuen Fähigkeit.Platform- und Security-Teams scheitern oft nicht an mangelnder Kompetenz — sondern weil ihre Organisationsstruktur verhindert, dass sie an den richtigen Problemen arbeiten. Sie erhalten Tickets statt Problemformulierungen. Sie werden an Output gemessen, nicht daran, ob die gelösten Probleme bei ihren Stakeholdern etwas verändert haben. Das ist ein Boundary-Problem. Und Capability Spaces kann es benennen.
Wendet man Capability Spaces auf eine typische Security-Funktion an, zeigt sich ein klares Muster. Das Security Team hat eine Map: Es gibt echte Probleme zu lösen. Aber ihr Space ist eng – Rollendefinitionen schränken ein, was sie tatsächlich angehen dürfen, Prozesse erfordern Freigabeketten, die alles verlangsamen, Anforderungen kommen als Compliance-Checklisten statt als Problemformulierungen an. Ihr Compass ist schwach: Das Team sieht nicht, wie ihre Arbeit mit dem zusammenhängt, was die Organisation tatsächlich erreichen will.
Das Ergebnis ist vorhersehbar. Security wird zum Gate, nicht zur Fähigkeit. Teams umgehen sie. Schwachstellen häufen sich. Führung gibt der Kultur die Schuld. Aber die Diagnose ist strukturell: Das Security Team war nie in der Lage, die eigentlichen Probleme zu lösen, für die es geschaffen wurde.
Security wird erst am Ende eines Release-Zyklus konsultiert. Das Team hat kein Mandat, früher einzugreifen – auch wenn es das Risiko schon in der Entstehung sieht.
→ Schwachstellen, die im Design hätten erkannt werden können, erreichen Produktion.Jede Security-Anforderung braucht ein formales Risk-Assessment-Sign-off. Der Prozess wurde für Jahresaudits entworfen, nicht für Continuous Delivery.
→ Teams umgehen Security-Reviews, um ihre Release-Termine zu halten.Arbeit kommt als Compliance-Aufgabe an („MFA für alle Nutzer einführen") – ohne Problemformulierung. Das Team baut Features, keine Lösungen.
→ MFA wird geliefert. Der eigentliche Angriffsvektor, den es schließen sollte, bleibt offen.Wenn Capability Spaces genutzt wird, um das Security Team in ein echtes Enabling Team zu entwickeln – eines, das Fähigkeiten in Produktteams einbettet, statt als Gate zu fungieren – passiert etwas Unerwartetes. Security wird besser. Aber noch wichtiger: Die eigentlichen Boundaries im Rest der Organisation werden erstmals sichtbar.
Sobald Security echte Unterstützung anbieten kann, zeigt die Reaktion der Produktteams die tatsächliche Dynamik. Security-Themen verschwinden nicht aus den Backlogs — sie rutschen nach unten. Features werden von der Führung nach oben geschoben. Security-Arbeit wird systematisch verdrängt von dem, was die Organisation gerade für wichtiger hält.
Das ist eine Requirements Boundary — aber sie sitzt beim Produktteam, nicht beim Security Team. Die Prioritätsentscheidungen der Führung überstimmen, was das Team selbst als das richtige Problem erkannt hat. Security ist nicht mehr durch die eigene Struktur blockiert. Sie ist blockiert durch die Art, wie die Organisation Security gegenüber Feature-Delivery gewichtet. Capability Spaces macht diese Verschiebung der Verantwortung sichtbar: Der Constraint liegt nicht mehr in der Security-Funktion – er liegt in der Produktorganisation und in den Entscheidungen, die darüber getroffen werden.
So sieht echte Organisationsentwicklung aus. Keine Security-Initiative. Kein Trainingsprogramm. Eine Diagnose, die zeigt, wo Entscheidungen tatsächlich getroffen werden – und ob diese Entscheidungen mit dem übereinstimmen, was die Organisation zu wollen behauptet.
If you're not deeply familiar with agile frameworks, here's what they each do – and where they all share the same blind spot.
Du musst nicht alle agilen Frameworks kennen. Hier ein kurzer Überblick: was sie jeweils leisten — und wo sie alle denselben blinden Fleck teilen.
Organises teamwork into short cycles (Sprints). Roles, ceremonies, artefacts are predefined. The Scrum Master removes obstacles that get escalated.
Organisiert Teamarbeit in kurzen Zyklen (Sprints). Rollen, Zeremonien und Artefakte sind vordefiniert. Der Scrum Master räumt eskalierte Hindernisse aus dem Weg.
Visualises work in progress. Limits how many tasks run in parallel to reduce overload and surface bottlenecks in the workflow.
Macht laufende Arbeit sichtbar. Begrenzt parallele Aufgaben, um Überlastung zu reduzieren und Engpässe im Workflow sichtbar zu machen.
Coordinates multiple teams working on the same product. Adds planning cycles, roles and governance layers so large organisations can move together.
Koordiniert mehrere Teams, die am selben Produkt arbeiten. Fügt Planungszyklen, Rollen und Governance-Ebenen hinzu, damit große Organisationen synchron agieren können.
Aligns teams around shared outcomes. Separates objectives (direction) from key results (measurable progress). Used in parallel with any agile method.
Richtet Teams auf gemeinsame Outcomes aus. Trennt Ziele (Richtung) von Schlüsselergebnissen (messbarer Fortschritt). Wird parallel zu agilen Methoden eingesetzt.
Describes how to structure teams to minimise cognitive load and reduce dependencies. Defines team types and interaction patterns.
Beschreibt, wie Teams strukturiert werden sollten, um kognitive Belastung zu minimieren und Abhängigkeiten zu reduzieren. Definiert Teamtypen und Interaktionsmuster.
Sits on top of any framework you already use. Doesn't replace Scrum, Kanban, SAFe or OKR. Instead it diagnoses why the framework you have isn't delivering – and shows exactly which structural conditions need to change.
Legt sich über jedes Framework, das du bereits verwendest. Ersetzt weder Scrum noch Kanban, SAFe oder OKR. Stattdessen diagnostiziert es, warum dein Framework nicht liefert – und zeigt genau, welche strukturellen Bedingungen sich ändern müssen.
Every framework above assumes the organisation is structurally ready to let teams work on the right problems. None of them diagnoses whether that precondition exists. That is exactly what Capability Spaces does — regardless of which framework you use.
Jedes der obigen Frameworks setzt voraus, dass die Organisation strukturell bereit ist, Teams an den richtigen Problemen arbeiten zu lassen. Keines diagnostiziert, ob diese Voraussetzung überhaupt gegeben ist. Genau das tut Capability Spaces – unabhängig davon, welches Framework du verwendest.
Teresa Torres says: "Teams should do continuous discovery." Capability Spaces says: here is why this specific team structurally cannot — and who needs to change that.
Jeff Gothelf says: "OKRs should be aligned, not cascaded." Capability Spaces says: if the Map is missing, it does not matter how well your OKRs are set up.
This is not a summary of the literature. It is a meta-level — a diagnostic framework that explains why the known solutions are not working.
Teresa Torres sagt: „Teams sollten kontinuierlich Discovery betreiben." Capability Spaces sagt: Hier ist der Grund, warum dieses konkrete Team das strukturell nicht kann — und wer das ändern muss.
Jeff Gothelf sagt: „OKRs sollten ausgerichtet, nicht kaskadiert werden." Capability Spaces sagt: Wenn die Map fehlt, ist es egal, wie gut deine OKRs aufgesetzt sind.
Das ist keine Zusammenfassung der Literatur. Es ist eine Metaebene — ein Diagnoserahmen, der erklärt, warum die bekannten Lösungen nicht greifen.
Capability Spaces was developed in agile contexts – Scrum teams, OKR cycles, product organisations. But what it actually diagnoses has nothing to do with agile. It diagnoses a universal question: can a unit within an organisation independently identify and solve the problems that create the most value?
Capability Spaces wurde in agilen Kontexten entwickelt – Scrum-Teams, OKR-Zyklen, Produktorganisationen. Aber was es tatsächlich diagnostiziert, hat nichts mit Agilität zu tun. Es diagnostiziert eine universelle Frage: Kann eine Einheit innerhalb einer Organisation eigenständig die Probleme erkennen und lösen, die den größten Wert schaffen?
That question applies to a product team deciding which user problem to solve next. It applies equally to a nursing ward that sees a broken treatment process but isn't authorised to change it. To a legal department that knows which contracts create the most risk but must follow a review process designed for a different era. To a sales team that recognises an underserved customer segment but can only sell what's in the catalogue.
Diese Frage gilt für ein Produktteam, das entscheidet, welches Nutzerproblem es als nächstes löst. Sie gilt genauso für eine Pflegestation, die einen kaputten Behandlungspfad sieht, aber nicht befugt ist, ihn zu ändern. Für eine Rechtsabteilung, die weiß, welche Verträge das größte Risiko bergen, aber einem Prüfprozess folgen muss, der für eine andere Zeit gemacht wurde. Für ein Vertriebsteam, das ein unterversorgtes Kundensegment erkennt, aber nur verkaufen darf, was im Katalog steht.
The scope within which a unit can independently recognise problems and act on them. In a hospital: which treatment decisions can a ward make autonomously? In a government agency: which processes can a department improve without escalating? In sales: which customer problems can the team solve beyond what's prescribed?
Der Bereich, in dem eine Einheit eigenständig Probleme erkennen und bearbeiten kann. Im Krankenhaus: Welche Behandlungsentscheidungen kann eine Station autonom treffen? In einer Behörde: Welche Prozesse kann eine Abteilung verbessern, ohne zu eskalieren? Im Vertrieb: Welche Kundenprobleme kann das Team über das Vorgeschriebene hinaus lösen?
The structural constraints that limit the Map – present in every organisation, not just agile ones. A nurse who can't change a process that harms patients: Process boundary. A civil servant who knows a form is pointless but can't alter it: Rules boundary. A manager told to "be more innovative" but given no authority over budgets: Roles boundary. A team that receives solutions instead of problems: Requirements boundary.
Die strukturellen Einschränkungen, die die Map begrenzen – vorhanden in jeder Organisation, nicht nur in agilen. Eine Pflegekraft, die einen Prozess nicht ändern kann, der Patienten schadet: Prozess-Boundary. Ein Sachbearbeiter, der weiß, dass ein Formular sinnlos ist, es aber nicht ändern darf: Regeln-Boundary. Eine Führungskraft, die „innovativer sein" soll, aber keine Budgethoheit hat: Rollen-Boundary. Ein Team, das Lösungen statt Probleme erhält: Requirements-Boundary.
The four forces that expand the Map from outside – equally universal. Does leadership trust this unit enough to grant it autonomy? Does the unit get real feedback on whether its work makes a difference? Does it build knowledge that makes problems more solvable? Does good work open doors to new, meaningful problems?
Die vier Kräfte, die die Map von außen erweitern – ebenfalls universal. Vertraut die Führung dieser Einheit genug, um ihr Autonomie zu gewähren? Bekommt die Einheit echtes Feedback, ob ihre Arbeit etwas bewirkt? Baut sie Wissen auf, das Probleme besser lösbar macht? Öffnet gute Arbeit Türen zu neuen, bedeutsamen Problemen?
In non-agile organisations, Structural Comfort is not a defect – it is the design. The department head filters. The employees execute. Management receives reports. Nobody experiences friction. The system functions – until the environment changes and nobody understands why the organisation can't respond. The diagnosis is the same. Only the vocabulary changes.
In nicht-agilen Organisationen ist Structural Comfort kein Defekt – es ist das Design. Der Abteilungsleiter filtert, die Mitarbeiter führen aus, die Geschäftsführung erhält Berichte — und niemand erlebt Reibung. Das System funktioniert, bis sich die Umgebung verändert und niemand versteht, warum die Organisation nicht reagieren kann. Die Diagnose ist dieselbe, nur das Vokabular ändert sich.
In a flat organisation, a CEO can act as Boundary Owner directly – one conversation, one decision, one shift. In an organisation with six hierarchy levels, the Boundary is five layers removed from the person who could resolve it. Each layer absorbs, filters, reformulates – and generates its own Structural Comfort in the process. Middle management is not the problem. It is the largest buffer in the system. And it has the strongest interest in self-preservation, because its existence depends on the translation work between top and bottom being needed.
In einer flachen Organisation kann ein CEO direkt als Boundary Owner handeln – ein Gespräch, eine Entscheidung, eine Verschiebung. In einer Organisation mit sechs Hierarchieebenen ist die Boundary fünf Stufen von der Person entfernt, die sie auflösen könnte. Jede Stufe absorbiert, filtert, reformuliert – und erzeugt dabei ihren eigenen Structural Comfort. Das mittlere Management ist nicht das Problem. Es ist der größte Puffer im System. Und es hat das stärkste Motiv, den Status quo zu erhalten — weil seine Daseinsberechtigung davon abhängt, dass die Übersetzungsarbeit zwischen oben und unten gebraucht wird.
Capability Spaces can diagnose this – at every level. Not just for the team, but for every unit: what is this department's Capability Space? Which Boundaries exist? Who is the buffer? Where does Structural Comfort sit? The diagnosis scales, because the questions scale.
Capability Spaces kann das diagnostizieren – auf jeder Ebene. Nicht nur für das Team, sondern für jede Einheit: Welchen Capability Space hat diese Abteilung? Welche Boundaries existieren? Wer ist der Puffer? Wo steckt Structural Comfort? Die Diagnose skaliert, weil die Fragen skalieren.
Organisations that enable their people to independently identify and solve the right problems will outperform those that don't. This is not an agile belief. It is an organisational one. Agile frameworks are one attempt to create these conditions – but they are not the only one, and they are not a prerequisite. The prerequisite is a structure that makes empowerment possible, and a diagnostic that makes its absence visible. Capability Spaces provides the diagnostic. What the organisation does with it depends on its context – not on whether it calls itself agile.
Organisationen, die es ihren Menschen ermöglichen, eigenständig die richtigen Probleme zu erkennen und zu lösen, werden diejenigen übertreffen, die das nicht tun. Das ist keine agile Überzeugung — es ist eine Erkenntnis über Organisationen an sich. Agile Frameworks sind ein Versuch, diese Bedingungen zu schaffen – aber sie sind nicht der einzige, und sie sind keine Voraussetzung. Die Voraussetzung ist eine Struktur, die Befähigung ermöglicht, und eine Diagnostik, die ihr Fehlen sichtbar macht. Capability Spaces liefert die Diagnostik. Was die Organisation damit macht, hängt von ihrem Kontext ab – nicht davon, ob sie sich agil nennt.
The model is the same in every context: Map, Boundaries, Compass, Structural Comfort. What changes is the language: "Sprint" becomes "work cycle." "Product Outcome" becomes "measurable impact." "Product Owner" becomes "the person who translates between levels." The structural pattern remains identical – because the problem is not agile. The problem is human organisations and the structures they build around the people inside them.
Das Modell ist in jedem Kontext dasselbe: Map, Boundaries, Compass, Structural Comfort. Was sich ändert, ist die Sprache: „Sprint" wird zu „Arbeitszyklus." „Product Outcome" wird zu „messbarer Wirkung." „Product Owner" wird zu „die Person, die zwischen Ebenen übersetzt." Das strukturelle Muster bleibt identisch – weil das Problem nicht agil ist. Das Problem sind menschliche Organisationen — und die Strukturen, die sie um ihre eigenen Leute herum errichten.
The idea that empowered people produce better outcomes is not new. It has been studied for decades across disciplines, industries, and cultures. What Capability Spaces adds is not the hypothesis itself – it is the diagnostic that makes visible where the structural conditions for empowerment are present and where they are not.
Die Idee, dass befähigte Menschen bessere Ergebnisse erzielen, ist nicht neu. Sie wird seit Jahrzehnten erforscht – quer durch Disziplinen, Branchen und Kulturen. Was Capability Spaces hinzufügt, ist nicht die Hypothese selbst – es ist die Diagnostik, die sichtbar macht, wo die strukturellen Bedingungen für Befähigung gegeben sind und wo nicht.
Self-Determination Theory (1970s–present) identifies three universal psychological needs: autonomy, competence, and relatedness. When organisations suppress these needs, performance, engagement, and creativity decline – regardless of industry. This is the most rigorously studied scientific foundation for the claim that empowerment drives performance. In Capability Spaces terms: the Map represents the structural scope of autonomy, the Compass (Knowledge) maps onto competence, and the Compass (Connection, Trust) maps onto relatedness. SDT explains why empowerment works. Capability Spaces diagnoses where the structure prevents it.
Self-Determination Theory (1970er–heute) benennt drei universelle psychologische Grundbedürfnisse: Autonomie, Kompetenz und Zugehörigkeit. Wenn Organisationen diese Bedürfnisse unterdrücken, sinken Leistung, Engagement und Kreativität – unabhängig von der Branche. Das ist die wissenschaftlich am besten belegte Grundlage für die These, dass Befähigung Leistung steigert. In Capability-Spaces-Begriffen: Die Map beschreibt, wie viel Autonomie die Struktur zulässt, der Compass (Knowledge) entspricht Kompetenz, und der Compass (Connection, Trust) entspricht Zugehörigkeit. SDT erklärt, warum Befähigung funktioniert. Capability Spaces diagnostiziert, wo die Struktur sie verhindert.
In Drive (2009), Pink synthesises four decades of motivation research into three intrinsic drivers: Autonomy (the desire to direct our own lives), Mastery (the urge to get better at something that matters), and Purpose (the yearning to serve something larger than ourselves). His central finding: for any work that involves cognitive complexity, extrinsic motivators like money and control actively reduce performance. Pink's framework is not industry-specific – it applies to any knowledge work. Capability Spaces translates his motivational insight into a structural diagnostic: Autonomy requires a Map large enough to act within. Mastery requires the Compass force Knowledge. Purpose requires the connection between one's work and a meaningful outcome. When Boundaries prevent these conditions, motivation collapses – not because people lack drive, but because the structure doesn't permit it.
In Drive (2009) destilliert Pink vier Jahrzehnte Motivationsforschung zu drei intrinsischen Antrieben: Autonomy (den Wunsch, das eigene Leben zu steuern), Mastery (den Drang, in etwas Bedeutsamem besser zu werden) und Purpose (die Sehnsucht, etwas Größerem zu dienen als sich selbst). Seine zentrale Erkenntnis: Bei jeder Arbeit, die kognitive Komplexität erfordert, reduzieren extrinsische Motivatoren wie Geld und Kontrolle die Leistung aktiv. Pinks Framework ist nicht branchenspezifisch – es gilt für jede Wissensarbeit. Capability Spaces übersetzt diese Erkenntnis in eine strukturelle Diagnostik: Autonomy erfordert eine Map, die groß genug ist, um darin zu handeln. Mastery erfordert die Compass-Kraft Knowledge. Purpose erfordert die Verbindung zwischen der eigenen Arbeit und einem bedeutsamen Outcome. Wenn Boundaries diese Bedingungen verhindern, bricht Motivation zusammen – nicht weil den Menschen der Antrieb fehlt, sondern weil die Struktur ihn nicht zulässt.
In Team of Teams (2015), McChrystal describes how the US military's strict command-and-control hierarchy failed against a networked, adaptive enemy. His solution: Shared Consciousness (everyone has the context to act correctly) and Empowered Execution (everyone is authorised to act without asking permission). His critical insight: empowerment without context leads to chaos – you must build shared consciousness first, then enable empowered execution. This is the exact sequence Capability Spaces follows: first make the Map visible (context), then remove Boundaries (enabling action). McChrystal's case is the strongest non-agile evidence that the hypothesis holds – in a military hierarchy with six levels, life-or-death consequences, and zero tolerance for failure. If it works there, the structural pattern is universal.
In Team of Teams (2015) beschreibt McChrystal, wie die strenge Kommandohierarchie des US-Militärs gegen einen vernetzten, adaptiven Feind versagte. Seine Lösung: Shared Consciousness (jeder hat den Kontext, um richtig zu handeln) und Empowered Execution (jeder darf handeln, ohne um Erlaubnis zu fragen). Seine entscheidende Erkenntnis: Empowerment ohne Kontext führt zu Chaos – zuerst muss Shared Consciousness geschaffen werden, dann kann Empowered Execution ermöglicht werden. Das ist exakt die Reihenfolge, der Capability Spaces folgt: zuerst die Map sichtbar machen (Kontext), dann Boundaries beseitigen (Handlung ermöglichen). McChrystals Fall ist der stärkste nicht-agile Beweis, dass die Hypothese trägt – in einer Militärhierarchie mit sechs Ebenen, lebensbedrohlichen Konsequenzen und null Fehlertoleranz. Wenn es dort funktioniert, ist das strukturelle Muster universell.
Kirkman & Rosen (1999) demonstrated across four organisations that team empowerment positively impacts customer service, job satisfaction, and organisational commitment. A meta-analysis by Lee, Willis & Tian (2018, 105 studies) confirmed this at scale: empowering leadership significantly improves employee creativity and citizenship behaviour, and increases trust in leadership. The effects hold across team types — production teams, project teams, management teams. The larger and more complex the team, the stronger the empowerment effect. This is the empirical evidence that the hypothesis is not aspirational — it is measurable. Capability Spaces does not generate this evidence. It provides the diagnostic lens to understand why empowerment is present or absent in a specific structural context.
Kirkman & Rosen (1999) wiesen in vier Organisationen nach, dass Team-Empowerment positive Auswirkungen auf Kundenzufriedenheit, Arbeitszufriedenheit und organisationale Bindung hat. Eine Meta-Analyse von Lee, Willis & Tian (2018, 105 Studien) bestätigte dies im großen Maßstab: Empowering Leadership steigert Kreativität und freiwilliges Engagement signifikant und erhöht das Vertrauen in Führung. Die Effekte gelten über Teamtypen hinweg — Produktionsteams, Projektteams, Managementteams. Je größer und komplexer das Team, desto stärker der Empowerment-Effekt. Das ist der empirische Beleg dafür, dass die Hypothese kein Wunschdenken ist — sie ist messbar. Capability Spaces erzeugt diesen Beleg nicht. Es liefert das Diagnosewerkzeug, um zu verstehen, warum Empowerment in einem bestimmten strukturellen Kontext vorhanden oder abwesend ist.
Research has shown for decades that empowered people produce better outcomes. What is missing is not the insight — it is the ability to see, in a specific organisation, where the structural conditions for empowerment are present and where they are not. Capability Spaces provides this diagnostic. Whether it is the only or the best one remains to be shown in practice. That such a diagnostic is needed — that is what the research itself demonstrates.
Die Forschung zeigt seit Jahrzehnten, dass befähigte Menschen bessere Ergebnisse erzielen. Was fehlt, ist nicht die Erkenntnis — sondern ein Weg, in einer konkreten Organisation zu sehen, wo die strukturellen Bedingungen dafür gegeben sind und wo nicht. Capability Spaces liefert diese Diagnostik. Ob es die einzige oder die beste ist, muss die Praxis zeigen. Dass eine solche Diagnose gebraucht wird — das zeigt die Forschung selbst.
The biggest structural problem in agile transformations: the decoupling between what teams experience daily and what leaders perceive.
Retros and impediment lists end up as reports. They reach a leader as summarised information – not as a lived pattern. Capability Spaces works differently.
The leader is not a recipient of reports. They sit in live – in a dedicated format that fits any existing frame: a weekly meeting in Scrum, a Kanban stand-up, an OKR Weekly. The key point is that leadership is there to diagnose – not to approve.
Make a decision: is the team allowed to solve this problem? If yes, update the role description or explicitly authorise.
Temporarily suspend a process, approve an exception, or bring the team into the process change itself.
Replace the ticket with a problem statement. Clarify with the requesting side: what should change, for whom?
Clarify whether the rule was designed for this situation. If not: grant an explicit exception, initiate a change, or escalate to whoever owns the rule.
Capability Spaces works – but only if leadership is not just present, but actively takes responsibility for boundaries the team cannot resolve itself. This is not a weakness of the model. It is its core condition.
The traffic-light looks simple – and it is. That is precisely its strength. You do not need a new tool, a new process, or a new role. You need one honest question asked regularly: are we able to work on what actually matters? Green, Amber, Red. The colour itself opens the conversation. The Boundary that follows gives it structure. Complexity hides problems. Simplicity surfaces them.
Agile scaling frameworks like SAFe or LeSS treat the symptom: they coordinate the dependencies that arise because teams are cut by topic and feature.
Capability Spaces offers a conceptual alternative: teams are not cut by topic, but by which problems they can independently identify and solve. Scaling then emerges through the natural growth of spaces – not through periodic org design from above.
For a deeper look at how to cut teams, Team Topologies (Skelton & Pais) offers a complementary model: cutting teams by cognitive load and interaction mode rather than by feature. Capability Spaces and Team Topologies are compatible – Team Topologies describes the how of cutting, Capability Spaces describes why a cut needs to change in the first place.
Teams cut by topic. Dependencies unavoidable. Coordination through PI Planning, Scrum of Scrums. The framework treats the symptom.
Teams cut by problem-solving ability. Dependencies become visible as boundaries. Structure follows organic growth of spaces.
Periodic top-down decision. High effort, disconnected from what teams can actually do. Often outdated before implemented.
Continuous diagnosis via boundaries. Structure adapts when spaces become too tight. No reorg project – ongoing self-correction.
Scaling is not a one-time org-design project. It is the result of teams continuously growing – in capability and in responsibility. Boundaries show where that growth process is currently stuck.
Das größte strukturelle Problem agiler Transformationen: Die Entkopplung zwischen dem, was Teams täglich erleben, und dem, was Führungskräfte wahrnehmen.
Retros und Impediment-Listen enden als Reports. Sie landen bei einer Führungskraft als zusammengefasste Information — nicht als erlebtes Muster. Capability Spaces geht einen anderen Weg.
Führungskräfte sind nicht Empfänger*innen von Berichten. Sie sind dabei — in einem dedizierten Format, das in jeden bestehenden Rahmen passt: ein wöchentliches Meeting in Scrum, ein Kanban-Jour-Fixe, ein OKR Weekly. Entscheidend ist, dass Führung dort ist, um zu diagnostizieren — nicht um zu genehmigen.
Entscheidung treffen: Darf das Team dieses Problem lösen? Wenn ja, Rollenbeschreibung anpassen oder explizit freigeben.
Prozess kurzfristig suspendieren, Ausnahme genehmigen oder das Team in die Prozessveränderung einbinden.
Ticket durch Problemformulierung ersetzen. Mit der anfragenden Person klären: Was soll sich für wen verändern?
Klären, ob die Regel für diese Situation gemacht wurde. Falls nicht: explizite Ausnahme erteilen, eine Änderung anstoßen oder an die Person eskalieren, die die Regel verantwortet.
Capability Spaces funktioniert – aber nur, wenn Führungskräfte nicht nur dabei sind, sondern aktiv Verantwortung für Boundaries übernehmen, die das Team nicht selbst lösen kann. Das ist keine Schwäche des Modells. Es ist seine Kernbedingung.
Die Ampel sieht simpel aus – und das ist sie auch. Genau darin liegt ihre Stärke. Du brauchst kein neues Tool, keinen neuen Prozess, keine neue Rolle. Du brauchst eine ehrliche Frage, die regelmäßig gestellt wird: Können wir gerade an dem arbeiten, was wirklich wichtig ist? Grün, Gelb, Rot. Die Farbe öffnet das Gespräch. Die Boundary, die folgt, gibt ihm Struktur. Komplexität versteckt Probleme. Einfachheit bringt sie ans Licht.
Agile Skalierungsframeworks wie SAFe oder LeSS behandeln das Symptom: Sie koordinieren die Abhängigkeiten, die entstehen, weil Teams nach Themen und Features geschnitten sind.
Capability Spaces bietet eine konzeptionelle Alternative: Teams werden nicht nach Themen geschnitten, sondern danach, welche Probleme sie eigenständig erkennen und lösen können. Skalierung entsteht dann durch das natürliche Wachstum der Spaces – nicht durch periodisches Org-Design von oben.
Wer tiefer einsteigen möchte, wie Teams geschnitten werden sollten, findet in Team Topologies (Skelton & Pais) ein ergänzendes Modell: Teams nach kognitiver Belastung und Interaktionsmustern zu schneiden statt nach Features. Capability Spaces und Team Topologies sind kompatibel — Team Topologies beschreibt das Wie des Schnitts, Capability Spaces beschreibt, warum ein Schnitt überhaupt verändert werden muss.
Teams nach Themen geschnitten. Abhängigkeiten unvermeidlich. Koordination durch PI Planning, Scrum of Scrums. Das Framework behandelt das Symptom.
Teams nach Problemlösungsfähigkeit geschnitten. Abhängigkeiten werden als Boundaries sichtbar. Struktur folgt organischem Wachstum der Spaces.
Periodische Top-down-Entscheidung. Hoher Aufwand, losgelöst vom tatsächlichen Teamkönnen. Oft schon veraltet, bevor sie umgesetzt ist.
Kontinuierliche Diagnose über Boundaries. Struktur passt sich an, wenn Spaces zu eng werden. Kein Reorganisationsprojekt, sondern laufende Selbstkorrektur.
Skalierung ist kein einmaliges Org-Design-Projekt. Sie entsteht, wenn Teams kontinuierlich wachsen — in Fähigkeiten und in Verantwortung. Boundaries zeigen, wo dieser Wachstumsprozess gerade hängt.
Organisations invest in strategy, consulting, and transformation programmes. The direction is usually clear. The execution consistently isn't. This gap – between what leadership has decided and what actually happens – is the oldest and most expensive problem in organisational life. It is also, almost always, a structural one.
Classical organisational development approaches treat this as a change management problem: communication, culture, leadership behaviour. These interventions matter. But they address the surface. Capability Spaces goes one level deeper – it asks not how do we get people to change, but what in the structure prevents the organisation from doing what it has already decided to do?
Organisationen investieren in Strategie, Beratung und Transformationsprogramme. Die Richtung ist meist klar. An der Umsetzung scheitert es verlässlich. Diese Lücke – zwischen dem, was Führungskräfte entschieden haben, und dem, was tatsächlich passiert – ist das älteste und teuerste Problem im Organisationsleben. Und sie ist fast immer ein strukturelles.
Klassische OE-Ansätze behandeln das als Change-Management-Problem: Kommunikation, Kultur, Führungsverhalten. Diese Interventionen sind wichtig. Aber sie adressieren die Oberfläche. Capability Spaces geht eine Ebene tiefer — es fragt nicht wie bringen wir Menschen dazu, sich zu verändern, sondern was in der Struktur verhindert, dass die Organisation umsetzt, was sie längst beschlossen hat?
Capability Spaces speaks to different people differently. The model is the same. What changes is the lever each person holds.
You approved the strategy. You allocated the resources. You see the effort in every status report. But between your decision and its execution, something consistently disappears. Capability Spaces shows you exactly where – not as a culture narrative, but as a structural map.
You run the development programmes. You measure engagement. You coach leaders. The people get better. But the organisation doesn't seem to follow. That is because the constraint is rarely in the people – it is in the structure those people operate within.
You translate strategy downward and team reality upward. Both directions distort the signal. Capability Spaces gives you a shared format: one that makes visible to leadership what teams experience, and makes visible to teams why the constraints around them exist.
All three roles are caught in the same dynamic: the gap between intention and execution is experienced at every level, but named differently at each one. C-Level calls it a performance problem. HR calls it a culture problem. Middle management calls it a communication problem. Capability Spaces gives all three the same structural language – so the diagnosis, for once, matches the actual problem.
Capability Spaces spricht verschiedene Menschen unterschiedlich an. Das Modell ist dasselbe. Was sich ändert, ist der Hebel, den jede Person hält.
Du hast die Strategie freigegeben. Du hast die Ressourcen bereitgestellt. Du siehst den Einsatz in jedem Statusbericht. Aber zwischen deiner Entscheidung und ihrer Umsetzung geht verlässlich etwas verloren. Capability Spaces zeigt dir genau wo – nicht als Kulturerzählung, sondern als strukturelle Diagnose.
Du gestaltest die Entwicklungsprogramme. Du misst Engagement. Du coachst Führungskräfte. Die Menschen werden besser. Aber die Organisation zieht nicht mit. Das liegt daran, dass das Problem selten in den Menschen steckt — sondern in der Struktur, in der sie arbeiten.
Du übersetzt Strategie nach unten und die Realität der Teams nach oben. Beide Richtungen verzerren das Signal. Capability Spaces gibt dir ein gemeinsames Format: eines, das Führung sichtbar macht, was Teams erleben – und Teams sichtbar macht, warum die Constraints um sie herum existieren.
Alle drei Rollen stecken in derselben Dynamik: Die Lücke zwischen Absicht und Umsetzung zeigt sich auf jeder Ebene — wird aber überall anders benannt. Das C-Level nennt es ein Performance-Problem. HR nennt es ein Kulturproblem. Das mittlere Management nennt es ein Kommunikationsproblem. Capability Spaces gibt allen drei dieselbe strukturelle Sprache – damit die Diagnose endlich zum tatsächlichen Problem passt.
Problem-oriented work does not start automatically. It requires a shift in how teams think — and that shift takes time, coaching, and repeated practice.
Teams that have been executing tickets for years have internalised a different mode of work: receive requirement, build feature, mark done. Reorienting toward the problem behind the request — and toward the outcome it should produce — is a behaviour change. That takes coaching, not just process.
Once a team has completed a full cycle — Sprint, Quarter, or OKR period — with problem-oriented thinking, the next planning becomes significantly easier. They arrive with context, hypotheses, and outcome signals from the previous cycle. The model compounds over time.
Reaching an outcome means that another person — a user, a customer, an internal stakeholder — has changed their behaviour. They can now do something they couldn't before. That change is never fully within the team's control.
This is a natural boundary. Not a team failure. Not a process failure. Expecting outcomes within a single sprint is a structural misunderstanding. Capability Spaces makes this visible — so leaders stop measuring the wrong thing, and teams stop being held accountable for what they cannot control.
Problemorientiertes Arbeiten entsteht nicht von selbst. Es erfordert eine Veränderung in der Denkweise des Teams — und diese Veränderung braucht Zeit, Coaching und wiederholte Praxis.
Teams, die jahrelang Tickets abgearbeitet haben, kennen nur einen Modus: Anforderung empfangen, Feature bauen, abhaken. Den Blick auf das Problem hinter dem Auftrag zu richten — und auf die Wirkung, die es erzeugen soll — ist eine Verhaltensveränderung. Das braucht Coaching, nicht nur Prozess.
Sobald ein Team einen vollständigen Zyklus — Sprint, Quartal oder OKR-Periode — mit problemorientiertem Denken abgeschlossen hat, wird das nächste Planning deutlich einfacher. Das Team kommt mit Kontext, Hypothesen und Outcome-Signalen aus dem vorherigen Zyklus. Das Modell verstärkt sich über die Zeit.
Ein Outcome ist erreicht, wenn eine andere Person — ein User, ein Kunde, ein interner Stakeholder — ihr Verhalten verändert hat. Sie können jetzt etwas tun, was sie vorher nicht konnten. Diese Veränderung liegt nie vollständig im Einflussbereich des Teams.
Das ist eine natürliche Boundary. Kein Team-Versagen. Kein Prozess-Versagen. Outcomes innerhalb eines einzelnen Sprints zu erwarten, verkennt die Natur der Sache. Capability Spaces macht das sichtbar — damit Führungskräfte aufhören, das Falsche zu messen, und Teams nicht für das verantwortlich gemacht werden, was sie nicht kontrollieren können.
Capability Spaces gives coaches and leaders a shared diagnosis – and shows clearly who needs to act, and where. It also draws a clear line: between goals imposed from outside, and goals a team sets for itself.
Both columns below describe the same situation — from two different positions in it. The diagnosis is the same. What changes is what each person can do about it.
You improve team dynamics, you name the impediments, you coach the process. But the same blockers return every sprint. The team doesn't grow. That is not necessarily a coaching failure – it may mean the team was never in a position to set its own goals in the first place.
You approved the transformation. You provided the resources. You see the effort. But team performance stays flat – and no one can explain why. The explanation is structural.
Capability Spaces gibt Coaches und Führungskräften eine gemeinsame Diagnose – und zeigt klar, wer wo handeln muss. Das Modell trennt dabei sauber: zwischen Zielen, die von außen vorgegeben werden, und Zielen, die ein Team sich selbst setzt.
Beide Spalten beschreiben dieselbe Situation — aus zwei verschiedenen Positionen. Die Diagnose ist dieselbe. Was sich unterscheidet, ist der Hebel, den jede Seite in der Hand hat.
Du verbesserst die Teamdynamik, benennst die Impediments, coachst den Prozess. Aber dieselben Blocker kommen jeden Sprint zurück. Das Team kommt nicht weiter. Das ist nicht zwingend ein Coaching-Versagen – es kann bedeuten, dass das Team nie in der Lage war, überhaupt eigene Ziele zu setzen.
Du hast die Transformation genehmigt, Ressourcen bereitgestellt und siehst den Aufwand. Trotzdem bleibt die Team-Performance flach – und niemand kann erklären, warum. Die Erklärung ist strukturell.
Capability Spaces is not a workshop. It is a set of lightweight, recurring practices — embedded directly into how teams already work.
Capability Spaces ist kein Workshop. Es ist ein Set aus schlanken, wiederkehrenden Praktiken — eingebettet in die Art, wie Teams bereits arbeiten.
The three formats below are additions to an existing Scrum setup. All standard Scrum events remain unchanged — Sprint Planning, Daily, Review, Retrospective. Capability Spaces adds three lightweight layers: a problem-orientation reset (The Map), a weekly boundary check, and a compass signal in every retro. Nothing replaces what's already there.
Die drei Formate unten sind Ergänzungen zu einem bestehenden Scrum-Setup. Alle Standard-Scrum-Events bleiben unverändert — Sprint Planning, Daily, Review, Retrospektive. Capability Spaces fügt drei leichtgewichtige Ebenen hinzu: einen Problem-Orientierungs-Reset (Die Map), einen wöchentlichen Boundary-Check und ein Compass-Signal in jeder Retro. Nichts ersetzt, was bereits da ist.
Most product teams build what they are asked for. The Map reorients them toward the problem behind the request — without changing the process, just the thinking.
Die meisten Produktteams bauen, was man ihnen aufträgt. Die Map reorientiert sie auf das Problem hinter dem Auftrag — ohne den Prozess zu ändern, nur das Denken.
Before writing a single line of code: who has the problem? What is their situation? What can they not do today that they need to do?
Bevor eine Zeile Code geschrieben wird: Wer hat das Problem? Was ist ihre Situation? Was können sie heute nicht tun, was sie brauchen?
"What outcome does this person need — not what feature do they want?" „Welches Ergebnis braucht diese Person — nicht welches Feature wünscht sie sich?"The team formulates a testable assumption: if we build X, then the user can do Y, and this solves problem Z. They ship to test — not to deliver.
Das Team formuliert eine überprüfbare Annahme: Wenn wir X bauen, kann der User Y tun, und das löst Problem Z. Sie liefern zum Testen — nicht zum Abliefern.
"How will we know if we were right?" „Woran erkennen wir, ob wir richtig lagen?"The user can now do something they couldn't before. The problem is solved. They say so. This signal — not a sprint velocity — is the real measure of success.
Der User kann jetzt etwas, was er vorher nicht konnte. Das Problem ist gelöst. Er sagt es. Dieses Signal — nicht eine Sprint-Velocity — ist das echte Maß für Erfolg.
"Did the user's situation actually change?" „Hat sich die Situation des Users wirklich verändert?"The user can do something they couldn't before. One explicit problem solved.
All outcomes together form the product. Not a collection of features — a collection of solved problems.
Teams that think in outcomes automatically contribute to business objectives. The alignment happens through the work itself — not through top-down goal cascades.
A team that thinks in problems and outcomes is operating inside its Compass — building trust through knowledge, testing assumptions in real time. And because each outcome connects to the product, and the product to business goals, the question of strategic alignment answers itself.
Der User kann etwas, was er vorher nicht konnte. Ein explizites Problem gelöst.
Alle Outcomes zusammen ergeben das Produkt. Keine Feature-Sammlung — eine Sammlung gelöster Probleme.
Teams, die in Outcomes denken, zahlen automatisch auf die Businessziele ein. Die Ausrichtung entsteht durch die Arbeit selbst — nicht durch Top-down-Zielkaskaden.
Ein Team, das in Problemen und Outcomes denkt, arbeitet innerhalb seines Compass — baut Vertrauen durch Wissen auf und testet Annahmen in Echtzeit. Und weil jeder Outcome auf das Produkt einzahlt, und das Produkt auf die Businessziele, beantwortet sich die Frage nach strategischer Ausrichtung von selbst.
The weekly meeting is an opportunities meeting first. Each team names the most important user problems they are working on. The meeting is done when the opportunities have been named. Boundaries only come up if the team is amber or red — then leadership needs to act.
Das Weekly ist in erster Linie ein Opportunities-Meeting. Jedes Team nennt die wichtigsten User-Probleme, an denen es gerade arbeitet. Das Meeting ist beendet, wenn die Opportunities genannt wurden. Boundaries kommen nur zur Sprache, wenn das Team gelb oder rot ist — dann muss die Führungskraft handeln.
The output is simple: what are the biggest opportunities the team is currently running solution experiments for? Leadership is present to hear exactly that — nothing more. If the team is amber or red, boundaries are named — but only then. The traffic light is a signal, not the agenda.
Das Ergebnis ist einfach: Was sind die größten Opportunities, an denen das Team gerade mit Lösungsexperimenten arbeitet? Die Führungskraft ist dabei, um genau das zu hören — nicht mehr. Wenn das Team gelb oder rot ist, werden Boundaries benannt — aber erst dann. Die Ampel ist ein Signal, keine Agenda.
Clearest user problem right now. Team owns it fully — no blockers to working on this.
Klarestes User-Problem aktuell. Team kann es vollständig bearbeiten — keine Blocker.
We see the problem in data but can't reach affected users to understand it. Blocking sprint goal.
Wir sehen das Problem in den Daten, kommen aber nicht an betroffene Nutzer ran. Blockiert das Sprint Goal.
Most important problem for the sprint goal. We can't work on it — it's owned by another team and we have no mandate to change it.
Wichtigstes Problem für das Sprint Goal. Wir können nicht daran arbeiten — es gehört einem anderen Team und wir haben kein Mandat zur Änderung.
The green item above is the normal case — a clear opportunity the team fully owns. Amber and red only come up when something structural is in the way. The meeting is designed to end with opportunities visible — not to be a blocker review. When it stays on opportunities, leadership sees what matters. When it surfaces a red boundary, they know exactly where to act.
Das grüne Element oben ist der Normalfall — eine klare Opportunity, die das Team vollständig verantwortet. Gelb und Rot kommen nur dann ins Spiel, wenn etwas Strukturelles im Weg steht. Das Meeting ist so gestaltet, dass es endet, wenn die Opportunities sichtbar sind — nicht als Blocker-Review. Wenn es bei Opportunities bleibt, sieht die Führungskraft, was zählt. Wenn eine rote Boundary auftaucht, weiß sie genau, wo sie handeln muss.
The Compass extends the "what went well" part of the retro. No Boundaries here — those are already covered in the weekly. This is purely team-internal: the team recognises and names what worked, to strengthen their sense of capability. The Sprint Review is where Connection happens — feedback from stakeholders and users flows back to the team there.
Der Compass erweitert den „Was lief gut"-Teil der Retro. Keine Boundaries hier — die werden bereits im Weekly besprochen. Das ist rein team-intern: Das Team erkennt und benennt, was gut funktioniert hat, um das eigene Kompetenzgefühl zu stärken. Das Sprint Review ist der Ort für Connection — dort fließt Feedback von Stakeholdern und Usern zurück zum Team.
We talked directly to the stakeholder or user. We can describe their situation in our own words — not in ticket language. We know why we're building this.
Wir haben direkt mit dem Stakeholder oder User gesprochen. Wir können seine Situation in eigenen Worten beschreiben — nicht in Ticket-Sprache. Wir wissen, warum wir das bauen.
We defined what we believed before we built it. We shipped something specifically to test that belief. We didn't just execute a ticket — we ran an experiment.
Wir haben definiert, was wir glaubten, bevor wir es gebaut haben. Wir haben geliefert, um diese Annahme zu testen. Wir haben kein Ticket abgearbeitet — wir haben ein Experiment durchgeführt.
The user can now do something in the product they couldn't before. Their explicit problem is solved. Not "feature shipped" — problem gone.
Der User kann jetzt etwas in der App tun, was er vorher nicht konnte. Sein explizites Problem ist gelöst. Nicht „Feature geliefert" — Problem beseitigt.
The user noticed. They gave the team direct feedback — a message, a comment, a conversation. This is the signal that closes the loop. The work had impact.
Der User hat es bemerkt. Er hat dem Team direktes Feedback gegeben — eine Nachricht, ein Kommentar, ein Gespräch. Das ist das Signal, das den Kreis schließt. Die Arbeit hatte Wirkung.
Boundaries are not discussed here — they belong in the weekly. The retro is team-internal. The Compass takes the place of "what went well": the team names where Trust, Knowledge, Assumption Testing and Connection showed up this sprint. The Sprint Review is where Connection signals arrive from outside — feedback from users and stakeholders that confirms the work mattered. Together, retro and review close the loop.
Boundaries werden hier nicht besprochen — die gehören ins Weekly. Die Retro ist team-intern. Der Compass übernimmt den „Was lief gut"-Teil: Das Team benennt, wo Trust, Knowledge, Assumption Testing und Connection in diesem Sprint sichtbar waren. Das Sprint Review ist der Ort, an dem Connection-Signale von außen ankommen — Feedback von Usern und Stakeholdern, das bestätigt, dass die Arbeit etwas bewirkt hat. Zusammen schließen Retro und Review den Kreis.
The same food delivery app. Users order once and don't come back. The team is in Sprint 2 of an unknown number. There is no OKR yet — just Scrum, Capability Spaces, and the discipline to ask the right question every two weeks.
Dieselbe Food-Delivery-App. Nutzer bestellen einmal und kommen nicht wieder. Das Team ist in Sprint 2 von einer unbekannten Anzahl. Noch kein OKR — nur Scrum, Capability Spaces und die Disziplin, alle zwei Wochen die richtige Frage zu stellen.
Users who ordered once don't open the app again the next day — even when they're hungry.
A single relevant push notification 18h after the first order will increase day-2 app opens.
Users who ordered yesterday open the app again tomorrow.
Nutzer, die einmal bestellt haben, öffnen die App am nächsten Tag nicht wieder — auch wenn sie hungrig sind.
Eine einzelne, relevante Push-Benachrichtigung 18h nach der ersten Bestellung erhöht die App-Öffnungen an Tag 2.
Nutzer, die gestern bestellt haben, öffnen die App morgen wieder.
We want to personalise the notification by cuisine preference — but we can't read the user's order history without a formal data request. We're sending generic notifications instead. Likely reduces conversion.
→ Leadership: data access approved same day. Personalised version ships in the sprint.Wir wollen die Benachrichtigung nach Cuisine-Präferenz personalisieren — kommen aber ohne formalen Datenzugriff nicht an die Bestellhistorie. Wir verschicken generische Benachrichtigungen. Das senkt wahrscheinlich die Conversion.
→ Führung: Datenzugriff noch am gleichen Tag genehmigt. Personalisierte Version wird im Sprint ausgeliefert.We defined the hypothesis before building. We shipped a test, not a feature. Day-2 opens increased 11 points — the assumption was right.
Leadership unblocked the data access in hours, not weeks. The team noticed. It matters.
Day-2 opens went up — but reorders didn't follow. We don't yet know why users browse and leave. We haven't talked to them. Next sprint: user interviews first.
We don't know what happens between opening the app and leaving without ordering. The data shows the drop — but not the reason. We need to get closer to users.
The Compass makes the gap visible: the metric moved, but the outcome didn't. That is exactly the right thing to know at the end of Sprint 2. The next sprint starts with the right question — not a new feature, but a user conversation.
Wir haben die Hypothese definiert, bevor wir gebaut haben. Wir haben einen Test ausgeliefert, kein Feature. Tag-2-Öffnungen +11 Punkte — die Annahme war richtig.
Die Führung hat den Datenzugriff in Stunden entsperrt, nicht in Wochen. Das Team hat es bemerkt. Es macht einen Unterschied.
Tag-2-Öffnungen stiegen — aber Nachbestellungen folgten nicht. Wir wissen noch nicht, warum Nutzer scrollen und gehen. Wir haben noch nicht mit ihnen gesprochen. Nächster Sprint: zuerst User-Interviews.
Wir wissen nicht, was zwischen App-Öffnung und Verlassen ohne Bestellung passiert. Die Daten zeigen den Drop — aber nicht den Grund. Wir müssen näher an die Nutzer.
Der Compass macht die Lücke sichtbar: die Metrik hat sich bewegt, der Outcome nicht. Das ist genau das Richtige, was man am Ende von Sprint 2 wissen muss. Der nächste Sprint beginnt mit der richtigen Frage — kein neues Feature, sondern ein Nutzergespräch.
Most Jira backlogs describe what the team plans to build. The Map asks a different question: what is the user problem, and what should change for them? The hierarchy stays the same — Epic, Story, Subtask. Only the thinking changes.
Ron Jeffries invented User Stories in 1998 as a placeholder for a conversation about user need. Mike Cohn later codified the format as "As a [user], I want [X] so that [Y]" — the "so that Y" is the outcome. In practice, that last part is almost always omitted. Jeff Patton's User Story Mapping (2014) goes further: stories should describe the activity the user is trying to complete, not the feature the team plans to build. The problem was understood from the start. Jira just made it easier to ignore.
A large outcome — something meaningful that changes for users or the business. If you use OKRs, an Epic maps directly to a Key Result.
The user problem and the desired outcome. Not the solution. Not the feature. The ticket answers: who cannot do what, and what should be different afterwards?
Solution ideas and implementation steps — experiments toward the outcome. Optional: if developers prefer not to track subtasks, that is fine. Transparency comes from outcomes, not task lists.
An outcome, not a delivery list. The Sprint Goal describes what will be different for users at the end of the sprint — not what the team plans to ship.
The outcome the team is working toward. Not a feature area — a change in user behaviour. Every story in this epic is an experiment toward this outcome.
An outcome hypothesis, not a shipping list. At the Sprint Review: did it happen? If not — what did we learn?
"As a first-time buyer, I want a timely, relevant reminder — so that I think of the app before deciding to order elsewhere." The "so that" names the outcome. The implementation lives in subtasks.
The implementation decision. Tracked internally by the team if useful. Leadership and stakeholders see the Story and the Sprint Goal — not the Subtask.
The concern is sometimes raised that without detailed subtasks, nobody knows what developers are working on. This confuses activity transparency with outcome transparency. A team with clear user problems and defined desired outcomes is far more transparent than one with 400 linked tickets and no shared understanding of what change they are working toward. What the team does is their business. What changes for users is everyone's.
Die meisten Jira-Backlogs beschreiben, was das Team zu bauen plant. Die Map stellt eine andere Frage: Was ist das Nutzerproblem, und was soll sich für sie verändern? Die Hierarchie bleibt gleich — Epic, Story, Subtask. Nur das Denken ändert sich.
Ron Jeffries erfand User Stories 1998 als Platzhalter für ein Gespräch über Nutzerbedürfnisse. Mike Cohn kodifizierte das Format als „Als [Nutzer] möchte ich [X], damit [Y]" — das „damit Y" ist der Outcome. In der Praxis fällt dieser Teil fast immer weg. Jeff Pattons User Story Mapping (2014) geht weiter: Stories sollten die Aktivität beschreiben, die der Nutzer abschließen möchte — nicht das Feature, das das Team zu bauen plant. Das Problem war von Anfang an bekannt. Jira hat es nur leichter gemacht, es zu ignorieren.
Ein großer Outcome — etwas Bedeutsames, das sich für Nutzer oder das Unternehmen verändert. Wenn OKRs genutzt werden, entspricht ein Epic direkt einem Key Result.
Das Nutzerproblem und der gewünschte Outcome. Nicht die Lösung. Nicht das Feature. Das Ticket beantwortet: Wer kann was nicht tun, und was soll danach anders sein?
Lösungsideen und Implementierungsschritte — Experimente auf dem Weg zum Outcome. Optional: Wenn Entwickler keine Subtasks erfassen möchten, ist das kein Problem. Transparenz entsteht durch Outcomes, nicht durch Aufgabenlisten.
Ein Outcome, keine Lieferliste. Das Sprint Goal beschreibt, was sich am Ende des Sprints für Nutzer verändert hat — nicht was das Team plant auszuliefern.
Der Outcome, auf den das Team hinarbeitet. Kein Feature-Bereich — eine Verhaltensänderung bei Nutzern. Jede Story in diesem Epic ist ein Experiment auf dem Weg dorthin.
Eine Outcome-Hypothese, keine Lieferliste. Im Sprint Review: Ist es eingetreten? Wenn nicht — was haben wir gelernt?
„Als Erstkäufer möchte ich eine zeitlich passende, relevante Erinnerung — damit ich an die App denke, bevor ich mich woanders entscheide." Das „damit" benennt den Outcome. Die Implementierung steckt in Subtasks.
Die Implementierungsentscheidung. Intern vom Team erfasst, wenn sinnvoll. Führung und Stakeholder sehen die Story und das Sprint Goal — nicht den Subtask.
Manchmal wird eingewandt, dass ohne detaillierte Subtasks niemand weiß, woran Entwickler arbeiten. Das verwechselt Aktivitätstransparenz mit Outcome-Transparenz. Ein Team mit klaren Nutzerproblemen und definierten gewünschten Outcomes ist deutlich transparenter als eines mit 400 verlinkten Tickets und keinem gemeinsamen Verständnis davon, welche Veränderung angestrebt wird. Was das Team tut, ist seine Sache. Was sich für Nutzer verändert, geht alle an.