Why Access to Industry Knowledge Matters — and How Disciplined Agile Helps
ABSTRACT
We live in a world with more information than any generation before us, yet we increasingly see less, choose less, and understand less. As browsing and searching are gradually replaced by preselected content, our ability to orient ourselves, learn, and adapt begins to erode.
This is not only a social media problem. The same access pattern has shaped software process methods for years: practices are delivered as ready-made prescriptions, while exposure to alternatives, trade-offs, and industry-wide options is limited. As a result, adaptation often becomes reactive or superficial—even when teams act in good faith.
This article argues that the core issue is not the content of software methods, but how industry knowledge is accessed in practice. From this perspective, Disciplined Agile is not simply a flexible framework, but a mechanism that restores structured browsing before decision-making—enabling informed adaptation rather than ad-hoc adjustment.
WHAT THIS ARTICLE IS NOT
This article is not a classic argument for adopting Disciplined Agile as a framework.
It is an argument about how access to industry knowledge shapes adaptation—and about the consequences of getting that access wrong. When industry knowledge is delivered as prescriptions rather than navigable options, adaptation becomes reactive, narrow, or illusory, even when teams act in good faith.
CONTEXT: METHODS, FRAMEWORKS, AND THE CORE CONFUSION
Software methods typically offer:
- Principles, values, practices, frameworks, and sometimes entire ecosystems
The problem is not a lack of content in these methods, but defective access to the broader body of industry knowledge—of which any single method (and methods in general) covers only a part.
What is usually needed in practice is the adaptation of knowledge and tools provided by the industry at large—and by methods in particular—to a specific context: project, product, team, organization, customers, and constraints.
Most discussions about “adaptation” skip a more fundamental question:
How does someone know what to adapt—and why?
A TYPOLOGY: PUSH, BROWSE, AND SEARCH IN SOFTWARE METHODS
We have previously discussed generic modes of access to information and their roles in everyday life.
Browse
Sometimes we navigate through a palette of options—newspapers, websites, news
lists—and choose what interests us. Browsing means navigation, exposure to
diversity, and the construction of a general mental map of the world: we learn
what exists, where things are, and how they relate to one another.
Search
Search is intentional inquiry, depth, and specialization. It works well only
when a general map already exists through browsing, and it is often triggered
by browsing itself: we encounter a new topic and become curious.
Push
Increasingly, information is delivered to us directly—preselected, sometimes as
a single item—without the possibility to choose or compare.
See more info in my previous post “Abundant Information, Broken Access” [Note 1].
In software, these three modes map as follows:
- Push: a prescribed set of practices or rules delivered through methods and frameworks
- Browse: a map of options, alternatives, and trade-offs
- Search: intentional, contextual choice driven by a real need
The key idea is this: real adaptation requires browse before search.
You must start as a generalist to become a specialist in any coherent way—to know what exists, what to look for, and how to compare options. Without browse—without access to industry-wide experience beyond local habits and a few methods—adaptation turns into improvisation, or vanishes altogether.
By industry knowledge I mean not a single method or framework, but the accumulated experience of multiple approaches, patterns, and trade-offs developed across the industry over time.
Let us now look at what some well-known methods actually offer.
XP AND SCRUM: INTENTIONAL PUSH, PERCEIVED AS SUFFICIENT
XP
From an adaptation perspective, XP is a compact and coherent push: it provides a tightly integrated set of practices designed to work together as a system.
- Kent Beck discusses adaptation mainly in terms of scaling XP practices when teams or contexts grow beyond the original assumptions [Note 2].
- Don Wells formulates a more general corrective principle — “Fix XP when it breaks” — but without offering a map of alternatives or guidance on where and how to search outside the XP practice set [Note 3].
Scrum
Scrum explicitly states that it is a framework [Note 4]. However:
- it does not provide browse,
- it does not point to a broader ecosystem of options (except for occasional references to XP),
- it is too often used as a complete solution, even though it was not designed as such.
Conclusion
XP and Scrum are intentionally incomplete, push-based approaches, yet they
are commonly perceived and used as if they were sufficient.
In addition, they are relatively generic and contain what can be called Core Agile Practices [Note 5]. This makes them applicable in many situations—but not in all situations. Therefore, they too must follow the logic of contextual adaptation.
RUP: REAL BROWSE, PERCEIVED AS PUSH
RUP (the Rational Unified Process [Note 6]) was conceived as a browse of practices and approaches. However, the tailoring mechanism was not part of the core user experience. Without a clear, central message about how to choose and why, RUP was widely perceived as a large, rigid push—and was either rejected outright or applied mechanically.
THE CENTRAL PROBLEM: WHY PUSH IS CONFUSED WITH “THE WHOLE”
Why are push-based methods so often mistaken for “complete recipes”?
- The desire for a finite recipe
- The need for professional stability
- Low cognitive cost
- The illusion that “the process problem has been solved”
- Organizational pressure
- The absence of a shared map of industry options
Push becomes “sufficient” when people want to close the process problem—not understand it.
WHY ADAPTATION WITHOUT BROWSE IS AN ILLUSION
Real adaptation requires:
- knowing what exists,
- understanding trade-offs,
- recognizing recurring industry patterns.
Without browsing:
- search becomes chaotic—there are no reliable reference points,
- reinventing the wheel becomes inevitable,
- personal experience fails to connect into a coherent mental map,
- significant energy is wasted rediscovering known solutions—or settling on outcomes that are worse than what proper browse would have enabled.
NO BROWSE: CONSEQUENCES IN PRACTICE
Assumption: the team is genuinely trying to adapt and improve, but bases its decisions mainly on internal experience and on a narrow external reference (for example, a single method such as Scrum or XP).
The cost of poor access to industry knowledge is not methodological impurity—it is time: wasted learning, late discoveries, and decisions made without seeing real alternatives.
In practice, this leads to:
- process decisions discovered too late, after resources are already consumed and the delivered solution does fit real customer needs;
- learning opportunities lost as teams repeat local experiments instead of building on existing industry knowledge;
- proven practices that could narrow the gap with competitors—or create a genuine advantage—remaining invisible;
- improvement stalling not because teams resist change, but because they cannot see what other viable options exist.
DA TOOLKIT: EXPLICIT, STRUCTURED BROWSE
Disciplined Agile starts from an explicitly different assumption: people cannot adapt well without a map of what already exists in the industry.
The DA Toolkit offers:
- process areas,
- real options,
- alternative practices,
- indications of trade-offs.
It does not say “do this.” It exposes the available options and trade-offs, so you can orient yourself first and decide deliberately.
In other words, it enables effective and efficient browse and search, not prescriptive push.
WHY DA FEELS DIFFICULT FOR SOME
Because it:
- does not offer a final recipe (which does not exist anyway),
- does not promise artificial logical stability,
- requires responsibility and choice.
This is not a matter of bad intentions, but of a distorted expectation about how access to information should work.
Using the DA Toolkit does not add
effort—it replaces unstructured effort with orientation.
What would otherwise take years of scattered learning and trial-and-error is
made visible and navigable upfront.
WHAT CAN I DO FOR EFFECTIVE ACCESS TO INFORMATION?
From a practical perspective, DA helps in two distinct situations.
If I already use Scrum, XP, or another method, DA helps me see what those methods do not cover and what viable alternatives exist when their default options no longer fit my context. Instead of forcing adaptations blindly, I can make informed choices based on known industry options.
If I do not yet use a method, DA helps me choose one deliberately—and then adapt it consciously. I may claim that I can work without a method, but having a method as a reference still matters when my context aligns with the mini-ecosystem it proposes: sets of practices that work well together and reinforce each other.
In both cases, DA does not replace methods—it restores orientation before choice.
CONCLUSION
Methods do not fail—or plateau—because they are wrong.
They fail when push is mistaken for sufficiency, browse disappears, and search never really starts.
Disciplined Agile helps because it restores correct access to industry knowledge:
- orientation comes before decision,
- adaptation is informed, not improvised,
- people are treated as generalizing specialists, not rule followers.
END NOTES
[1] V. Mocanu, “Abundant Information, Broken Access”,
https://agileand.blogspot.com/2026/01/abundant-information-broken-access.html
[2] Beck, K.,
Extreme Programming Explained: Embrace Change (2nd Edition),
Addison-Wesley, 2004.
[3] Donovan Wells, “Fix XP When It Breaks”,
http://www.extremeprogramming.org/rules/fixit.html
[4] Schwaber, K., Sutherland, J.,
The Scrum Guide, scrumguides.org
[6] V. Mocanu,
“Core Agile Practices” — I also proposed this term for the Disciplined Agile (DA) Toolkit and for Disciplined Agile content to replace and extend the former term “Critical Practices.”
https://agileand.blogspot.com/2017/03/core-agile-practices.html
[5] Kruchten, P.,
The Rational Unified Process: An Introduction, Addison-Wesley.
