Adaptation Without Browse Is an Illusion

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.

Abundant Information, Broken Access

 

Why fixing how we access information matters — and how it can be done.

 

ABSTRACT

We have more information than any generation before us, yet we see less, choose less, and understand less.

This is not a problem of content, but of access. As browsing and searching are gradually replaced by preselected feeds, our ability to orient ourselves, learn, and adapt begins to erode. This article looks at how this shift happens, why it matters, and how access to information could be corrected without rejecting technology or platforms altogether.

 

ABUNDANT INFORMATION, BROKEN ACCESS

We have access to more information than ever before, yet we use it less and less effectively.
The way we access information helps or hinders our ability to use specifically human capacities. To understand what is at stake, I start from the role information has played in human development.

WHAT THIS ARTICLE IS NOT

This is not an anti-technology manifesto, nor does it propose simple solutions or recipes. Its goal is to offer a framework for understanding, allowing each reader to better judge which forms of access to information are helpful and which are limiting.

THE KEY ABILITY OF HOMO SAPIENS

Homo sapiens did not prevail as a species through strength or biological specialization, but through a unique ability: access to a large pool of cumulative, shared knowledge and the capacity to specialize locally only when the context requires it.

Anthropology describes this strategy as that of a generalist–specialist: broad orientation toward the world, combined with rapid, contextual adaptation. This ability explains why Homo sapiens was able to occupy extremely diverse environments and, ultimately, the entire planet. [Note 1]

WHY CIVILIZATION APPEARS LATE

This capacity existed long before the emergence of civilization. For hundreds of thousands of years, Homo sapiens remained at a relatively stable level of organization.
Cultural acceleration appears only when communities become large enough and connected enough for ideas, practices, and symbols to circulate between groups and combine, starting with examples such as Göbekli Tepe. [Note 2]

 THE CIRCULATION OF IDEAS AS THE ENGINE OF EVOLUTION

Civilization does not begin with an individual leap in intelligence, but with the connection of multiple communities into a functional network of knowledge.
When ideas can circulate, be combined, and transmitted further, progress accelerates. Without such a network, even a capable species remains stalled.

 FROM COMMUNITIES TO ACCESS TO INFORMATION

The mechanism that made human progress possible is being tested today.
When access to information is replaced by the delivery of preselected content, navigation disappears and adaptation is impaired. The discussion about access to information is, at its core, a discussion about whether this mechanism is enabled or blocked.

 MODES OF ACCESS TO INFORMATION: BROWSE, SEARCH, AND PUSH

In everyday life, we interact with information in different ways.

Browse. Sometimes we navigate through a palette of options—newspapers, websites, news lists—and choose what interests us. Browse means navigation, exposure to diversity, and the construction of a general mental map of the world. It is the mechanism through which we become generalists in the first place: we learn what exists, where things are, and how they relate to one another.

Search. At other times we are curious or have a clear need to find something specific, and we use a search engine or documentation. Search is intentional inquiry, depth, and specialization. It works well only when a general map already exists through browsing and is often triggered by browsing itself: we encounter a new topic and become curious. [Note 3]

Push. Increasingly, however, information is delivered to us directly, preselected, sometimes as a single item, without the possibility to choose or compare. This is the push mode.

 BROWSE AND SEARCH: LEARNING AND SPECIALIZATION

During learning—childhood, school, and beyond—we discover the world primarily through browsing. Education provides a foundation of knowledge and helps us become generalists before any specialization occurs. Only later does the need for search emerge, as we deepen a domain and specialize.

From an early age, however, we are also exposed to push mechanisms, especially through advertising. The difference is that in the past, advertisements had dedicated spaces and were easy to recognize. Today, campaign-backed content is often delivered as “news” or “raw information,” without clear separation.

 A PROBLEMATIC TREND

There is a clear trend in which browsing (generalization) and searching (specialization) are diminished or distorted, while push becomes omnipresent.
Convenience makes this form of access appealing, but the difference is not merely one of comfort—it directly affects our ability—it directly affects our ability to function as generalist–specialists.

When browsing and searching disappear, we end up living either inside a permanent advertisement or inside an increasingly narrow personal bubble.

 CLASSIC BROWSE IN PRESS AND TELEVISION

Print media and television once offered a broad and clear form of browsing. People were exposed to diverse topics and news, even if these were not part of their direct interests. You might have cared only about football, yet you would still learn that athletics or hockey existed. You were also exposed to international news, not just to what happened in your own country.

This form of browsing:

