A recurring idea across the Practice Notes is that organizations often reason about capability through the things they can see. Processes are visible. Roles are visible. Governance forums are visible. Tools are visible. Framework practices are visible. Training can be completed. Documents can be inspected. Structures can be compared. This makes them convenient objects for assessment and transformation.
But the Practice Notes repeatedly argue that these things are not the capability itself. A capability concerns something more fundamental: What an organization is actually able to do.
That creates a distinction between capability and realization. The realization consists of the organizational arrangements through which the capability currently exists. The capability is the organizational ability those arrangements are supposed to create or sustain. Taken together, the Practice Notes suggest a general principle: Capabilities should be defined and judged by organizational ability, while processes, roles, tools, structures, practices and frameworks should be treated as possible realizations of that ability.
This is the Capability–Realization Separation.
Capability Is an Ability
The strongest starting point appears in Assessing Capabilities, Not Processes. The Practice Note questions the assumption that process maturity is an adequate proxy for organizational effectiveness. Some organizations can score highly against process-oriented models while producing weak results; others operate with lighter processes and perform well.
The note therefore shifts the object of assessment. A capability describes what the organization is able to do. Examples include managing quality risks, designing effective test strategies, learning from production incidents and making informed release decisions. This is already more abstract than process.
A capability such as manage significant quality risks does not require one specific ritual. One organization may use formal risk workshops and governance. Another may depend on continuous collaboration among experienced practitioners. A third may automate parts of risk detection. The arrangements differ. The required ability may remain substantially the same.
The Practice Note states the distinction explicitly:
A capability describes an outcome-oriented ability.
A practice describes one way of realizing that ability.
Realization Is Contingent
Once capability and realization are separated, organizational arrangements become contingent. A process may be useful without being essential in its current form. A governance meeting may perform an important function without that function requiring a meeting forever. A tool may enable a capability without defining it. A role may currently concentrate responsibility without being the only possible way to organize that responsibility.
This matters because practices evolve. The Practice Notes explicitly observe that techniques, methods and practices come and go while the underlying organizational need often persists.
A capability should therefore be stable enough conceptually to survive changes in realization. Otherwise every major organizational redesign would appear to create a completely different capability merely because its visible arrangements changed.
Process Presence Is Evidence, Not Proof
The separation changes Assessment immediately. Traditional process-oriented questions might ask:
- Is there a documented strategy?
- Does the retrospective occur?
- Is the dashboard maintained?
- Does governance meet?
These are legitimate observations. But the Practice Notes repeatedly warn against treating them as conclusions.
A documented test strategy does not demonstrate sound testing decisions. A retrospective does not prove learning. A dashboard does not prove insight. A governance process does not prove control. A strategy document does not prove alignment. The visible artifact can provide evidence about the realization. The capability judgment asks something else:
Can the organization reliably achieve the outcome the arrangement is supposed to support?
This creates a useful distinction:
realization evidence ≠ capability judgment
An organization might have excellent documentation and weak organizational ability. Another might have unconventional arrangements but strong capability. Therefore an Assessment that only checks the realization risks confusing conformity with effectiveness.
Framework Adoption Is Not Capability Development
The same distinction appears in transformation. Organizations often describe transformation by the visible thing being introduced: SAFe transformation. Agile transformation. AI transformation. Quality transformation. Then progress becomes visible as roles, ceremonies, governance, tools and structures appear.
But “What Are We Actually Transforming?” challenges exactly this logic. The presence of new roles, events, backlogs and governance forums does not establish that the organization has improved the abilities that motivated the transformation.
A framework provides one possible realization. It may contain extremely useful professional knowledge. But it is instrumental.
The Practice Notes make the consequence explicit:
an organization can become increasingly faithful to a framework without becoming increasingly capable.
The transformation question should therefore be:
Which organizational capabilities are we trying to strengthen?
rather than:
How completely have we implemented the framework?
The framework becomes a possible means rather than the target.
Interventions Are Changes to the Realization
This distinction also clarifies what an organizational intervention actually does. Training changes competence. A new tool changes available technology. A governance forum changes decision structures. A new role changes responsibility or authority. A process redesign changes coordination. A reorganization changes structural relationships. These interventions change the realization. They do not directly guarantee capability. One Practice Note makes this exceptionally concrete by asking what the increment of capability development actually is.
It is not the workshop. It is not the training. It is not the tool. The increment is the change in organizational ability. This produces a stronger completion criterion. Completing planned interventions demonstrates that Development activity occurred. It does not demonstrate that capability changed. The relevant question is whether the organization can now do something it previously could not do reliably enough. So:
intervention completed ≠ capability improved
Adoption Is Not Ability
That distinction implies several stages between organizational change and organizational effect. An intervention can be implemented without being adopted. It can be adopted without changing organizational ability. Organizational ability can improve without producing the expected organizational effect. The Practice Notes therefore resist collapsing activity into outcome. A training program might be successfully delivered. People might even attend it.
But the capability claim might concern whether teams can now make better risk-informed decisions under actual delivery pressure. Those are different claims. The realization is where Development intervenes. Capability is what Development is trying to change. The effect is why the capability mattered in the first place. This prevents transformation reporting from mistaking visible activity for meaningful change.
The Same Capability Can Have Different Realizations
The separation is also important because organizational context differs. The Practice Notes explicitly state that organizations can realize the same capability differently. One might rely on formal governance, documented procedures and predefined workflows. Another might achieve similar results through experienced practitioners, strong relationships and adaptive collaboration. That does not mean every realization is equally good.
It means the realization must be evaluated against the required capability rather than against resemblance to another realization. This creates space for context. Formal controls may be necessary in a regulated environment. They may be excessive elsewhere. Highly distributed organizations may need more explicit coordination than small co-located teams. High-risk work may justify stronger assurance. The capability requirement constrains the realization without uniquely prescribing it.
Capability Requires Appropriate Abstraction
This has consequences for Reference Models. A Capability Reference Model cannot simply reproduce one operating model. The Practice Notes explicitly warn that if a Capability Reference specifies a particular process, role structure and toolset as the definition of good capability, legitimate alternative realizations may be excluded. But the model cannot become so abstract that it says only: have good governance; have appropriate competence; use efficient processes; continuously improve.
Such statements allow almost anything to claim conformity. The Reference Model therefore needs an appropriate level of abstraction. It must be: abstract enough to allow different realizations while also being: specific enough to distinguish capable from incapable organizations. That tension follows directly from the Capability–Realization Separation.
Capability Can Survive Radical Structural Change
Once capability is separated from realization, organizational continuity becomes easier to understand. Suppose a company removes a governance forum. Did it lose governance capability? Not necessarily. Suppose a dedicated testing team disappears and quality responsibility becomes distributed across product teams. Did testing capability disappear? Not necessarily. Suppose a manual approval process is automated. Did the control capability disappear?
Again, not necessarily. The question is whether the functions supporting the required ability still exist in the new realization. This is why the Practice Notes about ritualized practices emphasize recovering function before deciding whether to preserve, simplify, replace or remove an activity. The visible structure may change considerably while the organizational ability is preserved or even strengthened. Conversely, all visible structures may remain while the capability degrades.
A Practice Can Survive After Its Function Is Forgotten
This is the inverse problem. Meetings remain scheduled. Templates continue to be copied. Governance gates survive reorganizations. People learn how to comply. But the rationale disappears. The organization becomes proficient at executing a practice without understanding what it is supposed to accomplish. At that point, the realization can appear healthier than the capability. Compliance remains high. The meeting occurs. The checklist is complete.
But nobody can confidently explain whether the underlying function is still necessary, whether the practice remains effective, or whether another arrangement would work better. This shows why preservation of realization is not the same as preservation of capability.
Capability May Depend on Invisible Realization
The separation also prevents the opposite mistake: assuming only formal structures matter. Some organizational ability may depend strongly on informal mechanisms. Experienced people know whom to contact. A particular person bridges two teams. Informal relationships resolve ambiguities that the formal process cannot. Specialists compensate for unclear responsibility. These mechanisms are part of the realization even if they do not appear in the official operating model.
That matters because apparently strong current outcomes can conceal fragile capability. If organizational performance depends disproportionately on one exceptional person, the effect may exist today while the underlying organizational ability remains unsustainable. This is why capability should not be equated either with formal structure or with current performance alone. The question is whether the organization itself possesses the ability reliably.
Capability Exists Across Multiple Enablers
The Practice Notes increasingly suggest that organizational ability is distributed across many kinds of enabling characteristics: competence; authority; information; relationships; processes; tools; governance; structures; leadership; learning. No single one is the capability. And their mere presence is not enough. Excellent people without authority may be unable to act. Strong tools with poor information may contribute little.
Good processes without competence may become ritualized. Governance without evidence may create only the appearance of control. This suggests that capability is an emergent property of the realization rather than a component contained somewhere inside it. Assessment must therefore reason through relationships among the enablers rather than simply inventory them.
Realization Is Necessary
The Capability–Realization Separation should not be misunderstood as saying realization does not matter. A capability without realization is merely an intention. Organizational ability must exist through something: people, skills, processes, technology, information, relationships, authority, structures. The separation is analytical, not ontological. Capability does not float independently of the organization. Rather: Capability is realized through organizational arrangements without being reducible to any one arrangement.
This distinction makes it possible to ask whether the realization is actually adequate for the ability required.
Development Changes Realization; Assessment Judges Capability
A useful consequence emerges. Capability Development necessarily acts on realization. It changes people, structures, practices, tools, authority or relationships. But its objective is changed organizational ability. Capability Assessment observes realization. It examines processes, artifacts, behavior, decisions, outcomes and experiences. But its judgment concerns organizational ability. So the two disciplines meet at the same separation from opposite directions:
Development:
realization change → intended capability change
Assessment:
realization evidence → capability judgment
Neither should confuse the observable arrangement with the capability itself.
The Persistent Subject Is Capability
This also explains why capability management or stewardship becomes plausible in the later Practice Notes. Improvement projects end. Framework implementations end. Consultancies leave. Organizational structures change. Tools are replaced. Yet the organization may still need the underlying ability. The Practice Notes therefore suggest keeping responsibility connected to the capability itself: What organizational ability do we need?
Why? Under which conditions? What evidence shows that it exists? Where is it weakening? What must evolve? Those questions outlive individual realizations. This means capability is the more persistent subject. Realizations are successive states through which it exists.
Emerging Principle
The Practice Notes establish separately that process maturity may not correlate with organizational effectiveness, practices are means rather than ends, frameworks can be implemented without capability improvement, interventions can be completed without changing ability, rituals can persist after their function is forgotten, and capabilities require continuity beyond individual improvement projects. Taken together, these observations imply: Organizational capability and organizational realization must remain conceptually distinct.
Or more fully: Capability is the organizational ability that must exist; realization is the changing configuration of people, processes, practices, tools, structures and relationships through which that ability is currently produced. This leads to three related rules: Assess the capability, not merely the realization. Develop the capability by changing the realization. Preserve the required ability, not necessarily the existing arrangement.
Synthesis Basis
This Synthesis Note was derived from Practice Notes concerning capability assessment, organizational transformation, capability development, ritualized practices, stewardship and Reference Models.
Primary Practice Notes
- Assessing Capabilities, Not Processes: is the strongest conceptual basis. It defines capability as what an organization is able to do and explicitly distinguishes capability from practices that realize it. Different organizations may realize similar capabilities through different arrangements. Capability is outcome-oriented organizational ability; practices and processes are realizations of it.
- Assessing Capabilities, Not Processes: shows why Assessment must not confuse artifacts with capability. A documented strategy, retrospective, dashboard or governance process may provide evidence without proving the organizational effect it supposedly enables. Visible arrangements are evidence about capability, not the capability judgment itself.
- What Are We Actually Transforming? applies the distinction to organizational change: Framework structures, roles, ceremonies and governance can all be implemented while the intended organizational capabilities remain unchanged. Transformation acts on realization but should be judged by changed organizational ability.
- Agile Capability Development?: makes the same distinction operationally. Workshops, training and tools are interventions; the capability increment is the resulting change in organizational ability. Completed Development activity does not establish that capability has been realized.
Supporting Practice Notes
- When Practices Become Rituals: shows that organizational arrangements can persist after the rationale and function behind them have become unclear. Persistence of the realization does not establish continuing health of the capability.
- From Improvement to Management: shifts responsibility from temporary improvement initiatives toward continued stewardship of the organizational ability itself. Capability persists across successive realizations and therefore becomes the more durable object of stewardship.
- transformation reinforce that a framework may provide useful structures and practices but: is only one possible means of developing the capability the organization actually needs. Frameworks can inform realization without defining capability.
- Practice Notes concerning Reference Models add the abstraction requirement: a Capability Reference should not specify one process, role structure or toolset so concretely that legitimate alternative realizations become impossible.: A capability reference must remain implementation-independent enough to judge multiple realizations.
How the Synthesis Emerged
One Practice Note already makes the core distinction between capability and process. But the wider corpus extends the consequences into several different domains. Assessment shows that realization should be treated as evidence rather than conclusion. Transformation shows that changing realization does not necessarily change capability. Capability Development shows that completion of interventions is not completion of capability change.
Ritualization shows that realization may remain stable while capability understanding deteriorates. Stewardship shows that capability can persist across multiple transformations and organizational structures. Reference Model thinking shows why capability must be described at a level that allows alternative realizations. Together, these ideas establish more than “assess capabilities, not processes.” They establish a general separation between the persistent organizational ability and the contingent organizational arrangement through which it is currently realized.
That is the synthesis: The capability is what the organization must be able to do. The realization is how, for now, it manages to do it.
Leave a Reply