Marcel van Oosterwijk

Category: Capabilities

Organizational capabilities, responsibilities, governance, ways of working, transformation, and how organizations develop and sustain their ability to achieve outcomes.

  • Practice Note: Understanding Debt

    Development projects rarely start with a clean sheet of paper. Every new feature, enhancement or migration inherits the consequences of decisions made years before. Teams often discover that seemingly straightforward changes become unexpectedly expensive, estimates become unreliable and developers hesitate to modify important parts of the system. We usually describe this phenomenon as technical debt.

    Technical debt is often compared to financial debt. A shortcut taken today may accelerate delivery, but the resulting complexity must eventually be repaid through slower development, greater maintenance effort and increased risk. Left unmanaged, technical debt gradually reduces an organization’s ability to evolve its products.

    Technical debt is commonly divided into several categories.

    • There is code debt, where implementation has become unnecessarily difficult to maintain or extend.
    • There is test debt, where insufficient automated regression testing reduces confidence that changes preserve existing behavior.
    • And there is documentation debt, where documentation is missing, incomplete or outdated.

    I have started wondering whether the third category describes the symptom rather than the underlying problem. Perhaps the deeper problem is understanding debt. Documentation is only one way of preserving understanding.

    Understanding can also be lost because experienced people leave, architectural decisions are forgotten, business rationale disappears, names become disconnected from the problem domain, or relationships between artifacts are no longer visible.

    The visible product survives. Its explanation does not. That changes the nature of the debt. Code debt makes implementation difficult. Test debt makes changes difficult to trust. Understanding debt makes it difficult to know what should be changed, what should remain unchanged, and why the system looks the way it does.

    This distinction also helps explain something I have always appreciated about Behavior-Driven Development (BDD). BDD is often described as executable documentation. I still believe that is one of its greatest strengths. BDD preserves the observable behaviour of a system.

    A scenario such as:

    Given a Gold customer

    When an order exceeds €50

    Then shipping is free

    tells future developers exactly what behaviour is expected.

    But BDD deliberately answers a different question. It explains what the system should do. It does not attempt to explain why Gold customers receive free shipping.

    Perhaps the rule originated from a marketing campaign, a contractual agreement, a legal obligation or a business strategy that has since changed. Those reasons belong somewhere else.

    This made me realise that different product artifacts preserve different kinds of knowledge.

    • Business decisions preserve intent.
    • Architecture Decision Records preserve technical rationale.
    • Architecture preserves structural decisions.
    • Code preserves implementation.
    • BDD scenarios and tests preserve expected behaviour.
    • The Product Reference Model preserves where these artifacts live and how they relate to one another.

    None of these artifacts should be expected to preserve everything. Together they preserve understanding. Understanding debt therefore cannot be solved simply by writing more documentation. It requires preserving the why, the how, and the what of the product. Only then can future teams reconstruct not merely how the system behaves, but why it became the system they inherited.

    Perhaps documentation debt should therefore not disappear as a concept. Instead, it should be recognized as one of several causes of understanding debt. The objective is not to produce more documents. The objective is to preserve enough understanding that future people can continue the story instead of starting over.

  • Practice Note: Who Owns the Product Reference Model?

    The idea of a product reference model creates an immediate question:

    Who owns it?

    If the model describes what the product is intended to achieve, the conditions under which it must operate, the quality expected of it and the evidence needed to judge it, ownership cannot remain implicit. Many people may contribute to the model. Someone must still own whether it forms a coherent whole. That responsibility naturally belongs to Product Ownership.

    Ownership Does Not Mean Writing Everything

    A Product Owner cannot personally define every part of the product reference model.

    Architects contribute technical constraints. Security specialists contribute controls and risks. Developers contribute feasibility and implementation knowledge. Testers contribute evidence needs and ambiguity detection. Operations contributes knowledge of production reality. Customers and users contribute expectations and desired outcomes.

    Leadership also contributes by setting strategic direction, investment boundaries, customer commitments and acceptable levels of risk. All of these inputs may be valid. But a collection of valid inputs is not yet a coherent product model. Someone must ensure that they fit together.

    Leadership Sets the Boundaries

    Leadership defines the space in which the product is expected to operate. It determines strategic direction, business outcomes, investment limits, policy constraints and acceptable risk.

    These decisions shape the product, but they do not automatically translate into something that can guide development and assessment. That translation belongs closer to the product. Leadership defines the boundaries. Product Ownership determines what the product must become within those boundaries.

    Leadership also has to provide the conditions needed to meet its expectations. A product cannot be expected to be secure, resilient, scalable and compliant without sufficient time, competence, authority and investment. Constraints without enabling conditions become governance theatre.

    Product Ownership Owns Integrity

    The Product Owner does not need to be the greatest expert in every dimension of the product. The Product Owner does need to ensure that the different dimensions form one coherent whole.

    That means connecting business objectives to product outcomes, making constraints visible, resolving important trade-offs, recognizing risks and ensuring that quality expectations and evidence needs are explicit. The central responsibility is therefore not authorship. It is integrity. The Product Owner owns the integrity of the product reference model.

    Specialists remain responsible for the validity of their contributions. The architect must provide credible architectural guidance. The security specialist must provide credible security expertise. The tester must identify meaningful evidence. The developer must explain technical implications.

    But those contributions should not remain separate professional perspectives. They must still describe one intended product.

    The Product Owner as Custodian

    The product reference model is not finished when the initial requirements are written. It changes as the organization learns. Operational incidents may reveal false assumptions. Larger customers may expose scalability limitations. Regulation may change. User behavior may challenge expectations. Business priorities may shift.

    Someone must ensure that the model changes with the product and its context. This is why the Product Owner is best understood as the custodian of the product reference model. A custodian does not create every element. A custodian ensures that the whole remains coherent, current and useful.

    Leadership defines direction, constraints and acceptable risk. Specialists ensure that their contributions are credible. Product Ownership ensures that it all still describes one product.

  • Practice Note: An Assessment Is a Snapshot. Improvement Requires Reassessment.

    I have usually thought of an assessment as a one-time intervention. We define a reference model, collect evidence, judge the current state and identify improvements. The result is a snapshot. That is useful for diagnosis.

    But it is not enough when the purpose is improvement. Once change begins, the subject of the assessment starts to move. Practices change. Responsibilities shift. New evidence appears. Some improvements work, others do not. New weaknesses become visible. The original assessment gradually becomes a description of a state that no longer exists.

    An assessment may be a snapshot. Assessment should be a recurring capability.

    The first assessment establishes a baseline

    A thorough initial assessment remains valuable. It clarifies:

    • what is being assessed;
    • what good looks like;
    • the current state;
    • important strengths, weaknesses and risks;
    • priorities for improvement.

    Without that baseline, improvement can become a collection of disconnected actions. But the baseline is only the beginning.

    Improvement creates new evidence

    Every improvement action is also a hypothesis. We expect that changing a process, role, tool, structure or behaviour will lead to a better result.

    That expectation should be tested. Did the change actually happen? Did behaviour improve, or only documentation? Did the intended result appear? Did the improvement create new problems elsewhere?

    Without reassessment, these questions are often answered through impressions or completion reports.

    But completing an improvement is not the same as achieving improvement. Reassessment brings the organisation back to evidence.

    Reassessment does not mean repeating everything

    Continuous assessment does not require a full formal assessment every sprint or every month. That would quickly become bureaucratic. Reassessment can happen at different depths. A lightweight review may examine recent evidence and a few critical indicators. A periodic deeper assessment may revisit the complete reference model. A major change, failure or shift in context may trigger an earlier reassessment.

    The principle is simple:

    Reassess often enough to learn whether improvement is actually happening.

    The reference model may also change

    Reassessment is not merely updating a score against a fixed model. As understanding improves, the definition of good may also evolve. Some expectations may prove irrelevant. New capabilities may become important. The organisation may discover that its original target state was incomplete or misguided.

    Reassessment should therefore ask two questions:

    Are we moving closer to what we defined as good?

    And:

    Is our definition of good still the right one?

    From report to improvement loop

    A static assessment often ends with findings and recommendations.

    A continuous assessment process closes the loop:

    reference model

    → evidence

    → judgement

    → decision

    → improvement

    → new evidence

    → reassessment

    The assessment should therefore identify not only what needs to improve, but also:

    • what evidence will show progress;
    • when reassessment will occur;
    • what should trigger an earlier review;
    • which assumptions remain uncertain.

    Assessment then becomes part of the improvement system rather than an event before improvement begins.

    The real purpose of reassessment

    The purpose is not to prove that the plan was followed. It is to discover whether the plan was right. Reassessment helps the organisation detect ineffective improvements early, adapt priorities, expose unintended consequences and remain focused on outcomes rather than activity.

    An assessment tells us where we are. Reassessment tells us whether we are actually moving—and whether we are still moving in the right direction.

  • Practice Note: Quality Is the Integrity of the Chain

    We usually discuss software quality somewhere in the middle of the product lifecycle. Requirements have been defined. Work has entered the backlog. Engineering has started. Testing, Quality Assurance and Quality Engineering help ensure that the software is built and delivered well.

    But the product’s quality story began earlier. It began when the organisation formed an intention: solve a problem, serve a customer, enter a market, reduce a cost or create a business outcome.

    And the story does not end when the product is released. It ends—if it ends at all—when we can understand whether the product produces the outcome for which it was created.

    This suggests a broader definition:

    Quality is the integrity of the chain from business intent to business outcome.

    The chain

    The chain may be expressed simply:

    Business intent

    → product decisions

    → engineering delivery

    → operational reality

    → business outcome

    Each link translates something into something else.

    Business ambition is translated into a product direction. Product direction is translated into capabilities, priorities and quality expectations. These are translated into engineering decisions and working software. The software enters an operational environment where customers, users, integrations, data and real workloads affect its behaviour. That behaviour contributes—or fails to contribute—to the intended outcome. Quality depends on the integrity of all these translations.

    How the chain breaks

    A product may fail because the original intent was unclear. It may fail because the organisation misunderstood the customer need or selected the wrong route to its ambition. It may fail because the right intent was translated into the wrong product. It may fail because engineering realised the product poorly. It may function as designed but prove unreliable, difficult to use, expensive to operate or impossible to scale. It may operate successfully and still fail to produce adoption, efficiency, customer value or commercial results.

    These failures look different, but they share something important:

    Somewhere between intent and outcome, the chain lost integrity.

    This expands the meaning of a quality failure. A defect is a quality failure. But so is building a technically excellent capability that customers do not need. So is improving performance when the real obstacle to enterprise adoption is permissions, auditability or integration. So is meeting every acceptance criterion while failing to create the intended outcome.

    Different disciplines protect different parts

    Testing, Quality Control, Quality Assurance and Quality Engineering remain essential. But they do not protect the complete chain. Testing guards against not knowing how the product behaves. Quality Control guards against accepting outputs that do not conform to defined expectations. Quality Assurance guards against relying on processes and controls that cannot consistently produce dependable results. Quality Engineering guards against treating quality as something that can be inspected into the product at the end. Each protects an important part of the chain.

    Product-quality assessment asks a more complete question:

    Does the available evidence support the judgement that the product is right, good enough for its intended context and capable of producing its intended outcome?

    It therefore guards against false confidence. Tests may pass. Requirements may be met. Delivery metrics may be healthy. The system may operate as designed. The organisation may still be wrong about the product.

    The role of Product Ownership

    Someone must preserve continuity of intent as the product moves through the chain. That does not mean one person owns every quality decision. But Product Ownership has a central responsibility for maintaining coherence between:

    • the business ambition;
    • customer and stakeholder needs;
    • product decisions;
    • quality expectations;
    • engineering work;
    • operational evidence;
    • product learning.

    Product Ownership should not merely feed work into engineering. It should help ensure that what emerges from engineering can still be traced to the purpose that justified the investment—and that evidence from operation changes future product decisions.

    The role of governance

    Product-quality assessment creates a basis for judgement. Governance determines what happens next. Leadership must decide:

    • which outcomes and risks matter;
    • what evidence is sufficient;
    • which trade-offs are acceptable;
    • who may accept remaining risk;
    • whether to release, invest, redirect or stop.

    This is why the complete view of quality cannot be delegated to testing or contained within delivery. It reaches into product strategy, investment and accountability.

    The economic meaning of integrity

    When the chain lacks integrity, the organisation pays in several ways. It pays the cost of being wrong when it invests in the wrong capability, assumption or market response. It pays the cost of failure through defects, incidents, disruption and lost trust. It pays the cost of operation through support demand, workarounds and recurring interventions. It pays the cost of future change when complexity, weak maintainability and unclear intent make every next improvement slower and more expensive.

    When the chain retains its integrity, the organisation increases the likelihood that engineering effort becomes product value and that product value becomes business outcome. That may be the most complete business definition of quality:

    Quality is the integrity of the chain from business intent to business outcome.

    Everything else helps us understand where that chain can break, what evidence reveals its condition and how the organisation should respond.

  • Practice Note: Product Ownership Has a Business Side. Where Are Its Tools?

    Product Ownership carries broad business accountability.

    The Product Owner is expected to understand customers, engage stakeholders, maximize value, establish product goals, make trade-offs, order the backlog and inspect outcomes. These responsibilities sound substantial.

    But when we look for practical tools to perform them, the picture becomes less clear. “Understand the customer” is not a customer-analysis technique. “Manage stakeholders” is not a method for reconciling conflicting interests. “Maximize value” does not explain how value should be defined, compared or assessed. “Inspect and adapt” does not tell us which evidence matters or how it should influence product direction.

    The Product Owner is told what to think about. But where are the tools for doing the work?

    Engineering has a visible operating model

    Scrum gives engineering delivery a clear structure:

    Product Backlog → Sprint → Increment → inspection and adaptation

    The roles, events, artifacts and commitments make the work visible. A team can discuss whether backlog items are ready, whether the Sprint Goal is clear, whether the Increment is Done and what should change next. The Product Owner appears at the beginning of this flow through the backlog.

    But the backlog is not the beginning of Product Ownership. Before something becomes a story, a much broader translation should already have taken place. Someone must connect:

    • business and product strategy;
    • customer and stakeholder needs;
    • intended outcomes;
    • assumptions and risks;
    • quality expectations;
    • business and operational constraints;
    • dependencies and wider product context;

    to something engineering can understand and act upon. The story is the visible engineering-facing output. The reasoning that should produce it remains largely hidden.

    Scrum hides the business perspective behind the Product Owner

    Scrum gives Product Ownership broad accountability but only a thin formal operating structure outside backlog and delivery. Advanced Product Owner training adds useful stances, exercises and techniques, but these do not necessarily form an explicit lifecycle model for translating business intent into engineering work and operational evidence back into business learning.

    SAFe provides more—but spreads it out

    SAFe makes more of the business perspective visible. It introduces concepts such as Product Management, customer centricity, design thinking, roadmaps, epics, features, non-functional requirements, Lean Business Cases and outcome hypotheses. That is more operational support than Scrum provides on its own.

    But the broader Product Ownership capability is also distributed across many roles, levels and artifacts. Strategy may sit with portfolio leadership. Product Management may own vision and features. Product Owners manage team backlogs. Business Owners represent broader outcomes. Architects address technical direction. Operations and support hold important evidence after release. The pieces exist.

    What is harder to see is the model that keeps them coherent. Who maintains the complete connection between:

    • why the product exists;
    • who it serves;
    • what quality means;
    • which assumptions and risks matter;
    • what engineering is asked to build;
    • what evidence the organisation receives;
    • what production teaches us;
    • what should change next?

    Scrum hides much of the business perspective behind one Product Owner. SAFe exposes more of it, but risks fragmenting it across the organisation.

    Why Product Owners are pulled downstream

    The most practical tools and recurring activities available to Product Owners are usually engineering-facing:

    • backlog refinement;
    • story clarification;
    • prioritisation;
    • Sprint Planning;
    • answering team questions;
    • accepting completed work.

    These activities are concrete, visible and urgent. They are also supported by the delivery rhythm.

    The upstream work is less structured. So is the work after Done and release. How should a Product Owner translate strategy into a coherent product perspective? How should production incidents, support calls, customer behavior and outcomes be interpreted? How should that learning change product priorities and future engineering work?

    Without equally practical tools for these responsibilities, the role is naturally pulled towards the part of the system where the work is clearest. Product Owners may not choose to become backlog administrators. The operating model pulls them there.

    The backlog is not enough

    The backlog is an essential engineering-facing artifact. It organizes and prioritizes work. It supports refinement and delivery. But it cannot carry the complete business perspective of the product. It is not designed to preserve all relevant knowledge about purpose, stakeholders, outcomes, quality, risks, context, evidence and learning. Yet in many organisations, it is the primary practical instrument provided to the Product Owner.

    Product Ownership will remain centred on backlog administration as long as the backlog is the only operational tool we provide.

    In search of a broader model

    Perhaps Product Ownership needs a more explicit way to maintain the product perspective across the lifecycle.

    Something that helps connect:

    business intent → product definition → engineering work → delivery evidence → production experience → outcomes → learning

    It may need to preserve intended outcomes, stakeholders, quality expectations, assumptions, risks, constraints, operating context and required evidence. Perhaps this could eventually take the form of a product reference model.

    We do not yet know exactly what that model should contain or how it should work. But the gap is becoming visible. Product Ownership has a business side. It carries broad accountability for that business perspective.

    What it still lacks are the practical tools to keep that perspective coherent before, through and after engineering.