• expanded the general mental map,
• created shared reference points at community level,
• naturally broke individual bubbles.

 DISTORTED BROWSE IN TELEVISION AND NEWS WEBSITES

There is also a degraded form of browsing in some television channels and news websites, where selection is no longer made for general orientation but to support an agenda.
Topics are deliberately chosen or omitted, sometimes exaggerated or built from minor facts, and analysis is pre-directed toward predetermined conclusions.

Formally, a palette of options still seems to exist. In reality, browsing is steered, and access to genuine alternatives and competing interpretations is limited.

 DIMINISHED BROWSE: SOCIAL MEDIA

On social media, browsing still exists—but in a diminished form. We see lists of topics and can choose what to read, yet these lists are no longer built on relevance for a broad community. Instead, they are personalized based on our previous choices.

Instead of seeing what is important or relevant to many, we see what is deemed suitable for us.

As a result:

• we remain captive within our own choice-based bubbles [Note 4],
• access to community-level options is reduced,
• inspiration for search declines, because we see less from outside our bubble.

Another form of diminution is artificial popularity. Some items are promoted through paid mechanisms and appear as “popular,” even though that popularity is manufactured. In essence, this is advertising disguised as neutral news or information.

 ABSOLUTE PUSH

The least useful and most easily manipulated form is absolute push: situations in which a single item (for example, a video) is presented directly, without any real possibility of choice or comparison.

In this case:

• the option to choose approaches zero,
• the usefulness of information for the individual decreases,
• vulnerability to manipulation reaches its maximum.

Here, neither browsing nor searching truly exists. Something—or someone—has already done them on your behalf. Technically, search may still exist, but the motivation to use it almost entirely disappears.

 CONSEQUENCES: ARE WE LIVING INSIDE AN AD?

The disappearance and distortion of browse and search, together with the growing dominance of push, have real and cumulative consequences.

First, individuals can no longer fully use their cognitive capacities. Information that would be practically useful—for health, parenting, professional adaptation, or informed political decisions—is no longer visible. Access is no longer guided by real needs, but by what others decide to deliver.

Without genuine browsing and active searching, such information is not discovered—even if it exists.

Ultimately, our understanding of the world deteriorates: captive within an advertising-like feed decided by others, individuals no longer build a coherent mental map of reality.

 THE SLEEP OF REASON, TECHNOLOGIZED

When browsing and searching disappear and push becomes dominant, it is not only individual orientation that vanishes. Mechanisms of informational manipulation—especially political and ideological—begin to thrive.

We often complain about advertisements for products and services, but these are relatively well regulated and easy to recognize. Political and ideological manipulation, by contrast, is far less regulated and can take many forms.

In this context, information can be delivered as “news,” “analysis,” or “opinion” without being marked as promotion. Artificial public agendas can be constructed, critical moments in elections influenced, and political or ideological support obtained through financial investment—without transparency or accountability. This is no longer information, but perception engineering.

 WHAT CAN BE DONE

The problem is not the existence of browse, search, or push, but how they are used. A healthy information system uses all three—but in different roles.

• Browse must exist as a human orientation mechanism. It builds the general map and makes diversity visible. Without browse, curiosity does not arise and search is not triggered.
• Search must remain an intentional act. It enables specialization and depth, but functions properly only when orientation has already been established through browsing.
• Push can exist—but not without alternatives. It may be useful for entertainment, but becomes harmful when it eliminates choice and replaces browsing and searching.

 HOW THIS CAN BE DONE

Solutions do not require banning any mode of access but offering real and visible alternatives.

• Core principle: push is acceptable only if a visible browsing alternative exists.
  A platform may prioritize a single-item feed (for example, video), but it must clearly and accessibly offer a list-based alternative where users can see multiple options and choose what to consume.
• Access to a generic, non-personalized feed. A feed built on common criteria (public relevance, timeliness) pulls users out of bubbles and restores the orientation role of classic browsing. Personalization without an exit option becomes captivity.
• Browse by categories, not only personalized feeds. The ability to choose category-based feeds (Sports, World News, Economy) offers more focused browsing while preserving user control and option visibility.
• Visible and non-penalized search. Explicit search must remain easy to access and lead to relevant results. It should not be hidden in the interface, diverted into recommendations, or replaced by prepackaged answers that close exploration.

 A PRACTICAL “REVOLUTION”

No radical solutions are needed. It is enough for information systems not to block the basic mechanisms through which people orient themselves and specialize.
Choice must remain possible. Without it, access to information ceases to be a tool for adaptation and becomes merely a stream of stimuli.

  CONCLUSION

