Any framework gives you structure. Agility is what happens when teams can actually use it. Jedes Framework gibt Ihnen Struktur. Agilität entsteht, wenn Teams sie wirklich nutzen können.
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 folgen dem Prozess korrekt. 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 Ihnen, wo dieser Raum blockiert ist, und was nur Sie verändern können.
Scrum was designed to empower teams – to put developers at the centre and give them autonomy. The Scrum Guide still says so. What happened instead is well documented. Scrum wurde entwickelt, um Teams zu empowern – Entwickler in den Mittelpunkt zu stellen und ihnen Autonomie zu geben. Der Scrum Guide sagt das bis heute. Was stattdessen passiert ist, ist gut belegt.
The most common diagnosis when agile fails: the team did something wrong. The data tells a more nuanced story. Most impediments are at management level – organisational structure, functional silos, approval processes. Teams that are not empowered to set their own goals cannot meaningfully be held accountable when those externally defined goals aren't met. Only when teams miss goals they set themselves do Scrum Masters and coaches become genuinely effective – helping teams understand how to reach their own commitments. Capability Spaces gives you a diagnostic to see exactly where – and a format to act on it.
Die häufigste Diagnose, wenn Agilität scheitert: das Team hat etwas falsch gemacht. Die Daten erzählen eine differenziertere Geschichte. Die meisten Impediments liegen auf Management-Ebene – Organisationsstruktur, funktionale Silos, Freigabeprozesse. Teams, die nicht in die Lage versetzt werden, eigene Ziele zu setzen, können für das Verfehlen extern definierter Ziele kaum verantwortlich gemacht werden. Erst wenn Teams selbstgesetzte Ziele verfehlen, werden Scrum Master und Coaches wirklich wirksam – indem sie Teams helfen zu verstehen, wie sie ihre eigenen Commitments erreichen. Capability Spaces gibt Ihnen eine Diagnose, um genau das zu sehen – und ein Format, um darauf zu reagieren.
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?
Sie genehmigen, investieren, unterstützen.
Und trotzdem liefern Ihre Teams nicht.
Lesen Sie diese Situationen. Schauen Sie, wie viele Sie wiedererkennen.
Ihre Teams arbeiten in Sprints – aber beim Sprint Review überrascht Sie trotzdem, was gebaut wurde.
Ihre Teams machen Retrospektiven – aber es gibt kein Format, in dem Sie direkt erleben, was sie blockiert. Boundaries bleiben für Sie unsichtbar.
Ihre Teams haben einen Product Owner – aber Prioritäten kommen trotzdem von oben. Der Product Owner koordiniert, entscheidet nicht.
Impediments werden zu Ihnen eskaliert. Sie lösen sie. Denselben Impediments begegnen Sie im nächsten Sprint wieder.
Ihre Entwickler sind beschäftigt. Tickets werden geschlossen. Aber die Wirkung sehen Sie nicht – weder im Produkt noch in den Zahlen.
Ihre Teams wissen genau, was das Problem ist. Lösen können sie es nicht – weil sie es nicht dürfen.
Ihre 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 Ihnen genau, wo die Organisation sich selbst im Weg steht – und was nur Sie verändern können. Die Coaching-Frage kommt danach: Sobald Teams eigene Ziele setzen können, wird die Arbeit: Wie erreichen sie, was sie sich selbst vorgenommen haben?
When a team doesn't reach its goals, the most common diagnosis is: the team did something wrong. But that question only makes sense if the team was actually in a position to set goals it believed were realistic.
Wenn ein Team seine Ziele nicht erreicht, ist die häufigste Diagnose: das Team hat es falsch gemacht. Aber diese Frage macht nur Sinn, wenn das Team überhaupt in der Lage war, Ziele zu setzen, die es selbst für realistisch hält.
Teams that are no longer enabled to define their own goals can hardly be held accountable when externally imposed goals aren't met. Only when a team misses goals it set itself does real coaching work begin – and that is where Scrum Masters and coaches are most effective: helping teams reach their own goals.
Teams, die nicht mehr in die Lage versetzt werden, eigene Ziele zu setzen, können schwerlich dafür verantwortlich gemacht werden, wenn externe Ziele verfehlt werden. Erst wenn ein Team seine selbstgesetzten Ziele nicht erreicht, beginnt echte Coaching-Arbeit – und genau da sind Scrum Master und Coaches am wirksamsten: dabei zu helfen, die eigenen Ziele zu erreichen.
Capability Spaces makes that distinction visible – and gives teams and leaders a shared language for it.
Capability Spaces macht diesen Unterschied sichtbar – und gibt Teams und Führungskräften eine gemeinsame Sprache dafür.
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 diagnosierbar.
The model predicts failure when two conditions are simultaneously present. Both are structural. Both are visible – if you know what to look for.
Das Modell sagt Scheitern voraus, wenn zwei Bedingungen gleichzeitig vorliegen. Beide sind strukturell. 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 organisationale Reibung nicht durch inneren Zusammenhalt kompensieren.
The space in which a team can independently identify and pursue opportunities (problems).
Der Raum, in dem ein Team eigenständig Opportunities (Probleme) erkennen und bearbeiten kann.
Structural constraints – roles, processes, rules, requirements – that prevent teams from working on the right opportunities.
Strukturelle Einschränkungen – Rollen, Prozesse, Regeln, Requirements – die Teams daran hindern, an den richtigen Opportunities zu arbeiten.
Four forces – Trust, Knowledge, Connection, Assumption Testing – that strengthen the team's space from outside.
Vier Kräfte – Trust, Knowledge, Connection, Assumption Testing – die den Handlungsraum des Teams von außen stärken.
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 before the transformation starts – 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, bevor die Transformation startet – 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.
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 konkreter Outcome: eine Veränderung im Verhalten von Nutzern, die Business-Ergebnisse erzeugt. Nur eine Gruppe in Ihrer Organisation kann das leisten – die Teams, die mit Nutzern interagieren, Hypothesen testen und aus dem lernen, was wirklich passiert.
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, hört das Testen von Hypothesen vollständig auf. 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 Prozesskonfirmität, nicht Liefergeschwindigkeit. Achtzehn Jahre später sah sich Josh Seiden genötigt, es in Outcomes Over Outputs (2019) zu wiederholen: „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.
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 problems?
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 problems. Maximum impact possible.
The team is working on the most important problem, but also serving a boundary in parallel. Impact is reduced.
Boundaries dominate. The team is mainly working on assigned tasks, not on problems 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.
Boundaries describe what constrains a team. The Compass describes the opposite: moments when work has real impact and gives energy – despite all obstacles.
Boundaries can be pushed back from the outside – through trust given by leadership (Trust), through knowledge that expands the action space (Knowledge), through connections to new problems (Connection), and through testing assumptions that generate feedback (Assumption Testing). Each of these four forces enlarges the Capability Space – not by directly removing boundaries, but by demonstrating that the team is capable of carrying more.
This counterweight is essential. Without visible moments of success, teams gradually lose the willingness to name boundaries honestly at all. The Compass also marks the turning point: when these four forces are strong enough, teams gain the space to pursue their own goals – and that is exactly when coaching becomes most effective. In the retrospective, four Compass categories are actively reflected on:
We actively tested assumptions about problems and solutions – and received real feedback that confirmed or corrected our direction.
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.
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 dadurch, dass Hindernisse aus dem Weg geräumt werden.
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 war das Team überhaupt in der Lage, Ziele zu setzen, die es selbst für realistisch hält? Wenn nicht, verlagert sich die Frage an die Organisation. Erst wenn ein Team selbstgesetzte Ziele verfehlt, wird Coaching wirklich wirksam – dann geht es darum, dem Team zu helfen zu verstehen, warum es seine eigenen Commitments nicht erfüllt hat.
Capability Spaces nennt vier typische Hindernisse – Boundaries (Grenzen des Handlungsraums) – die Teams daran hindern, an den wirklich wichtigen Problemen zu arbeiten:
Teammitglieder können nicht an den Problemen arbeiten, für die sie eigentlich die richtigen Fähigkeiten hätten – weil ihre Rolle es nicht erlaubt.
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. Das umgeht die Fähigkeit des Teams, Hypothesen zu bilden und zu testen, vollständig.
Bestehende Abläufe verhindern, dass Teams eigenständig entscheiden oder etwas ausprobieren können – egal wie sinnvoll das Ziel wäre.
Implizite Spielregeln schränken den Spielraum ein, ohne dass das jemand bewusst entschieden hat. Sie sind 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 nicht benennt, dreht das Team 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 Problemen arbeiten?
Das Ampel-System lässt sich in jedem Arbeitsformat nutzen – in einem wöchentlichen Team-Meeting, einer Retrospektive oder einem eigens dafür eingerichteten Format, bei dem Führungskräfte dabei sind und Boundaries direkt miterleben.
Das Team arbeitet eigenständig an seinen wichtigsten Problemen. Maximale Wirkung möglich.
Das Team arbeitet am wichtigsten Problem, muss aber parallel eine Boundary bedienen. Wirkung eingeschränkt.
Boundaries dominieren. Das Team arbeitet hauptsächlich an vorgegebenen Aufgaben, nicht an eigenen Problemen.
Gelb oder Rot löst keine Kritik aus – sondern 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.
Boundaries beschreiben, was ein Team einschränkt. The Compass beschreibt das Gegenteil: Momente, in denen die Arbeit wirkt und Energie gibt – trotz aller Hindernisse.
Boundaries können von außen aufgebrochen werden – durch Vertrauen, das Führungspersonen geben (Trust), durch Wissen, das den Handlungsraum erweitert (Knowledge), durch Verbindungen zu neuen Problemen (Connection) und durch das Testen von Annahmen, das Feedback erzeugt (Assumption Testing). Jede dieser vier Kräfte vergrößert den Capability Space – nicht weil sie Boundaries direkt entfernt, sondern weil sie zeigt, dass das Team in der Lage ist, mehr zu tragen.
Dieses Gegengewicht ist entscheidend. Ohne sichtbare Erfolgsmomente verlieren Teams über Zeit die Bereitschaft, Boundaries überhaupt noch ehrlich zu benennen. Der Compass markiert auch den Wendepunkt: Wenn diese vier Kräfte stark genug sind, gewinnen Teams den Raum, eigene Ziele zu verfolgen – und genau dann wird Coaching am wirksamsten. In der Retrospektive werden vier Compass-Kategorien aktiv reflektiert:
Wir haben Annahmen über Probleme und Lösungen aktiv getestet – und echtes Feedback bekommen, das unsere Richtung bestätigt oder korrigiert hat.
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.
Scrum is a delivery framework. It assumes the team is already empowered – but doesn't ask whether the conditions actually allow for that.
The real question is not whether a team delivers. It is whether it can work on the right problems – and generate outcomes, not just outputs. That is the coach's task: enabling teams to work in an outcome-oriented way. But coaching is most effective when a team has self-set goals and misses them. That is the diagnostic moment: not failure of character, but a signal about what the team needs to close the gap between its own intentions and its results. Capability Spaces gives coaches the diagnostic to answer exactly this question: where is the organisation structurally preventing outcome-oriented work? And what needs to change for the team to get there?
Impediments describe disruptions in process. Boundaries describe why the team cannot work on the right problems at all. Only those who see this difference can enable real change.
| Aspect | Scrum / Impediment | Capability Spaces / Boundary |
|---|---|---|
| Focus | Process improvement within the sprint | Team empowerment – can it solve the right problems? |
| Who sees obstacles? | Scrum Master and team; leadership receives reports | Leadership experiences boundaries live in a shared format |
| What is named? | What disrupts the process | What prevents work on the most important opportunity (problem) |
| Response | Escalation by Scrum Master – leadership reacts to reports | Leader as active boundary owner, anchored in the format |
| Energy & motivation | Sprint Review shows delivery progress | The Compass shows why work makes sense despite boundaries |
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?
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.
A dedicated weekly format with leaders. Teams name traffic-light status and active boundaries directly. Leadership experiences live what constrains teams.
Boundaries as an explicit category on the board. Prioritised and assigned in the stand-up with leadership.
Traffic-light status before every Weekly. Side Topics name active boundaries – escalable, visible to leadership.
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.
Scrum ist ein Lieferframework. Es setzt voraus, dass das Team bereits empowered ist – fragt aber nicht, ob die Rahmenbedingungen das überhaupt erlauben.
Die eigentliche Frage ist nicht, ob ein Team liefert. Sondern ob es an den richtigen Problemen arbeiten kann – und Outcomes erzeugt, nicht nur Outputs. Das ist die Aufgabe von Coaches: Teams dazu zu befähigen, outcome-orientiert zu arbeiten. Coaching ist dabei am wirksamsten, wenn ein Team selbstgesetzte Ziele verpasst. Das ist der diagnostische Moment: kein Charakterversagen, sondern ein Signal darüber, was das Team braucht, um die Lücke zwischen seinen eigenen Absichten und seinen Ergebnissen zu schließen. Capability Spaces gibt Coaches die Diagnose, um genau diese Frage zu beantworten: Wo verhindert die Organisation strukturell outcome-orientiertes Arbeiten? Und was muss sich verändern, damit das Team dorthin kommt?
Impediments beschreiben Störungen im Prozess. Boundaries beschreiben, warum das Team nicht an den richtigen Problemen arbeiten kann. Nur wer diesen Unterschied sieht, kann echte Veränderung ermöglichen.
| Aspekt | Scrum / Impediment | Capability Spaces / Boundary |
|---|---|---|
| Fokus | Prozessverbesserung im Sprint | Empowerment des Teams – kann es die richtigen Probleme lösen? |
| Wer sieht Hindernisse? | Scrum Master*in und Team; Führung erhält Reports | Führung erlebt Boundaries live im gemeinsamen Format |
| Was wird benannt? | Was stört den Prozess | Was verhindert Arbeit an der wichtigsten Opportunity (Problem) |
| Reaktion | Eskalation durch Scrum Master*in – Führung reagiert auf Berichte | Führungskraft als aktive Boundary-Owner*in im Format verankert |
| Energie & Motivation | Sprint Review zeigt Lieferfortschritt | The Compass zeigt, warum die Arbeit trotz Boundaries Sinn ergibt |
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 löst das anders.
Führungskräfte sind nicht Empfänger*innen von Berichten. Sie sitzen live dabei – in einem dedizierten Format, das in jeden bestehenden Rahmen passt: ein wöchentliches Meeting in Scrum, ein Kanban-Jour-Fixe, ein OKR Weekly. Der entscheidende Punkt ist, dass Führung dabei 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?
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. Sie brauchen kein neues Tool, keinen neuen Prozess, keine neue Rolle. Sie brauchen 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.
Eigenes wöchentliches Format mit Führungskräften. Teams benennen Ampelstatus und aktive Boundaries direkt. Führung erlebt live, was Teams einschränkt.
Boundaries als explizite Kategorie im Board sichtbar. Im Jour-Fixe mit Führung priorisiert und zugewiesen.
Ampelstatus vor jedem Weekly. Side Topics benennen aktive Boundaries – eskalierbar, für Führung sichtbar.
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 einen konzeptionellen Gegenentwurf: Teams werden nicht nach Themen geschnitten, sondern danach, welche Probleme sie eigenständig identifizieren und lösen können. Skalierung entsteht dann durch das natürliche Wachstum der Spaces – nicht durch periodisches Org-Design von oben.
Wer tiefer in die Frage des Team-Schnitts einsteigen möchte, findet in Team Topologies (Skelton & Pais) ein ergänzendes Modell: Teams nach Kognitionsbelastung 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. Es ist das Ergebnis davon, dass Teams kontinuierlich wachsen – in Fähigkeiten und in Verantwortung. Boundaries zeigen, wo dieser Wachstumsprozess gerade hängt.
If you're not deeply familiar with agile frameworks, here's what they each do – and where they all share the same blind spot.
Wenn du die agilen Frameworks nicht alle kennst: Hier ist, was sie jeweils leisten – und wo sie alle denselben blinden Fleck haben.
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, 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.
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 startet nicht von allein. 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, haben eine andere Arbeitsweise verinnerlicht: Anforderung empfangen, Feature bauen, abhaken. Die Reorientierung auf das Problem hinter dem Auftrag — und auf den Outcome, den 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.
Einen Outcome zu erreichen bedeutet, dass 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 ist ein strukturelles Missverständnis. 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.
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. Es zieht dabei eine klare Linie: zwischen Zielen, die von außen auferlegt werden, und Zielen, die ein Team selbst setzt.
Sie verbessern die Teamdynamik, benennen die Impediments, coachen den Prozess. Aber dieselben Blocker kommen jeden Sprint zurück. Das Team wächst nicht. Das ist nicht zwingend ein Coaching-Versagen – es kann bedeuten, dass das Team nie in der Lage war, überhaupt eigene Ziele zu setzen.
Sie haben die Transformation genehmigt. Sie haben Ressourcen bereitgestellt. Sie sehen den Aufwand. Aber die Team-Performance bleibt 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 eine Reihe von leichtgewichtigen, 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 second 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 zweiten 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.
Most teams using Jira have hundreds of tickets, hundreds of dependencies, and no clear picture of what they are actually trying to change. The root cause is almost always the same: tickets describe solutions, not problems. 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. If you are doing Scrum, the Sprint Goal should describe what will be different for users at the end — not what the team plans to ship.
On transparency: 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 Teams, die Jira nutzen, haben hunderte Tickets, hunderte Abhängigkeiten — und kein klares Bild davon, was sie eigentlich verändern wollen. Die Ursache ist fast immer dieselbe: Tickets beschreiben Lösungen, keine Probleme. 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. Wenn Scrum gemacht wird, sollte das Sprint Goal beschreiben, was sich am Ende für Nutzer verändert hat — nicht was das Team plant auszuliefern.
Zur Transparenz: 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.
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, für die das Team gerade Lösungsexperimente macht? 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.