Agile Manifesto Explained: Values, Principles, and Why Some Teams Succeed and Others Don't

By the late 1990s, software development had a structural problem. The dominant approach — Waterfall — treated building software like building a bridge: gather all requirements upfront, design the full system, then deliver it, often a year or two later. But software is not a bridge. Requirements shift, priorities change, and users want something different once they see what they asked for. By the time most projects delivered, the assumptions they were built on were already outdated.

In February 2001, seventeen practitioners gathered in Snowbird, Utah and wrote down what they had in common: four values and twelve principles that reframed software development around short cycles, continuous adaptation, working software over documentation, and ongoing collaboration over fixed contracts. The Manifesto didn't invent a new methodology. It named a reaction that was already forming. Its influence spread fast and broadly. Waterfall, once the default, is today the exception. Agile thinking — in one form or another — now shapes how teams are structured, how products are built, and how delivery is measured across virtually every corner of the software industry, from two-person startups to global enterprises.

The results, however, have been uneven. The same values and principles, applied across thousands of teams, have produced wildly different outcomes — high-functioning teams that deliver consistently alongside teams trapped in process theater and the illusion of agility without any of its substance. Misinterpretations accumulated: "working software over documentation" became "no documentation"; "responding to change" became "no planning"; "self-organizing teams" became "no accountability." The Manifesto is short. What it means in practice, and why it works in some contexts and fails in others, is considerably more complex. But even a well-implemented Agile practice is only the beginning. Delivering excellence consistently requires more than good ceremonies and short sprints — it requires aligning engineering practices, team structures, technical discipline, and organizational ways of working into a coherent whole. This article is part of the Modern Agile Engineering series, which explores the broader set of methodologies, principles, and practices that engineering organizations need to move from competent delivery to genuine excellence.

The Four Core Values

The Manifesto's four core values are short enough to quote in full:

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.

Each value is structured as a trade-off, and the Manifesto is explicit about this: while there is value in the items on the right, we value the items on the left more. The right-hand side still matters. These are priorities for moments of tension, not rejections of the things they're weighed against.

Individuals and interactions over processes and tools. Software is a creative, collaborative, cognitively demanding activity. The judgment of competent people who communicate well is what produces good outcomes. Processes and tools are support structures — they should make that collaboration easier and more consistent, not replace it. When a process starts overriding human judgment rather than supporting it, something has gone wrong.

Working software over comprehensive documentation. Progress in software is easy to fake. Documents get written, milestones get checked off, percentages get reported — and none of it tells you whether anything actually works. The Manifesto says the only honest measure of progress is software that runs and does something useful. That doesn't make documentation worthless. It makes documentation subordinate — something that supports and explains the work, not something that substitutes for it.

Customer collaboration over contract negotiation. In the Waterfall model, signed-off requirements effectively became the contract. The entire project was built around that document — which meant that if the interpretation of those requirements was wrong, or the business had shifted direction, or thinking had evolved, or a new competitor had changed the market, none of that could easily be accommodated. Changing course meant renegotiating the contract, which was expensive, slow, and adversarial. The Manifesto's argument is that ongoing collaboration — continuous dialogue with the customer throughout the work — is what keeps delivery pointed at the actual problem, even as that problem evolves. The contract still exists. The question is whether it drives decisions, or the relationship does.

Responding to change over following a plan. Planning is valuable — it is an act of thinking through a problem, mapping dependencies, anticipating risk. But a plan made at the start of a project is based on what the team knew then. As work progresses, new information arrives. Responding to that information, rather than defending the original plan against it, is what keeps delivery connected to reality.

The Twelve Agile Manifesto Principles Explained

If the four values tell you what to prioritize, the twelve principles tell you how. They translate the abstract into the operational. But there's a larger structure worth naming before diving into each one, because understanding it changes how you read them.

The Manifesto works as a translation chain: values become principles, principles shape team behavior, and team behavior determines system design choices — how you architect software, how you structure delivery, how you govern quality. Most Agile discussions stop at the principles level. The deeper insight is that the principles are not independent prescriptions. They are intermediate steps in a chain that ends in concrete engineering decisions: whether you use feature flags, how you handle technical debt, how frequently you deploy, how decisions get made. If your values and principles don't eventually connect to those system-level choices, they remain decorative.