We are not facing a crisis of information, but a crisis of access.

When browsing and searching are diminished and push becomes dominant, people can no longer build a coherent mental map of the world they live in, nor can they make informed choices about what is useful to them. Choice and orientation are not matters of comfort—they are conditions for understanding, adaptation, and informed decision-making.

 

END NOTES

[1] Homo sapiens as a “generalist–specialist.” Recent research suggests that Homo sapiens occupied a distinct ecological niche compared to other hominin species, based on the combination of broad general orientation with local and temporary specializations, supported by cumulative knowledge and cultural transmission.

Source: Max Planck Institute for Social Anthropology

https://www.shh.mpg.de/1021619/general-specialist-homo-sapiens

[2] Göbekli Tepe is frequently cited as an example of complex pre-agricultural community organization, suggesting the existence of social, symbolic, and cooperative networks before the emergence of agriculture.

Source: National Geographic

https://www.nationalgeographic.com/magazine/article/gobeki-tepe

[3] Information Foraging Theory describes how people explore information and decide when to deepen their inquiry, in a manner analogous to resource foraging in nature (Pirolli & Card). The theory highlights the role of exploration (browse, as defined in this article) in triggering intentional search (search, as defined in this article), directly corresponding to the access modes discussed here.
https://en.wikipedia.org/wiki/Information_foraging

This model (from the current article) was developed independently, based on empirical observation of feed-based information systems and their societal effects.
Only after the model was articulated did I become aware of Information Foraging Theory, which partially overlaps in describing user behavior in browse and search contexts, but does not address push-based systems or their political and social implications.

[4] Filter Bubble / Selective Exposure. The filter bubble concept describes the effects of excessive personalization on information exposure, reducing access to alternative perspectives and fostering informational isolation (Eli Pariser). This phenomenon is closely linked to the algorithmic personalization mechanisms described here as “diminished browse.”

What is wrong with Agile?

 Alongside numerous works that popularize the agile way of working, occasionally we come across articles or presentations created by experienced professionals who express exasperation with Agile.

Why is this happening?

Recently, a friend sent me the link to this article, suggestively titled “The Age of Agile must end” [See B1-Age of Agile]. I could easily see myself spending an hour discussing the points I might disagree with in this article, and perhaps even another two hours exploring areas of potential agreement. It strikes me as an excellent example of these perspectives, where software professionals or other professionals express their dissatisfaction with Agile. In short, I can say that I resonated with certain problems described. Here are some aspects of how Agile is used that, from my perspective, could profoundly affect our work:

Agile Simplified as Scrum: A good part of the "Agile world" is centered around Scrum, or similar prescriptive methods, serving as the sole reference point.

Challenges with New Products: Developing a new product often demands a distinct life cycle compared to established products. The Scrum-Agile cycle is more suited to the latter. Therefore, a variety of development life cycles should be available for selection.

Adapting Lean Techniques: When integrating Lean into an Agile-lean approach, customization according to the situation and the current stage in the product's life cycle becomes crucial.

Unaddressed Technical Debt: The issue of quality, technical debt, and a deficiency in technical excellence remains a significant concern within the practical Agile landscape.

Technical Debt in New Products: Indeed, technical debt can swiftly accumulate and impede even the development of a freshly conceived product.

Compromising for Expediency: The tendency to cut corners often gives rise to the accumulation of technical debt.

Limited Focus on Short-Term Goals: Concentrating solely on short-term objectives and hoping for medium and long-term goals to somehow resolve themselves is a common practice.

To me, these are symptoms of "Incomplete Agile". Let's talk about them.

 

 

Agile simplified as Scrum

 

Reducing Agile to Scrum (and other prescriptive methods), along with the Agile manifesto, doesn't provide a robust foundation for developing Agile processes that can adapt to various situations. A significant portion of the "Agile world" relies heavily on these limited references. Many people criticize Agile for not aligning well with their specific contexts and the outcomes they want to achieve. In reality, this often points to this "Incomplete Agile" approach.

Definitely, Agile, as well as your process, has more than 10 practices.

 

New Products Problems

The essential tools required in this scenario cannot be found within the realm of Scrum. While the Scrum lifecycle could indeed prove valuable for a mature product, an alternative lifecycle better aligned with this situation exists: the Exploratory Lean Startup, one of the several Agile-Lean lifecycle options detailed in the DA Toolkit (see [B2 – DA Toolkit]). Instead of adhering to regular deliveries, the focus shifts towards conducting numerous small experiments to identify market needs and showcase the proposed solution approach.

