Category: Reflections

  • Blog Retrospective #6

    I have now reached 120 posts.

    In the previous retrospective, I observed that the Body of Knowledge had begun behaving like a learning system. Practice Notes generated theory, theory generated approaches, and those approaches generated new observations that could flow back into the Practice Notes.

    During the latest twenty posts, that process continued.

    But something else happened.

    The inquiry increasingly turned towards the reliability of the understanding we produce.

    Not just what we know about products, capabilities and organizations, but how we know it, what our evidence actually supports, and whether our models might themselves be wrong.

    What Happened?

    The latest cycle explored several apparently different subjects.

    Some notes examined transformation, projects and interventions. Others explored product reference models, contextualization, organizational knowledge and AI. A few returned to everyday observations, including watches and model railway automation.

    The final group emerged directly from developing a standard approach to capability assessment.

    That work raised questions about evidence, contradictions, assessment confidence, sampling and the quality of assessments themselves.

    At first glance, these might seem like separate lines of inquiry.

    But I think they share an underlying concern.

    How do we establish that the mechanisms we use actually achieve their intended purpose?

    A project can deliver successfully without producing the intended change.

    An intervention can be completed without improving organizational capability.

    A product can be extensively documented without being properly understood.

    An assessment can contain considerable evidence without producing a justified conclusion.

    The presence of a mechanism doesn’t establish that the mechanism works.

    That observation has appeared throughout the blog. During this cycle, it became particularly difficult to ignore.

    From Reference Models to Context Layers

    One development I hadn’t anticipated was the connection between reference models and organizational knowledge.

    Earlier work on reference models focused primarily on assessment.

    A reference model provides a conceptual structure against which we can examine a subject. Contextualization helps us interpret that structure in relation to a particular organization, capability or product.

    But what if contextualized reference models could serve another purpose?

    Organizations already possess enormous Bodies of Knowledge. They contain documents, decisions, observations, assessments and accumulated experience.

    AI can make much of this information accessible.

    But accessibility isn’t necessarily understanding.

    Knowing that several documents mention requirements management doesn’t automatically establish how requirements management relates to organizational capabilities, product characteristics, decisions or outcomes.

    Perhaps contextualized reference models could provide part of the structure needed to interpret those relationships.

    That led to the idea of context layers: representations connecting generic concepts to particular organizational subjects and the evidence available about them.

    An interrogable organization might then be able to ask questions that require information from many different sources.

    Not merely retrieving documents, but investigating relationships.

    There is still an important open question.

    How much context must be explicitly modeled, and how much can AI reliably reconstruct when needed?

    I don’t know.

    But the possibility changes how I think about reference models.

    They might be useful not only as instruments for assessment, but also as part of the infrastructure through which an organization understands itself.

    When the Assessment Approach Started Asking Questions

    Perhaps the most interesting development came from working on the capability Assessment Approach.

    The approach was intended to operationalize ideas already developed in the Practice Notes and Continuity work.

    But making those ideas operational exposed questions that deserved attention in their own right.

    One concerned contradictions.

    What should an assessor do when interviews, documentation, observed behaviour and outcomes disagree?

    The obvious response is to reconcile the evidence.

    But perhaps the disagreement itself reveals something important.

    Why does management believe a process works when outcomes repeatedly suggest otherwise?

    Why does a team achieve excellent results despite apparently weak practices?

    Perhaps the contradiction exposes a weakness in our understanding rather than a weakness in the evidence.

    Another question concerned confidence.

    An assessment might conclude that a capability is mature, but how strongly does the evidence support that conclusion?

    A Level 4 capability assessment based on limited evidence is different from a Level 2 assessment supported by extensive observation.

    The assessed condition and our confidence in that condition are different dimensions.

    Then came sampling.

    An assessment can examine evidence rigorously and still produce a misleading conclusion if the evidence represents only a favourable part of the organization.

    We might establish that one team performs effectively without establishing that the organization can reproduce that performance elsewhere.

    Finally, the assessment itself became the subject of inquiry.

    An assessment report may claim to be evidence-based.

    But what justifies that claim?

    Were the right questions asked? Was the evidence representative? Were contradictions investigated? Were conclusions stronger than the evidence warranted?

    That produced Who Assesses the Assessment?

    By the time I finished that note, I was beginning to wonder whether I would ever dare conduct another assessment.

    When Disciplined Curiosity Becomes Indiscipline

    That reaction was useful.

    Each additional question about assessment quality seemed reasonable.

    But taken together, they threatened to make assessment impossibly demanding.

    Every conclusion could be challenged.

    Every sample could be questioned.

    Every interpretation could have alternatives.

    And every assessment of an assessment could presumably require another assessment.

    At some point, the pursuit of justified understanding can become an obstacle to using that understanding.

    This brought me back to Disciplined Curiosity.

    The purpose of assessment is not to eliminate uncertainty.

    It is to develop sufficiently justified understanding for the decisions we need to make.

    The necessary rigor depends on the purpose of the assessment, the consequences of getting it wrong and the resources available.

    Further investigation has a cost.

    So does acting on insufficient understanding.

    Professional judgment includes knowing when additional inquiry is worthwhile.

    Perhaps that is something the Assessment Approach still needs to express more clearly.

    Moving Upstream

    Another recurring theme became more explicit during this cycle.

    A professional can perform an assignment correctly without achieving the purpose that motivated it.

    A tester can thoroughly test the wrong requirements.

    A project manager can deliver a project that produces no meaningful change.

    A consultant can implement an improvement that doesn’t address the underlying problem.

    This led to the question of whether moving upstream is itself a professional quality.

    Perhaps professional competence involves more than executing an assignment.

    It also involves understanding why the assignment matters and recognizing when successful execution may not achieve its intended purpose.

    The AI-related notes added another perspective.

    When AI removes some of the friction involved in implementation, more attention can move towards intent, evidence and judgment.

    That doesn’t make implementation knowledge irrelevant.

    But it may change where human attention creates the most value.

    Looking back, moving upstream has been a recurring movement throughout the blog.

    Testing led to quality.

    Quality led to organizational capabilities.

    Capabilities led to organizational purpose.

    Projects led to interventions and their effects.

    Documentation led to understanding.

    And assessment results led to questions about the justification for those results.

    The subjects changed.

    The underlying curiosity remained remarkably consistent.

    What Surprised Me?

    The biggest surprise was how naturally the Assessment Approach generated new Practice Notes.

    I had expected the approach to apply existing ideas.

    Instead, operationalizing those ideas exposed distinctions that hadn’t previously received sufficient attention.

    That is encouraging.

    It suggests that the relationship between Practice Notes, theory and application can work in both directions.

    But I also noticed a potential danger.

    The ideas are becoming increasingly coherent.

    Almost every new observation can be connected to something already present in the Body of Knowledge.

    That makes synthesis easier.

    It also creates the risk that the framework becomes too good at explaining everything.

    If every observation can be interpreted as supporting the theory, how would we recognize evidence that challenges it?

    The recent note Contradiction Is Information applies just as much to this Body of Knowledge as it does to organizational assessments.

    Perhaps the next important development won’t be another concept that fits neatly into the existing framework.

    Perhaps it will be an observation that doesn’t fit.

    Looking Back at the Whole Blog

    At 120 posts, the scope of the inquiry has changed considerably.

    It began largely with questions about software quality, testing and assessment.

    Those questions led towards organizational capabilities and the conditions required to produce reliable outcomes.

    From there, the inquiry expanded towards products, portfolios, Subject Stewardship and Continuity.

    Then came organizational knowledge, the preservation of decisions and evidence, and the possibility of making accumulated knowledge interrogable.

    The latest cycle has increasingly examined the quality of the understanding produced by those mechanisms.

    There is an interesting symmetry here.

    The early notes questioned whether testing activities were sufficient to establish product quality.

    The recent notes question whether assessment activities are sufficient to establish justified understanding.

    Both challenge the assumption that performing an activity demonstrates that its purpose has been achieved.

    And both lead to questions about the capabilities and conditions needed to produce the intended outcome.

    Perhaps the blog hasn’t moved as far from its original subject as it sometimes appears.

    The subject of Quality Management has simply become broader.

    What Concerns Me?

    I see two concerns worth carrying into the next cycle.

    The first is that abstraction may be moving faster than practical application.

    Some of the newer ideas, particularly around context layers and interrogable organizational knowledge, remain propositions rather than demonstrated approaches.

    They need to encounter reality.

    The second is that the growing coherence of the Body of Knowledge may make it increasingly difficult to challenge its assumptions.

    I don’t want the Practice Notes to become a collection of arguments explaining why the existing theory is correct.

    They should remain a place where observations can challenge the theory, including observations that make earlier conclusions uncomfortable.

    That is also why I think the distinction between observations, interpretations and hypotheses deserves continued attention.

    Not everything that follows logically from an idea has been demonstrated in practice.

    What Next?

    I don’t think the next step necessarily requires another major theoretical synthesis.

    I would rather see what happens when some of these ideas are applied.

    What would a contextualized product reference model reveal about an actual product?

    Would context layers improve an AI assistant’s ability to investigate organizational questions?

    Would the Assessment Approach expose weaknesses or contradictions that a conventional assessment might overlook?

    And perhaps most importantly, what would happen when one of these approaches failed to work as expected?

    Those failures might generate more valuable Practice Notes than another successful conceptual synthesis.

    A Final Observation

    The first retrospectives were largely concerned with the writing process and the ideas emerging from it.

    Later retrospectives examined how the Practice Notes began connecting, generating theory and feeding applications.

    This retrospective has turned towards something different.

    The Body of Knowledge is increasingly examining the mechanisms through which it develops understanding.

    That feels like progress.

    But it also creates a responsibility.

    If I argue that organizations should challenge their assumptions, investigate contradictions and evaluate the evidence supporting their conclusions, the same expectations should apply to my own work.

    The objective cannot simply be to develop an increasingly coherent theory.

    It must remain possible for experience to change that theory.

    Perhaps the most important question for the next retrospective is not what new ideas have emerged.

    It is what I have learned that forced me to reconsider something I previously believed.

  • Exploration: Is Moving Upstream a Professional Quality?

    A tester can execute tests perfectly against the wrong requirements.

    A developer can implement an elegant solution to the wrong problem.

    A project manager can deliver a project successfully without achieving the change it was intended to create.

    A consultant can implement an improvement initiative without improving anything.

    In each case, the professional may have performed the assigned work competently.

    But was it good professional work?

    Looking Beyond the Assignment

    Consider a tester who discovers that a requirement is ambiguous.

    The immediate response might be to request clarification so that testing can continue.

    But perhaps the ambiguity suggests a more fundamental problem with requirements management.

    And perhaps that problem originates in how stakeholders communicate, how decisions are made or how the organization understands customer needs.

    The tester can keep moving upstream.

    From testing to requirements. From requirements to product development. From product development to organizational decision-making.

    At each step, the question changes.

    Not simply How can I do my work better?

    But Why does this work need to be done, and what determines whether it creates value?

    This pattern isn’t unique to testing.

    A developer might question the architecture rather than simply implement another workaround.

    A project manager might question whether the planned deliverables will produce the intended outcomes.

    A consultant might question whether the requested intervention addresses the capability that actually needs improvement.

    In each case, moving upstream means looking beyond the immediate assignment toward the conditions and purposes that give it meaning.

    Is This Professional Development?

    We often associate professional development with increasing expertise.

    A tester becomes better at testing. A developer becomes better at programming. A consultant becomes more proficient in a methodology.

    But perhaps professional development also has another dimension.

    The ability to understand how one’s work contributes to something larger.

    That doesn’t necessarily mean moving into management or changing professions.

    A tester doesn’t need to become a business analyst to recognize weaknesses in requirements.

    A developer doesn’t need to become a product manager to question whether a feature solves the intended problem.

    And a consultant doesn’t need to become a strategist to recognize that implementing a framework is not the same as developing an organizational capability.

    Perhaps moving upstream isn’t about changing what we do.

    It’s about changing how we understand what we do.

    How Far Upstream?

    There is a problem with this reasoning.

    We can always ask another question.

    Why are the requirements poor? Why does the organization work this way? Why were these priorities chosen? Why does the business pursue these objectives?

    Eventually, questioning the purpose of the work can consume more attention than performing it.

    And not every upstream question is useful.

    Sometimes the problem is understood, the assignment is appropriate and the most valuable contribution is excellent execution.

    Specialization exists for good reasons. Deep expertise matters.

    A professional who continually challenges the assignment but cannot perform it well isn’t necessarily demonstrating superior professional quality.

    So perhaps moving upstream is not inherently better.

    The important quality might instead be knowing when the boundaries of the assignment prevent us from addressing the problem.

    And having the judgment to recognize when those boundaries should be questioned.

    When Implementation Becomes Easier

    AI adds another dimension to this question.

    As AI becomes increasingly capable of producing code, tests, documents, analyses and other artifacts, some implementation activities become easier.

    That doesn’t eliminate the need for expertise.

    But it may change where professional judgment contributes the most value.

    If producing a solution becomes easier, choosing the right problem becomes more important.

    AI can help implement what we ask for.

    It cannot make our intentions appropriate merely by implementing them successfully.

    Perhaps this makes the ability to move upstream more valuable.

    Not because everyone should become a strategist, but because the consequences of poorly understood intentions may become easier to realize.

    We may become increasingly effective at doing things without becoming equally effective at determining whether those things are worth doing.

    A Different Dimension of Professional Quality?

    Perhaps we should distinguish three things.

    Competence: Can I perform the assigned work well?

    Understanding: Do I know why the work matters?

    Judgment: Can I recognize when performing the assigned work well will not achieve its intended purpose?

    The first is essential.

    The second provides context.

    The third allows a professional to challenge the relationship between the assignment and its purpose.

    But even this distinction raises questions.

    How much upstream understanding should we expect from a professional?

    When does questioning an assignment demonstrate responsibility, and when does it become interference?

    Can organizations genuinely encourage professionals to challenge assumptions while continuing to evaluate them primarily on how efficiently they complete assigned tasks?

    And what happens when a professional recognizes an upstream problem but has no authority to influence it?

    Perhaps moving upstream is not simply an individual quality. It may also depend on whether the organization is capable of using the understanding that professionals develop.

    Perhaps the Question Is Different

    Maybe professional quality isn’t about moving upstream as far as possible.

    Nor is it about constantly questioning everything.

    It may be about retaining the ability to connect our work to its purpose, and recognizing when that connection is missing.

    A good professional knows how to perform the work.

    A better professional may also recognize when performing that work well is insufficient.

    But that leaves an uncomfortable question.

    If we recognize that the assignment will not achieve its intended purpose, is it still professional to complete it exactly as requested?

  • Practice Note: When Market Friction Becomes a Business Model

    I have always been somewhat uncomfortable with intermediaries whose business models depend on friction in a market.

    Not because intermediaries cannot create value. They certainly can. They help buyers and sellers find each other, facilitate transactions, and sometimes assume risks.

    But what happens when the friction they help overcome could be eliminated altogether?

    And what happens when maintaining that friction becomes more profitable than removing it?

    The Bread Analogy

    Imagine buying a loaf of bread for €5.

    The exact same bread is available elsewhere for €3.50, but you don’t know where.

    An intermediary knows and sells it to you for €5.

    There is nothing inherently wrong with this. You are willing to pay the price, and the intermediary earns a margin.

    But what happens when everyone can instantly discover where the bread is available and compare prices?

    The intermediary’s information advantage disappears.

    Unless the intermediary provides additional value, there is little reason to continue paying the premium.

    The interesting question is not whether the intermediary deserves to make money. It is why the information problem should continue to exist.

    The Consulting Market

    Consider the market for independent consultants.

    A customer needs an experienced consultant and has a budget that reflects that expectation.

    The assignment passes through one or more intermediaries, each taking a percentage of the hourly rate.

    By the time the offer reaches the consultant, the compensation may be considerably lower.

    This is usually discussed as a question of margins.

    But there is a more important consequence.

    An experienced consultant might decline the assignment because the compensation is too low. A less experienced consultant might accept.

    The customer could therefore end up with a less experienced consultant, despite having a budget sufficient to attract someone more experienced.

    Higher compensation does not automatically mean higher competence. But intermediary margins can exclude qualified candidates who would otherwise have accepted the assignment.

    Market friction does not merely consume money. It can influence the quality of what the market delivers.

    What If AI Removed the Bottleneck?

    Today, customers often rely on consulting brokers to reduce the number of candidates they need to evaluate.

    Each broker presents a small selection of consultants. The customer compares a handful of CVs and selects a few candidates for interviews.

    This makes the process manageable.

    But it also means that potentially excellent candidates never reach the customer.

    We have solved the problem of limited human information-processing capacity by restricting access to the market.

    What if that limitation disappeared?

    Imagine an open digital marketplace where customers publish assignments and consultants make their capabilities and availability discoverable.

    AI agents help consultants identify relevant opportunities and prepare applications.

    The customer’s AI evaluates all applications, identifies the strongest matches, and explains its reasoning.

    It can even prepare individual interviews designed to verify each candidate’s claimed experience rather than simply repeat what is written in the CV.

    The customer makes the final selection.

    AI agents then help both parties compare contractual terms and prepare the agreement.

    No traditional consulting broker required.

    Not because we have automated the broker’s existing process, but because we have removed much of the friction that made the broker necessary.

    And the money previously consumed by intermediation becomes available to reduce costs, improve compensation, or attract more experienced consultants.

    Reducing market friction can improve the value delivered, not merely reduce transaction costs.

    But Who Owns the Marketplace?

    There is an obvious danger.

    What if we replace numerous consulting brokers with one dominant AI marketplace?

    We might eliminate some friction while creating a new gatekeeper.

    That is why I believe three principles are essential:

    Openness. Interoperability. Transparency.

    Customers and consultants should be able to use different systems and AI agents without losing access to the market.

    They should understand how candidates are evaluated, what commercial terms apply, and what they are paying for.

    The marketplace still needs infrastructure, security, identity verification, and governance. But these services need not depend on collecting a percentage of every hour a consultant works.

    AI does not automatically guarantee an open and transparent market. These are choices we need to make when designing the systems.

    From Managing Friction to Eliminating It

    There is a broader pattern here.

    When a system contains friction, we often introduce a function to manage it.

    The function becomes specialized. It develops processes, tools, expertise, and eventually a business model.

    Over time, we become so accustomed to the function that we stop questioning why it is needed.

    We optimize the handling of friction rather than asking whether the friction itself could be removed.

    AI creates an opportunity to reconsider this.

    Not simply by automating existing activities, but by making entirely different ways of organizing work and markets possible.

    Some intermediaries will continue to create genuine value through expertise, assurance, coordination, or risk management.

    But those whose primary advantage is that buyers and sellers cannot efficiently find, evaluate, or transact with each other may face a more fundamental challenge.

    Their traditional function may no longer be necessary.

    A Final Thought

    We often discuss AI in terms of productivity.

    How can AI help someone perform an existing activity faster, cheaper, or better?

    But perhaps we should also ask a different question:

    What activities would no longer be necessary if AI removed the problems that made them necessary in the first place?

    In the consulting market, reducing friction could give customers access to better consultants for the same money.

    And the principle extends far beyond consulting.

    The real opportunity is not just to make intermediaries more efficient. It is to make markets more efficient by removing unnecessary intermediation.

  • Retrospective #5: When the Body of Knowledge Started Learning

    After the previous retrospective, the pace of new Practice Notes slowed down considerably.

    At first glance, that might look as if the inquiry itself had slowed down. In reality, almost the opposite happened. I was simply spending less time adding new notes and more time working with what had already accumulated.

    The Practice Notes started feeding temporary synthesis notes, more structured theory, standard assessment and development approaches, LinkedIn posts, and articles for my employer’s blog.

    Retrospective #4 had already suggested that the notes might become the primary body of evidence, while papers, models and guidance became derived representations. What I had not yet understood was that the relationship would not be one-way. 

    Those derived representations started giving something back.

    Trying to synthesize several notes exposed gaps and tensions between them. Turning theory into a standard approach forced abstract ideas to become usable. A LinkedIn post forced an argument to survive without all the context around it. And once those compressed ideas entered public conversations, people from other disciplines began challenging them, extending them, or asking questions I had not considered.

    Some of those questions eventually returned as new Practice Notes.

    The flow had changed. Experience still generated notes, but the notes now also generated synthesis, applications and conversations, and those in turn generated new experience and new questions. The Body of Knowledge was no longer merely accumulating. It had begun to behave like a learning system.

    I think that also explains why it has become increasingly difficult to say what the Body of Knowledge is actually about.

    The blog began in a reasonably recognizable territory. My original questions concerned software quality, assessment, evidence, organizational capabilities and the models we use to understand them. Even then, I described the scope as broader than testing alone, extending toward systems thinking and the conceptual models used to understand complex organizations. 

    But every cycle of inquiry seems to expose another relationship beyond the previous boundary.

    Quality led into risk and evidence. Requirements led into intent. Product development led into operations and continuity. Documentation led into the preservation of understanding. Organizational capabilities led into stewardship. AI raised the possibility that future understanding may not need to be stored primarily in predefined documents at all.

    Even an Exploration of Vivaldi’s Winter Largo followed a strangely familiar path. The interesting question was not merely which notes the bass voice played, but what function those notes performed within the music.

    That recurring habit has become more visible to me lately. When I encounter a mechanism, practice or artifact, I tend to move upstream from it.

    Why does this requirement exist? Why is this criterion in the Definition of Done? Why do we create this document? Why does this capability need to exist?

    The question is not simply a search for root cause. It is an attempt to recover the relationship between mechanism, function, intent and outcome.

    This also helps explain why several recent threads seem to converge around the idea of stewardship. A document, requirement, model or report may be useful, but it is still only a representation. Different artifacts may contain different claims about the same product, while different specialists each hold part of the relevant understanding.

    The challenge then shifts. Instead of trying to preserve one perfect artifact, perhaps we need to preserve enough coherence around the subject itself that people can continue to understand, develop and assess it as circumstances change.

    That idea led to one formulation I keep returning to:

    Contribution follows expertise; stewardship preserves coherence.

    Quality has not disappeared from the work as the scope widened. If anything, the latest notes show how strongly it still anchors the inquiry.

    The recent note on Ready and Done began with a very ordinary Sprint-end problem: tests being negotiated away because work needs to become Done. But asking why those controls existed changed the meaning of the situation. Skipping a test was no longer merely a delivery shortcut. It could be understood as accepting additional risk without the evidence that the test was supposed to provide.

    Following that line of thought into refinement produced another observation: refinement is not only about reducing uncertainty about what to build. It is also about reducing uncertainty about what could go wrong.

    That is still recognizably quality thinking, but it no longer feels bounded by QA. It reaches into product management, risk, decision-making, operations and learning.

    Perhaps that is why Quality Management feels closer to the territory I am moving through, while still not quite describing all of it.

    Looking back across the Body of Knowledge, I increasingly see one part concerned with how we intervene in systems and another concerned with how we understand them. But even that distinction is becoming difficult to maintain. We need understanding in order to intervene responsibly. The intervention produces consequences. Those consequences give us new evidence. The evidence changes our understanding, which should then influence the next intervention.

    The two strands keep folding back into each other.

    And perhaps this is why the subject itself seems harder to define now than it did twenty or forty notes ago.

    Not despite the Body of Knowledge becoming a learning system, but because of it.

    Every cycle seems to reveal relationships that were not visible before. That does not necessarily mean that the subject itself is objectively expanding. It means that my understanding of its boundary keeps changing as the inquiry develops.

    That distinction matters. Retrospective #4 already contained an important warning: as the theory became more ambitious, it became increasingly important to distinguish observation from interpretation and speculation, and not to make an experience prove more than it actually did. 

    So I am not ready to give the Body of Knowledge a new grand title.

    Quality Assurance is clearly too narrow. Quality Management gets closer. Systems thinking, organizational capability, assessment, knowledge management, product management and organizational learning all seem to touch parts of it.

    For now, one question seems to describe the territory better than any label:

    How do we understand changing systems well enough to intervene responsibly, learn from the consequences, and preserve that understanding over time?

    I do not know whether that is what the Body of Knowledge is ultimately about.

    But I think it is now a fair question to ask.

    When I started the blog, I wrote that writing was not merely a way to communicate conclusions. It was a way to discover what I think. 

    That still feels right.

    The difference is that the mechanism has become larger than writing. The Practice Notes feed synthesis, theory, approaches and public discussion. Those representations encounter other contexts and other people. What comes back changes the Body of Knowledge again.

    The previous retrospective ended with the observation that the theory had started talking back.

    Now it seems to be asking a more difficult question:

    What is it actually a theory of?

    And perhaps, for now, it is better that I do not know.

  • Blog Retrospective #5

    After the previous retrospective, the pace of new Practice Notes slowed down considerably.

    At first glance, that might look as if the inquiry itself had slowed down. In reality, almost the opposite happened. I was simply spending less time adding new notes and more time working with what had already accumulated.

    The Practice Notes started feeding temporary synthesis notes, more structured theory, standard assessment and development approaches, LinkedIn posts, and articles for my employer’s blog.

    Retrospective #4 had already suggested that the notes might become the primary body of evidence, while papers, models and guidance became derived representations. What I had not yet understood was that the relationship would not be one-way. 

    Those derived representations started giving something back.

    Trying to synthesize several notes exposed gaps and tensions between them. Turning theory into a standard approach forced abstract ideas to become usable. A LinkedIn post forced an argument to survive without all the context around it. And once those compressed ideas entered public conversations, people from other disciplines began challenging them, extending them, or asking questions I had not considered.

    Some of those questions eventually returned as new Practice Notes.

    The flow had changed. Experience still generated notes, but the notes now also generated synthesis, applications and conversations, and those in turn generated new experience and new questions. The Body of Knowledge was no longer merely accumulating. It had begun to behave like a learning system.

    I think that also explains why it has become increasingly difficult to say what the Body of Knowledge is actually about.

    The blog began in a reasonably recognizable territory. My original questions concerned software quality, assessment, evidence, organizational capabilities and the models we use to understand them. Even then, I described the scope as broader than testing alone, extending toward systems thinking and the conceptual models used to understand complex organizations. 

    But every cycle of inquiry seems to expose another relationship beyond the previous boundary.

    Quality led into risk and evidence. Requirements led into intent. Product development led into operations and continuity. Documentation led into the preservation of understanding. Organizational capabilities led into stewardship. AI raised the possibility that future understanding may not need to be stored primarily in predefined documents at all.

    Even an Exploration of Vivaldi’s Winter Largo followed a strangely familiar path. The interesting question was not merely which notes the bass voice played, but what function those notes performed within the music.

    That recurring habit has become more visible to me lately. When I encounter a mechanism, practice or artifact, I tend to move upstream from it.

    Why does this requirement exist? Why is this criterion in the Definition of Done? Why do we create this document? Why does this capability need to exist?

    The question is not simply a search for root cause. It is an attempt to recover the relationship between mechanism, function, intent and outcome.

    This also helps explain why several recent threads seem to converge around the idea of stewardship. A document, requirement, model or report may be useful, but it is still only a representation. Different artifacts may contain different claims about the same product, while different specialists each hold part of the relevant understanding.

    The challenge then shifts. Instead of trying to preserve one perfect artifact, perhaps we need to preserve enough coherence around the subject itself that people can continue to understand, develop and assess it as circumstances change.

    That idea led to one formulation I keep returning to:

    Contribution follows expertise; stewardship preserves coherence.

    Quality has not disappeared from the work as the scope widened. If anything, the latest notes show how strongly it still anchors the inquiry.

    The recent note on Ready and Done began with a very ordinary Sprint-end problem: tests being negotiated away because work needs to become Done. But asking why those controls existed changed the meaning of the situation. Skipping a test was no longer merely a delivery shortcut. It could be understood as accepting additional risk without the evidence that the test was supposed to provide.

    Following that line of thought into refinement produced another observation: refinement is not only about reducing uncertainty about what to build. It is also about reducing uncertainty about what could go wrong.

    That is still recognizably quality thinking, but it no longer feels bounded by QA. It reaches into product management, risk, decision-making, operations and learning.

    Perhaps that is why Quality Management feels closer to the territory I am moving through, while still not quite describing all of it.

    Looking back across the Body of Knowledge, I increasingly see one part concerned with how we intervene in systems and another concerned with how we understand them. But even that distinction is becoming difficult to maintain. We need understanding in order to intervene responsibly. The intervention produces consequences. Those consequences give us new evidence. The evidence changes our understanding, which should then influence the next intervention.

    The two strands keep folding back into each other.

    And perhaps this is why the subject itself seems harder to define now than it did twenty or forty notes ago.

    Not despite the Body of Knowledge becoming a learning system, but because of it.

    Every cycle seems to reveal relationships that were not visible before. That does not necessarily mean that the subject itself is objectively expanding. It means that my understanding of its boundary keeps changing as the inquiry develops.

    That distinction matters. Retrospective #4 already contained an important warning: as the theory became more ambitious, it became increasingly important to distinguish observation from interpretation and speculation, and not to make an experience prove more than it actually did. 

    So I am not ready to give the Body of Knowledge a new grand title.

    Quality Assurance is clearly too narrow. Quality Management gets closer. Systems thinking, organizational capability, assessment, knowledge management, product management and organizational learning all seem to touch parts of it.

    For now, one question seems to describe the territory better than any label:

    How do we understand changing systems well enough to intervene responsibly, learn from the consequences, and preserve that understanding over time?

    I do not know whether that is what the Body of Knowledge is ultimately about.

    But I think it is now a fair question to ask.

    When I started the blog, I wrote that writing was not merely a way to communicate conclusions. It was a way to discover what I think. 

    That still feels right.

    The difference is that the mechanism has become larger than writing. The Practice Notes feed synthesis, theory, approaches and public discussion. Those representations encounter other contexts and other people. What comes back changes the Body of Knowledge again.

    The previous retrospective ended with the observation that the theory had started talking back.

    Now it seems to be asking a more difficult question:

    What is it actually a theory of?

    And perhaps, for now, it is better that I do not know.