Each principle is worth reading on its own terms, because each one is answering a different practical question about how a team should behave.

1. "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

This is the foundational commitment of the entire Manifesto. Not delivery at the end. Not delivery when everything is ready. Early and continuous delivery, where the word "valuable" does a lot of work. The principle is not saying ship frequently for its own sake — it's saying that the primary measure of whether the work is going well is whether a real customer is receiving real value, and whether that is happening regularly rather than all at once at the end. Everything else in the Manifesto is in service of this.

2. "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage."

This is the principle that breaks most completely with Waterfall thinking. In a sequential process, a late change is a failure — it means someone didn't think hard enough upfront. In Agile, a late change is information. It means the team learned something, or the customer's world shifted, or what was built revealed something about what was actually needed. The second half of the principle is the part people miss: harnessing change for competitive advantage. The point isn't just tolerating change — it's treating the ability to change as a capability that delivers value. A team that can absorb and act on new information faster than its competitors is a team that is producing something genuinely useful.

3. "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

This principle operationalizes the first one. If early and continuous delivery is the goal, this is the mechanism: short cycles, regular outputs, consistent cadence. The preference for shorter timescales is deliberate. Longer cycles mean longer periods where you're building on assumptions that may be wrong. Shorter cycles mean you find out sooner. A team delivering every two weeks has twelve opportunities in six months to course-correct. A team delivering every six months has one.

4. "Business people and developers must work together daily throughout the project."

Not at the start and end. Not in weekly status meetings. Daily, throughout. The reasoning behind this is that software development decisions are not purely technical decisions. Almost every significant engineering choice involves a trade-off that the business needs to understand and weigh in on. What gets built, in what order, at what level of quality, under what constraints — these questions sit at the intersection of technical and commercial judgment. When the people with those two types of knowledge are separated, both make worse decisions. When they're close to each other, those decisions improve. Daily collaboration is the principle's way of saying: don't let the distance creep back in.

5. "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

This principle is fundamentally about respect. It says that people — not processes, not oversight mechanisms, not detailed specifications — are what produce good software. The implication is significant: if your project management approach is built around the assumption that people need to be controlled or monitored to be productive, you are starting from the wrong model of human motivation. Motivated people with the right environment will solve hard problems in ways that no process could have anticipated. Creating that environment — removing blockers, providing resources, shielding the team from distraction — is a more important leadership function than tracking progress against a plan.

6. "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

In 2001, this was essentially uncontroversial. Since then, it has become one of the most contextually dependent principles in the Manifesto. Remote and asynchronous teams have developed genuinely effective ways of communicating — documentation practices, asynchronous video, structured written decision-making — that weren't available or normalized in 2001. The underlying truth the principle is pointing at still holds: rich, back-and-forth, real-time conversation catches misunderstandings faster and builds shared understanding more efficiently than written communication alone. The question is whether "face-to-face" is the only or best way to achieve that richness. In a distributed world, the honest answer is no longer always yes.

7. "Working software is the primary measure of progress."

This is a direct challenge to how most organizations were measuring progress in 1999: by documents produced, milestones reached, percentages complete on a Gantt chart. The Manifesto says all of that is proxy measurement. The only measurement that actually tells you whether progress has been made is working software — code that runs, that does something, that a user can interact with. This principle has important implications for reporting, planning, and accountability. It means that a team that has written 10,000 lines of code, held 40 planning sessions, and produced a detailed architecture document but cannot demonstrate working software has not made progress in any meaningful sense.

8. "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

This is one of the most overlooked principles, and one of the most important for teams that have experienced the burnout side of Agile. The principle is saying explicitly that unsustainable pace is not Agile — it is a failure of Agile. A team that sprints at full intensity for six months and collapses is not demonstrating high performance. It is demonstrating poor planning and a broken relationship between capacity and commitment. The word "indefinitely" is the key. The right pace is not the fastest possible pace; it is the pace that can be maintained consistently over time, because that is what produces reliable, predictable delivery.

9. "Continuous attention to technical excellence and good design enhances agility."