A more detail discussion about the type of development life-cycle could be used in the different stage of the product life cycle can be found in one of my previous posts (See [B4 Delivery vs Product ]).

When you begin a new product, you are in an exploratory stage and should adapt your approach. 

 

Adapting Lean Technique  

Some distinct approaches are necessary for various stages of the product development lifecycle. For well-established teams and existing products, pinpointing delays (a significant result of diverse sources of waste) holds paramount importance. Conversely, for emerging products, it becomes even more critical to detect trends in the primary waste sources before substantial delays accumulate. Developing a new product requires drawing from the experience of waste prevention.

Also, we're not precisely employing the Lean manufacturing approach; rather, we're utilizing a distinct approach that is better tailored for knowledge work.

You should eliminate delays from your workflow, and even better, strive to avoid them.

 

Unaddressed Technical Debt

Scrum deliberately does not tackle this challenge explicitly, possibly because its creators known XP approach and aimed only to introduce additional elements. As a result, teams and products that intentionally embrace an exclusively Scrum-based approach, without addressing the "technical excellence" aspect emphasized in the Agile Manifesto, face the potential of encountering significant risks.

A key phrase in the mentioned article [See B1 Agile Age] is “Invest in foundational efforts like design systems and a clean tech stack so future efforts can be more efficient.”

The XP approach for this aspect might remain vague or challenging to duplicate. The team that embodies the XP style had a high level of skill. They didn't create a "mess" and used refactoring to align their evolving system design with new requirements

Contrastingly, a typical Agile team faces more risk in generating "mess" and accumulating technical debt. It's advisable to invest intentional effort into overall design and technology stack options decisions. Establishing a foundational base is necessary, followed by the opportunity to refine it as experience grows and new system requirements emerge. This approach indeed pursues a goal that extends beyond the immediate delivery.

 Software ages akin to milk, not maturing like fine wine.

 

Technical Debt in New Products

 

We have several competing goals concerning the economics of the first delivery and the feasibility of continuing the business post the initial delivery. These include swiftly determining if our product demanded by the market is viable and if our technical solution is feasible, preferably without incurring substantial expenses.

Establishing a robust internal design is essential, enabling modifications to the product without compromising its integrity or significantly increasing costs through the accumulation of technical debt.

Moreover, it's important to recognize that a product consistently has facets necessitating exploration and expertise. Therefore, opting for the appropriate life cycle to accommodate these needs is crucial.

Beware: you can create hard-to-change software from the start.

 

Compromising for Expediency

 

What is our objective? Is it solely the current delivery? Is it both the current delivery and future deliveries? Do we want to ensure the continuity of our business? Technical debt accumulates over time, leading to progressively worsening delays and escalating quality issues. There could be several possible reasons for not effectively addressing these issues: perhaps we don't fully comprehend them, or perhaps we do understand them but take a reckless approach.

Behind many technical disasters lies inadequate or reckless behavior.

Limited Focus on Short-Term Goals

 

We need a deliberate effort and dedicated actions to address also our medium- and long-term objectives. Here are some examples. We need to ensure that the internal design quality remains manageable and aligned with both current functional and non-functional requirements. This practice aids us in delivering high-quality products within designated timeframes and at minimized costs across short, medium, and long-term periods. To achieve this, as well as other equally valuable objectives, we should continuously enhance the knowledge and skills of our personnel. Additionally, it's crucial to monitor sources of waste to avert the repercussions stemming from their accumulation.

Long and medium-term goals encompass more than simply the aggregation of short-term goals.

 

How to address these problems

We needed to effectively address both our short-term and medium- to long-term objectives. This necessitates a deliberate and ongoing commitment to improvement. To achieve this, we should draw upon the collective industry experience, rather than relying solely on specific Agile methods. Our development cycle and practices should be chosen based on our unique circumstances, requiring a thorough understanding of available options. While tools like ChatGPT are trendy, their suggestions should complement our decision-making rather than dictate it. But are these insights structured and validated by industry experience? Success might be a matter of luck. If we seek access to industry-proven expertise concerning these options and guidelines on their contextual application, the Disciplined Agile Toolkit (see [B2 – DA Toolkit]) serves this purpose. If our aim is to overcome the challenges posed by an incomplete or ill-suited Agile approach, it's prudent to customize it ourselves within our specific context, leveraging the wealth of industry experience already available to us.

A good starting point is the online DA Browser knowledge base (See [B3 – DA Browser])