A surprising number of teams use Agile as cover for technical shortcuts. Move fast, ship often, fix it later. This principle is the Manifesto's explicit rejection of that approach. It is saying that technical quality and agility are not in tension — they are complementary. A codebase that is clean, well-tested, modular, and thoughtfully designed is one that can absorb change cheaply. A codebase that is fragile, poorly understood, and tightly coupled is one where every change is expensive and risky. The more you compromise technical quality in the name of speed, the slower you go over time. Technical debt is not free — it is a loan at a very high interest rate.

10. "Simplicity — the art of maximizing the amount of work not done — is essential."

This principle is easy to misread as "do less work." What it actually means is: don't build what you don't need. The most common form of waste in software development is features that no one uses, complexity that was added in anticipation of requirements that never materialized, and abstractions that were built for flexibility that was never needed. The Manifesto is saying that every piece of work you can avoid doing — without sacrificing what the user actually needs — is a win. This requires discipline and judgment. It means resisting the temptation to build ahead, to make things "future-proof," to add the extra option just in case. Do the simplest thing that works. If more is needed later, build more later.

11. "The best architectures, requirements, and designs emerge from self-organizing teams."

This is a strong claim and a deliberate one. It is not saying that architecture should be unplanned or that anyone can make any decision at any time. It is saying that the people closest to the work — who understand the constraints, the trade-offs, the actual behavior of the system — are better positioned to make good technical decisions than people who are distant from it. Architecture handed down from above, without the involvement of the team that has to implement and live with it, tends to be wrong in ways that are hard to predict from a distance. The best technical outcomes emerge when the people with the most relevant information are empowered to act on it.

12. "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

This is the meta-principle: the principle about how to apply all the other principles. It is saying that the way a team works should itself be subject to iteration and improvement. No process, however well-designed at the start, is optimal forever. Teams learn, circumstances change, bottlenecks shift. The regular retrospective — examining not just what was built but how the team worked — is the mechanism for applying Agile thinking to Agile itself. A team that never questions its own process is a team that has stopped learning. The retrospective, when it works, is not a ceremony. It is a system-level feedback loop pointed at the team's own operating model.

Agile as a Decision System

The Agile Manifesto is a decision system under uncertainty. The values tell you what to prioritize when you have to choose. The principles tell you how to structure work so the right decisions get made by the right people at the right time. The operating model that follows — short cycles, close collaboration, technical discipline, regular reflection — is where those decisions become engineering practice.

Teams don't "become Agile" and then stop. What actually happens in healthy organizations is continuous re-interpretation: regularly examining whether the way you're working still serves the values, and adjusting. The metric isn't whether the team is running standups. It's whether the team is learning faster than the problems are changing.

The Manifesto has lasted because it was never really about software. It was about navigating uncertainty well. And it survives not because it gave the right answers, but because it asked the right questions: What are we trying to learn? How quickly can we find out? What would have to change for us to work better?

What Agile Is — and What It Is Not

Agile is a philosophy and value system. Scrum, Kanban, SAFe, and XP are implementations of that philosophy — specific methodologies with defined roles, ceremonies, and artifacts. These are not the same thing. You can follow every Scrum ceremony faithfully and violate every Agile principle. You can ignore all frameworks entirely and embody Agile thinking deeply. The Manifesto is upstream of the frameworks. It is the philosophy those frameworks are trying, with varying success, to express.

There is also a maturity dimension worth understanding. Most teams encounter Agile first at the level of ceremonies — standups, sprints, retrospectives, story points. That is where most training starts, and where most teams stay. A step deeper is the principles: what does it actually mean to welcome change, or to build around motivated individuals, or to measure progress by working software rather than completed tasks? Deeper still is systems thinking — understanding how the values and principles propagate into architectural choices, deployment pipelines, team structures, and how decisions get made. That third level is where Agile becomes genuinely powerful — and where this series operates. Read only at the ceremony level, the Manifesto produces Agile Theater. Read as a decision system, it produces better organizations.

Agile is also not a guarantee of speed. What it gives you is not raw speed but feedback velocity — the ability to learn quickly whether you're building the right thing. That is more important than how fast you build the wrong thing. And it is not an excuse to skip planning. Plans are still necessary. The difference is that you treat them as hypotheses and update them when reality contradicts them.

Context, Misuse, and What Has Aged Poorly