Do not try to solve any problem you have with the same set of 10 practices.Adapt Agile practices to the specific context of the product, the team, and the organization.

Utilizing multiple references for Agile & Lean is recommended, and you can leverage the organized structure of these references available in the DA Toolkit.

 

REFERENCES

[B1 Age Of Agile]  The age of Agile must end, by Michael Burnett, Feb 12 2023

https://uxdesign.cc/the-age-of-agile-must-end-bc89c0f084b7

[B2 – DA Toolkit] Disciplined Agile Toolkit

https://www.pmi.org/disciplined-agile/

[B3 – DA Browser] – Disciplined Agile Browser

https://www.pmi.org/disciplined-agile/da-browser

[B4 Delivery vs Product ] Delivery life-cycles versus product lifecycle

https://agileand.blogspot.com/2020/01/life-cycle-evolution-example.html

 

 

The math behind Agile and Lean... and the future of AI

USING FEEDBACK

 

Here is one of the very specific Agile & Lean approaches: developing and delivering in small batches. Commentary: there are many practices in agile and lean that use feedback, but I'm talking here about the fundamental one, related to the life cycle of deliveries.

Who recommended this, and with what support and arguments?

Agile manifesto: The Agile manifesto is clearly centered around the approach of small releases as evidenced by the principles outlined in the AM (quotes): 

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”, and

 “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” (See [B- AM] ).

XP makes an explicit recommendation for small releases (see [B-XPE1], [B-XPE2]) and builds its practices ecosystem on this hypothesis. Integration and test-first approaches are among the supporting practices.

Scrum, on the other hand, doesn't emphasize the importance of small releases explicitly. While they suggest that work should be potentially releasable after each Sprint, there is no explicit requirement for releases to be small. (See [B-SG])

Disciplined Agile - In contrast, Disciplined Agile has "Accelerate value delivery" as a key mindset and delivery process goal, with a variety of options, practices (including those from XP), and guidance to help achieve it (see [B-DA AVD]). They also embrace the Lean approach of delivering in small batches, supported by numerous arguments.

If we want to distinguish between the role of feedback in human work processes versus technological processes, it may be best to abandon this traditionalist approach, as we have seen how AI, a “technology”, is increasingly capable of replacing humans in various tasks.

The math behind this - There are some situations where feedback control systems cannot be avoided: complex systems with time-varying dynamics, where it is not possible to obtain an analytical model to predict or control the system's behavior. Feedback loops provide the necessary information to obtain a flexible and adaptive approach to respond to changing conditions and achieve desired outcomes in such contexts. In such cases, there is no upfront formula to solve your problem, and you should rely on feedback loops to manage complexity. Remember that Big Up From Requirements, Design and Planning was one of the defining trait of waterfall approach.

Back to software: What are some main traits of software development and other knowledge work-based domains? Uncertainty and complexity. Attempting to solve the complexity and uncertainty related to knowledge work without using a lot of feedback loops (through the agile and lean approach) seems to be mathematically infeasible.

 

USING CONTEXT KNOWLEDGE

 

Math: However, feedback-based approaches also have some limitations. These approaches rely on a model of the system's dynamics and behavior, and if this model is inaccurate, it can severely limit system performance.

For example, feedback may be given through testing, either manual or automatic. If we cannot accurately model the test cases, or if we don't understand that certain tests are related to specific dynamic race conditions or competition levels, we may not achieve the desired results. Similarly, if we try to copy feedback-based practices that work well for another team or product, they may not be suitable for our context and the specific problems we are trying to solve.

To overcome these limitations, it is essential to understand and adapt to our context, continuously updating our model of it, beyond relying on feedback alone.

How powerful was medicine when it also collected the symptoms, but did not understand the internal processes of the body? In the meantime, the means of observation and measurement improved, as well as the understanding of these internal processes.

Who recommended this, and with what support and arguments?

Agile Manifesto: The authors of the Agile manifesto acknowledged that they were only able to agree on values and principles, not specific practices, as each of them situation and work context is different.

XP recommends adapting the framework if it's not working, but there is no specific guidance on how to tailor it. (See [B-XPE2])

Scrum provides little guidance beyond its lightweight framework, as the intention is for teams and organizations to define the rest of the process in their specific context. (See [B-SG])

Disciplined Agile was developed to provide guidance and options for practices and life cycles (See [DA-LC]) in context, and the DA Toolkit is a free online knowledge base for this purpose (See [B-DATK]). Disciplined Agile also use System Thinking (system is a product of the interaction of its parts, not just the sum of its parts.) to be able to have a more correct model of the problems to be solved.

We must tailor the process according to our specific context and not copy the solution from another context

In conclusion, attempting to solve the complexity and uncertainty of knowledge work without considering context (e.g. for modeling our process and selecting practices) is inherently flawed.

 

USING EXPLORATION

 

There are various factors that can impede finding good solutions to complex problems. One such factor arises when developing a new product, where the requirements and solution spaces may not be well defined. In such cases, it may be necessary to undertake extensive exploration to determine the functionalities that potential customers require, as well as to identify the feasible and optimal technical solutions among numerous options.

To my knowledge, James Coplien argues that agile as "responsive iterative design" does not work well (See [B-JC] ), and I think he is referring to situations where just doing iterative, incremental work will not yield the best option from several possibilities.

While some argue that agile methods do not work well in such situations, we contend that feedback and small batches are still useful for solving complex problems and understanding the context model. However, relying solely on feedback and small batches, can lead to local optimization and to overlooking better solutions. By selecting a technical solution and gradually improving it, we may miss out on superior options.

Math Support - To address such issues, a possible mathematical approach is to use genetic algorithms,  which explore a broader range of solutions and options (and not just optimize, develop and improve the initial one (See [B-GA]). There are also many other mathematical options to avoid a "local" maximum (See [B-LO])

In terms of process approaches, one example is the product life cycle model proposed by Kent Beck - Explore. Expand, Extract - which emphasizes exploration in the initial part of this life-cycle. (See [B-Beck])

Disciplined Agile also provides a dedicated development and delivery life cycle variant for situations where multiple options need to be explored, called "Exploratory Lean Startup" (See [B-EXLC]). Essentially, this approach involves exploring multiple options while using the fail-fast idea, as there is often limited time and resources available to explore options in detail. Additionally, DA recommends leveraging existing sources of knowledge or experts, such as the DA toolkit for practice options, to move faster or avoid unnecessary fail-fast sequences.

 

Some Conclusions

Although Agile and Lean processes are not inherently based on math, there is a mathematical foundation underlying them. Unfortunately, this foundation is not widely known, and the various aspects of Agile and Lean are often discussed separately, without recognition of their interconnectedness. Disciplined Agile provides comprehensive support for the various dimensions of this mathematical logic, offering an integrated and robust approach to agile and lean methodologies. XP and agile principles provide support only for the part related to feedback use.

Trivia ... future AIs

These mathematical dimensions of solving complex problems should also be part of the capabilities of future AIs. An AI can learn, it can use feedback, it can learn "offline". But how well can it build a model of the context, how well can it explore more options (and not in just a narrow field)? For now, exaggerating, they seem to be just talking encyclopedias with computing power.

  

References

 [B- AM] Principles behind Agile Manifesto - https://agilemanifesto.org/principles.html

 [B-XPE1] – Extreme Programming Explained First Edition, By Kent Beck, Addison-Wesley, 1999

• About „small releases” or „Short Releases”, see Chapter 10 - A quick Overview, Chapter 11 - How could this work, Chapter 26 Xp At work

[B-XPE2] – Extreme Programming Explained: Embrace Change, Second Edition, By Kent Beck, Cynthia Andres, Addison-Wesley,  2004

• Chapter 15, Scaling XP
  

[B-SG] Scrum Guide - https://scrumguides.org/scrum-guide.html

[B-DA AVD]- Disciplined Agile, Accelerate Value Delivery Process Goal 

https://www.pmi.org/disciplined-agile/construction-goals/move-closer-to-deployable-release 

[DA-LC] - https://www.pmi.org/disciplined-agile/lifecycle

[B-LO] For local versus global optimization - see https://en.wikipedia.org/wiki/Global_optimization

[B-GA] For genetic algorithms – see https://en.wikipedia.org/wiki/Genetic_algorithm

[B-EXLC] Disciplined Agile, Exploratory Life Cycle: https://www.pmi.org/disciplined-agile/lifecycle/exploratory-lifecycle

[B-JC]  Why Responsive Iterative Design is Evil - James Coplien | Codecamp_Festival 2022 

 https://www.youtube.com/watch?v=tjXrNeolmhg

[B-Beck] – Product development triathlon  

https://www.facebook.com/notes/kent-beck/the-product-development-triathlon/1215075478525314/

https://medium.com/@kentbeck_7670/the-product-development-triathlon-6464e2763c46

[B-DATK] Disciplined Agile Toolkit - https://www.pmi.org/disciplined-agile/toolkit