The Manifesto was written for a particular context: teams with direct access to users, short feedback loops, and the freedom to iterate quickly. The values it expresses — feedback, collaboration, adaptation, working evidence — hold across almost every engineering environment. The operating model that expresses those values does not. A startup can show a new feature to users on Friday. A medical device company cannot. Both can shorten internal feedback loops and make decisions closer to the work. The values are invariant. The implementation is not.

Understanding this helps explain why Agile distortions are so common — and why they take different forms. It helps to separate them.

Misinterpretation — the text is read incorrectly.

These are cases where the words of the Manifesto are taken at face value without understanding the intent behind them.

"Working software over documentation" becomes "no documentation." Teams stop writing architecture diagrams, decision records, onboarding guides, and runbooks. The result is a codebase only its original authors understand, institutional knowledge that walks out the door with every departure, and systems that become impossible to maintain or extend. The Manifesto was arguing against documentation that substitutes for working software — thick specification documents produced instead of actual delivery. It was never arguing against the communication that supports a team's ability to work effectively.

"Responding to change" becomes "no planning." The argument that plans should be held lightly gets misread as plans being unnecessary. Teams stop thinking ahead, stop mapping dependencies, stop anticipating risk. Every sprint becomes reactive. Long-term technical direction dissolves. The Manifesto's point was that plans should be updated when reality contradicts them — not that you shouldn't make them.

"Self-organizing teams" becomes "no accountability." If the team organizes itself, the reasoning goes, no individual is responsible for outcomes. Decisions get diffused across the group, hard calls never get made, and when things go wrong there is no one to own it. Self-organization is about where good technical and tactical decisions are made — close to the work, by people with context. It was never about removing accountability.

Velocity becomes a measure of productivity. Story points were designed as a tool for teams to forecast their own capacity. When management starts tracking velocity as a performance metric, teams respond rationally: they inflate estimates. Velocity goes up, actual delivery doesn't. The feedback loop that story points were meant to create gets corrupted.

Misapplication — the right idea, applied in the wrong way.

These are cases where the intent is understood but the execution misses.

Sprints become mini-Waterfalls. The team does full requirements, design, build, and test within each sprint — but the sprint boundary is just a time box, not a feedback loop. Nothing is shown to users, nothing is validated externally, nothing actually changes based on what was learned. The ceremony is present. The learning loop is absent.

Standups become status reports. Each person reports what they did yesterday and what they'll do today, directed at a manager rather than at the team. No blockers are raised. No help is offered. The standup exists to tick a box, not to coordinate work or surface problems.

Retrospectives become complaint sessions. The same issues are named every two weeks — slow build times, unclear requirements, too many meetings — without any action following. The team has learned that retrospectives are where problems go to be acknowledged and forgotten. The ceremony produces no change.

The backlog becomes a dumping ground. Every idea, request, bug, and piece of technical debt goes into the backlog and stays there indefinitely. It grows to hundreds of items, nobody prioritizes it seriously, and the team picks work based on what is loudest or easiest rather than what is most valuable. The backlog stops being a prioritization tool and becomes a list of things no one will ever do.

Agile becomes a delivery pressure mechanism. The language of Agile — sprints, velocity, burn-down — gets adopted by management as a way to push teams harder and track output more granularly, without any of the autonomy, feedback loops, or collaboration the Manifesto describes. Teams end up with more scrutiny and less support. This is probably the most corrosive misapplication because it poisons the well: teams associate Agile with pressure rather than with effectiveness.

Evolution — the world has built on top of the Manifesto.

Not everything that looks like a departure from the Manifesto is a failure. Some of it is the natural development of the same ideas into better tools and systems.

DevOps is Agile's feedback loop extended into the deployment pipeline. Continuous integration, automated testing, and deployment automation reduce the distance between a decision and its consequences in production — which is exactly what the Manifesto was pointing at. Product analytics replaced demo-based feedback with real behavioral data: rather than asking users what they think, you observe what they actually do. Platform engineering took the self-organizing team ideal and gave it structural constraints, allowing teams to move autonomously without creating chaos in shared infrastructure.

These aren't corrections to Agile. They're what Agile values look like when expressed through infrastructure and tooling that didn't exist in 2001.

Constraint mismatch — some principles haven't aged equally.

Not all twelve principles carry equally well across modern engineering contexts. It helps to think of them in three categories.

Some principles are universal in intent and fully applicable regardless of environment: shorten feedback loops, keep decision-makers close to the work, treat plans as hypotheses, measure progress by working software. These hold in a startup, an enterprise, a regulated industry, a distributed team.

Others are universal in intent but partially obsolete in prescription. Face-to-face communication as the primary channel for information exchange described the best available mechanism in 2001. Distributed teams with modern tooling — asynchronous video, structured written decision-making, collaborative documentation — have developed genuinely effective alternatives. The goal the principle points at is still right. The specific mechanism has been superseded.

A few are structurally incompatible with certain domains. Continuous delivery of working software to end users is simply not possible in aviation software, medical devices, or nuclear control systems, regardless of intent. Early and frequent feedback still applies — through internal testing environments, simulation, staged regulatory approvals — but the principle has to be adapted rather than applied directly.

Recognizing which category a principle falls into is what separates thoughtful application from either blind compliance or lazy dismissal.

When Agile Doesn't Fully Apply

The Manifesto was built on a set of assumptions: uncertainty is high, feedback is accessible, and iterating is cheaper than planning exhaustively upfront. In a product team building a consumer app, those assumptions hold well. In other environments, they hold only partially — and that changes what Agile looks like in practice.

In regulated industries — medical devices, aviation software, financial systems — feedback loops are constrained by approval cycles, and documentation is not optional. You cannot ship incrementally to end users and observe what happens. The cost of failure is not a sprint retrospective; it is a compliance violation or a safety incident. Teams in these environments still benefit from short internal feedback loops, cross-functional collaboration, and working incrementally — but the ceremonies and cadences of a typical Agile team need significant adaptation.

In large enterprises, the challenge is different. Agile at the team level is well understood. Agile across dozens of interdependent teams, with shared platforms, governance requirements, and quarterly budget cycles, is a different problem entirely. The Manifesto offers no guidance on how to coordinate at scale — that's where frameworks like SAFe, LeSS, and Spotify-model thinking emerged, with varying degrees of success.

In fixed-scope contractual environments — where a client has signed off on a specific deliverable for a fixed price — "welcoming changing requirements" is structurally difficult. The contract limits adaptability. Teams in this situation can still apply Agile thinking internally — delivering incrementally, getting early feedback, maintaining technical quality — but the customer collaboration loop operates within tighter constraints than the Manifesto assumed.

The point is not that Agile fails in these environments. It is that the values and principles have to be translated differently. The closer your environment is to the one the Manifesto assumed — small team, direct user access, high uncertainty, fast feedback — the more directly the principles apply. The further you are from it, the more interpretation is required.

Why Some Teams Perform and Others Don't

The Agile Manifesto is public, free, and has been widely read for over two decades. Every team has access to the same values and principles. And yet the performance gap between engineering teams — in delivery speed, technical quality, stability, and team health — is as wide as it has ever been. If the Manifesto were sufficient on its own, that gap shouldn't exist.

It points to something important: Agile is necessary but not sufficient.

Interpretation depth. Low-performing teams engage with Agile at the ceremony level — they run the standups, estimate the stories, hold the retrospectives. High-performing teams engage with the principles: they understand why short cycles matter, why feedback loops need to be tight, why technical quality is inseparable from delivery speed. When teams understand the principles, they adapt the ceremonies intelligently. When they don't, they follow the ceremonies rigidly and wonder why they aren't getting the results. The ceremony is the expression. The principle is the point.

Organisational context. High-performing teams understand the environment they operate in — the constraints, the stakeholders, the dependencies, the political realities — and they translate Agile values accordingly. They know which principles apply directly, which need adaptation, and which are structurally limited by their context. Low-performing teams apply a generic playbook without regard for context, then conclude that Agile doesn't work.

What Agile doesn't cover. This is where the real gap lives. The Manifesto is silent on a significant number of things that determine whether a team performs — and high-performing teams fill those gaps deliberately.

It says nothing about engineering culture. Without it, you get teams with good process and poor craft — code gets written, standards drift, technical debt accumulates silently until delivery slows to a crawl.

It says nothing about sound architecture. Principle 9 mentions that good design enhances agility, but the Manifesto offers no guidance on how to make architectural decisions, how to evolve architecture as systems grow, or how to recognise when architectural debt is quietly destroying delivery speed. High-performing teams treat architecture as a first-class, ongoing concern. Low-performing teams treat it as something iteration will eventually sort out — and discover too late that it won't. Poorly designed systems become harder to change with every sprint, which is the precise opposite of what Agile is trying to achieve.

It says nothing about leadership. The Manifesto trusts motivated individuals and self-organizing teams, but says nothing about what good engineering leadership actually looks like. Leaders create — or destroy — the conditions that Agile depends on. They set technical standards, protect team focus, resolve blockers, develop people, and make the organizational decisions that determine whether short feedback loops are even possible. Poor leadership quietly undermines everything the Manifesto is trying to achieve: self-organizing teams drift without direction, technical standards erode without reinforcement, and the psychological safety that makes honest retrospectives possible never gets established.

It says nothing about technical leadership development. Without it, senior engineers leave or get promoted into management, and the team loses its technical spine. Ceremonies continue. Quality quietly declines.

It says nothing about hiring and team composition. You can have perfect Agile practices and a team that cannot execute. Process does not substitute for capability.

It gestures at psychological safety — "give them the environment and support they need, and trust them" — but offers no guidance on how to actually build it. Without it, self-organization becomes performance. People agree in the room and do something different outside it. Retrospectives surface safe problems. Real problems stay hidden.

It says nothing about organizational design, stakeholder management, or how to structure teams around value streams rather than functional silos. High-performing teams draw on management theory, systems thinking, and organizational design to fill these gaps. They treat Agile as a foundation, not a complete answer.

Measurement discipline. High-performing teams measure the right things — lead time, deployment frequency, change failure rate, team health. Low-performing teams measure velocity and sprint completion rates. The first set tells you whether your system is working. The second tells you whether people are busy. They are not the same question.

Continuous adaptation. The best teams treat their own ways of working as a system under continuous improvement. They don't implement Agile once and consider it done. They regularly examine whether their practices are producing the outcomes they want and change what isn't working. This is level three Agile maturity in practice: not following a framework, but using a value system to make better decisions about how to work, continuously and deliberately.

The difference between these teams and the ones running ceremonies without outcomes is not a gap in knowledge of the Manifesto. It is a gap in how deeply the values have been understood, how honestly the context has been assessed, and how much broader organizational and engineering craft has been brought to bear alongside it.

Agile is where effective engineering starts. It is not where it ends.

This Modern Agile Engineering series is built around this premise. Each article goes deeper into a dimension that the Manifesto alone doesn't cover — technical practices and delivery systems, engineering culture and team design, technical leadership, measurement and flow, organizational ways of working. The goal is not just to explain Agile. It is to build the complete picture of what genuinely high-performing engineering organizations do differently — and how to get there.

Key Takeaways

For readers who want a crisp summary before going deeper:

The Agile Manifesto is best understood as a decision system under uncertainty — more precisely, a translation system that moves from values into principles, from principles into team behavior, and from team behavior into engineering operating models. It was written in 2001 as a reaction to heavyweight, plan-driven software processes that were too slow and too rigid for the realities of software development. It contains four values and twelve principles. The values establish priorities for moments of trade-off. The principles translate those values into operational team behaviors. The frameworks — Scrum, Kanban, SAFe — are institutional implementations of those values, not Agile itself.

Agile's core premise is that uncertainty is high, feedback is valuable, and the ability to adapt is a competitive capability. Where the translation chain breaks — where teams run ceremonies without outcomes, skip the feedback loops, or treat the framework as the point — the result is Agile Theater rather than Agile practice.

The principles sometimes conflict deliberately. Navigating those tensions — speed versus technical quality, autonomy versus platform constraints, change versus predictability — is where genuine Agile judgment is exercised. Not all principles are equally portable: some are universal in intent, some are partially obsolete in prescription, and some are structurally incompatible with certain domains. Knowing which is which is the real skill.

The values have proven durable. Some of the specific prescriptions have aged unevenly. And none of it requires agreement — only honest engagement with which assumptions hold in your context and which don't.