Professional Scrum Master I (PSM I) Certification Study
The Rise of the Agile Movement
How the software industry's search for lighter, adaptive ways of working converged at Snowbird in 2001 - and why Agile is a set of values and principles, not a single methodology
Estimated reading time: 20 minutes
By João Ricardo Dutra••Complete article
Chapter objective
Understand the software-development context of the 1990s, the emergence of so-called , the problems their creators were trying to solve, the Snowbird meeting in February 2001, the birth of the , and the crucial distinction between as shared values and principles and any particular method or framework such as or .
Introduction: Did Not Begin with a Meeting
The did not create the need for adaptation. It gave a name and shared language to lessons practitioners had already been learning for years.
It is tempting to tell the history of as a clean origin story: seventeen software professionals met at a ski resort in Utah in 2001, wrote a manifesto, and a new way of building software was born. The meeting was real, the manifesto was extraordinarily influential, and the date matters. But the simplified story hides the most useful lesson. was not invented from nothing at Snowbird. Snowbird was the moment when several streams of practice, frustration, experimentation, and professional learning finally found common language.
Throughout the 1990s, many software organizations were struggling with a mismatch between the way projects were managed and the way software knowledge actually emerged. Large plans promised control. Extensive documentation promised clarity. Specialized phases promised efficiency. Formal change procedures promised stability. Yet teams repeatedly discovered that requirements changed, users learned what they needed only after seeing software, integrations behaved differently from specifications, estimates decayed as assumptions changed, and exposed problems that had been accumulating for months.
This did not mean that every traditional project failed, nor that disciplined engineering was the enemy. The deeper problem was that the industry often tried to manage uncertain product development as if it were a predictable production process. The previous chapters explored why this becomes dangerous in complex work. By the 1990s, practitioners in different communities were independently arriving at a related conclusion: software development needed shorter feedback loops, closer collaboration, stronger technical practices, smaller batches of work, and more room to adapt as knowledge changed.
These approaches were initially described with labels such as or lightweight methodologies. The name was imperfect. "Lightweight" could sound unserious, as if rigor were being removed rather than relocated. In reality, many of these methods were highly disciplined. , for example, emphasized practices such as automated testing, ,, and close customer involvement. emphasized empirical control, iterative and incremental development, and frequent opportunities to . Other approaches attacked similar problems from different angles.
The gave this diverse movement a shared vocabulary. It did not erase the differences among its participants. It identified what they had learned to value more strongly after years of building software. For a candidate, this history matters because and are related but not interchangeable. existed before the Manifesto. is a specific framework. , in the sense established by the Manifesto, is a broader set of values and principles that influenced how people understand adaptive software development. Knowing that distinction prevents one of the most common conceptual mistakes in education: treating as if it were a branded process with one universal workflow.
The Software Industry of the 1990s: Pressure for a Different Approach
The 1990s were a period of enormous technological and commercial change. Personal computing expanded, client-server architectures became common, object-oriented programming gained influence, graphical user interfaces raised expectations, enterprise systems connected more business functions, and the public Internet transformed both software distribution and the pace of competition. Software was no longer merely a supporting component hidden inside a back-office environment; increasingly, it was becoming part of how organizations competed, communicated, sold, and served customers.
At the same time, many development organizations relied on process models influenced by predictive engineering and large-project management. Requirements were often expected to be substantially defined before construction. Analysis and design attempted to reduce uncertainty early. Development could be separated from testing and operations. Progress might be represented through documents, milestones, phase completion, or percentage-complete reports long before users had meaningful to evaluate.
Those approaches answered real organizational needs. Large programs require coordination. Contracts require scope and accountability. Safety-critical environments require evidence. Enterprises need architecture, budgeting, compliance, and governance. The problem was not the existence of planning or documentation. The problem was using these mechanisms as substitutes for feedback. When an organization could not observe useful software until late in a project, mistaken assumptions could survive for months while plans continued to look healthy.
The growing commercial pace made this more visible. A requirement written six months earlier might no longer reflect customer priorities. A competitor could change the market. A new platform or technology could alter the economics of a design. A project could deliver exactly what had been specified and still deliver too late, solve the wrong problem, or impose a user experience nobody wanted. The industry needed ways to keep engineering discipline while reducing the delay between a decision and evidence about that decision.
This environment also exposed the social nature of software development. Software is created through knowledge work: people interpret ambiguous needs, make design trade-offs, discover constraints, resolve conflicts, and communicate constantly. Treating as interchangeable production units ignored the importance of expertise, conversation, motivation, and shared understanding. Several emerging methods therefore became explicitly people-oriented as well as adaptive. They were not only asking how to schedule work differently. They were asking what kind of organization helps skilled people solve difficult problems together.
The Rise of
Before the word became the umbrella term, practitioners used descriptions such as . Martin Fowler's July 2000 essay "The New Methodology" captured the moment well: several communities were already exploring approaches that contrasted with established, more predictive methodologies. Fowler emphasized two recurring characteristics - adaptiveness and a people-first orientation - rather than the literal amount of documentation or process.
The landscape was diverse. had been developed in the early 1990s by Jeff Sutherland and Ken Schwaber and was formally presented publicly at OOPSLA in 1995. , associated especially with Kent Beck and the Chrysler C3 project in the mid-1990s, combined very short development cycles with demanding engineering practices. Dynamic Systems Development Method, , Adaptive Software Development, Feature-Driven Development, pragmatic programming ideas, and other approaches offered different combinations of principles and techniques.
The methods did not agree on everything. Some prescribed technical engineering practices. Some focused more strongly on project or product management. Some varied according to team size or system criticality. Some were intentionally minimal. That diversity is important: the movement did not arise because one group discovered a perfect process. It arose because multiple groups were solving related problems and noticing overlapping lessons.
One lesson was that requirements could not always be treated as a complete contract with the future. Another was that provides information that specifications cannot. Another was that business representatives and technical people need frequent collaboration instead of communicating primarily through documents and handoffs. Another was that quality cannot be postponed to a distant test phase without increasing risk. And another was that teams need enough autonomy to adapt their work as reality changes.
Calling these methods "lightweight" sometimes led critics to assume that their advocates opposed planning, architecture, documentation, or discipline. Historical accounts from the 's authors directly reject that interpretation. The movement was seeking balance. The emerging methods still planned; they simply acknowledged the limits of long-range prediction in turbulent environments. They still documented; they questioned documentation that became detached from useful communication. They still designed; they preferred designs that could evolve with learning rather than attempting to eliminate all uncertainty before implementation.
This distinction is especially relevant to . is deliberately lightweight, but lightweight does not mean vague. It establishes clear accountabilities, events, artifacts, commitments, and rules while leaving many implementation techniques to the people doing the work. The purpose of the constraints is to create a reliable empirical system, not a bureaucratic script.
Different Practitioners, Similar Problems
The people who later signed the came from different backgrounds and methods, yet they were responding to recognizable families of problems. Understanding those problems is more useful than memorizing a list of names because the same tensions still appear in modern organizations.
The first problem was delayed value. Projects could consume substantial budgets before users received anything usable. When delivery happened in large batches, the business waited longer for benefits and the team waited longer for meaningful evidence. Frequent delivery offered a way to reduce both delays.
The second problem was delayed learning. If appeared late, misunderstandings about requirements, design, integration, usability, and technical feasibility could remain hidden. Short iterations turned development into a repeated learning process: build something meaningful, inspect what happened, then adjust.
The third problem was the cost of change. Predictive approaches often attempted to control change through stronger baselines and approval mechanisms. The emerging methods tried to reduce the technical and organizational cost of change so adaptation became economically possible. Practices such as automated tests, ,, simple design, iterative planning, and frequent prioritization all contributed in different ways.
The fourth problem was communication through handoffs. When analysts, designers, programmers, testers, customers, and managers operated as separate stages, information could degrade at every boundary. Lightweight approaches generally increased direct collaboration and shortened the distance between people who understood the business problem and people who created the software.
The fifth problem was false progress. A project could be "80 percent complete" according to plans while the integrated product remained unusable. Emerging approaches placed more weight on demonstrable, working results. This shift from activity to evidence later became one of the most recognizable ideas associated with software development.
Finally, practitioners were wrestling with the human side of complex work. Creative problem solving does not behave like an assembly line. Teams needed trust, technical competence, rapid communication, and room to make local decisions. The challenge was not to eliminate management; it was to create conditions in which people could respond intelligently to information instead of waiting for every adjustment to move through a centralized command structure.
Snowbird, Utah: February 2001
From February 11 through 13, 2001, seventeen practitioners met at The Lodge at Snowbird in the Wasatch Mountains of Utah. According to the official history of the , the gathering brought together representatives and advocates connected with ,,, Adaptive Software Development, , Feature-Driven Development, pragmatic programming, and related approaches. They came to find common ground among methods that had often been discussed under the unsatisfying label "lightweight."
The meeting did not appear without preparation. An earlier gathering organized by Kent Beck in Oregon in 2000 had brought together practitioners and several outsiders, and conversations about lightweight approaches were already circulating. Later in 2000, Robert C. Martin proposed gathering leaders of these methods in one room. Discussions followed, including debate about the name and even the location. Snowbird ultimately became the setting for the agreement that shaped the movement's identity.
The remarkable outcome was not a merged methodology. Seventeen strong-minded practitioners did not attempt to combine ,,,, and every other method into one giant process. Instead, they articulated a small set of shared values and then a set of supporting principles. The result was named the .
The word "" mattered because it described a quality the group wanted: responsiveness and adaptability without implying that the work was trivial or "lightweight" in the dismissive sense. The new name helped a collection of related approaches become a recognizable movement. The Alliance was also formed to continue advancing the ideas.
For students, the date February 2001 is easy to memorize. The more important fact is conceptual: Snowbird was an act of synthesis. The signatories looked across their different practices and asked what underlying beliefs they shared. That is why the Manifesto is expressed as values rather than as a process diagram.
The : A Statement of Preference
The Manifesto is intentionally short. Its authors said they were discovering better ways to develop software through practice and by helping others. They expressed four paired value statements. In each pair, both sides retain value, but the authors placed greater emphasis on the side associated with human collaboration, usable results, customer partnership, and responsiveness to change.
This structure is frequently misunderstood. does not say that have no value. It does not say documentation should disappear. It does not say contracts are irrelevant. It does not say planning is waste. The final sentence of the value statement explicitly preserves value in the items receiving emphasis. The point is priority: when the two sides come into tension, the movement learned that effective software development often depends more strongly on interaction, working outcomes, collaboration, and adaptation.
The twelve principles behind the Manifesto expand this logic. They emphasize early and of valuable software, welcoming changing requirements, frequent delivery, daily collaboration between business and , motivated people, effective communication, as a key measure of progress, ,, simplicity, , and regular reflection followed by adjustment.
Seen together, the values and principles form a coherent theory of learning. Short delivery cycles produce evidence. Collaboration improves the interpretation of that evidence. keeps the product changeable. Simplicity limits unnecessary investment. can act on local knowledge. Reflection improves the system of work itself. is therefore not simply "go faster." Its deeper promise is to improve the organization's ability to learn and respond while continuously producing useful software.
This also explains why superficial transformations often disappoint. Renaming a project manager "," changing requirements documents into tickets, creating a board, or scheduling daily meetings does not necessarily make an organization adaptive. If feedback still arrives late, decisions remain centralized, is rare, quality is postponed, and plans cannot change when evidence changes, the vocabulary may be while the operating model remains predictive.
as Mindset and Principles - Not One Specific Methodology
One of the most important concepts for a learner is that is not a single methodology with a universal sequence of steps. The Manifesto does not define roles, events, artifacts, iteration lengths, estimation techniques, backlog formats, board columns, or engineering tools. It provides values and principles. Different methods and frameworks can embody those ideas in different ways.
Calling a "mindset" is a common modern shorthand for this broader orientation. The word mindset does not appear as a formal component of the 2001 Manifesto, so it should not be treated as an additional official rule. Used carefully, however, it is helpful: it describes a preference for learning, collaboration, customer value, technical quality, and adaptive decision-making over rigid adherence to an initial plan. A mindset influences how people interpret situations; a method provides more concrete structures and practices.
is one such concrete framework, but and are not synonyms. was already being practiced and described before 2001. Ken Schwaber and Jeff Sutherland were among the seventeen Manifesto signatories, and aligns strongly with and principles. Yet has its own definition in the Scrum Guide. It specifies a with three accountabilities, five formal events inside the , three artifacts and their commitments, and an empirical foundation. None of those structures is defined by the itself.
provides another example. is also associated with , but it includes a different and more explicit set of engineering practices. An organization can use together with complementary engineering practices influenced by . It can also follow without using . Conversely, a team can imitate the visible mechanics of while behaving in ways that undermine the adaptive values associated with .
This distinction is not academic trivia. It changes how you reason about exam questions and real organizations. If someone asks, "Does require a ?" the answer is no: the is a event. If someone asks, "Does require user stories?" the answer is also no: user stories are a commonly used technique, not a requirement. If someone asks whether responding to change is compatible with , the answer is yes at the level of its values and principles. Clear vocabulary prevents practices from becoming accidental dogma.
A Practical Example: Two Teams, the Same Requirements Change
Imagine two software teams building an online loan application. At the beginning of the initiative, both believe customers will be comfortable completing a twelve-step application before receiving any indication of eligibility. Midway through development, user research reveals a strong pattern: many customers abandon the process because they want an early estimate before providing detailed information.
Team A follows a strongly interpretation of delivery. The twelve-step flow was approved, designed, documented, and assigned to several specialist groups. Changing it now requires a formal request, impact analysis, budget approval, redesign, and rescheduling. Managers worry that accepting the discovery will make the project appear out of control. The team therefore finishes the original plan and intends to address abandonment in a later release.
Team B works from an orientation. It still has goals, budget constraints, architecture, compliance requirements, and a plan. But the plan is treated as a means to create value, not as the value itself. The new evidence triggers a conversation among product and technical people. They identify a smaller experiment: provide an early indicative eligibility result using a minimal data set, measure conversion and customer understanding, then decide how to adapt the rest of the journey.
The difference is not that Team B accepts every request immediately. responsiveness is not uncontrolled scope. The team evaluates the evidence against the , business value, risk, cost, and technical implications. What changes is the default relationship with learning. New information is not automatically treated as a threat to the plan; it is treated as potentially valuable input for the next decision.
Now connect the scenario to . A might make the emerging insight transparent through and stakeholder collaboration. The could adjust based on value and learning. During a , the and could renegotiate scope as more is learned, provided the is not endangered. A could inspect the and market or user feedback, informing what to do next. supplies a concrete empirical structure through which the broader preference for responding to change can be practiced professionally.
This is the key materialization of thinking: do not optimize for perfect obedience to yesterday's assumptions. Optimize for valuable outcomes by creating short paths from idea to evidence to adaptation.
Why This History Matters for
is a assessment, not an history exam. Still, understanding this chapter prevents several mistakes that appear repeatedly in learning. First, did not originate as a consequence of the ; it predates the 2001 meeting. Second, does not define . The Scrum Guide defines . Third, does not prescribe popular practices simply because teams often use them.
The history also makes 's easier to understand. The movement that converged at Snowbird was reacting to long feedback loops, rigid plans, weak , and process structures that could hide the true state of a product. addresses these tensions through transparency, inspection, adaptation, short Sprints, usable Increments, clear accountabilities, and an emergent . The framework is not a translation of the Manifesto into ceremonies, but the philosophical alignment is visible.
For exam reasoning, avoid replacing with vague statements such as " says we should be flexible." Flexibility alone is not enough. creates disciplined boundaries. A has a fixed length. Quality must not decrease. The provides focus. Accountabilities cannot simply be reassigned because a manager prefers another structure. Adaptation happens within a framework designed to make change useful rather than chaotic.
A strong candidate therefore keeps three layers separate: and principles; as a defined framework; and optional practices used by a particular organization or team. Once those layers are clear, many apparently difficult questions become classification problems: Is this required by ? Is it compatible with thinking but optional? Or is it simply a local practice that may or may not help?
Conclusion: A Name for a Movement That Was Already Learning
The movement emerged from years of experimentation rather than from a single theoretical invention. During the 1990s, software practitioners faced increasing pressure from changing technology, faster markets, uncertain requirements, delayed feedback, costly handoffs, and the limits of highly predictive development models. Different communities responded with methods that were often called lightweight because they reduced unnecessary process and increased adaptation, collaboration, and delivery of .
By February 2001, enough of these approaches had matured for seventeen practitioners to meet at Snowbird and identify common ground. Their achievement was not a universal methodology. It was a compact statement of values and principles that named what their experience had taught them to emphasize. The gave the movement a shared identity and vocabulary that spread far beyond the people in the room.
is therefore best understood as a broad orientation toward software development: value people and collaboration, seek real working outcomes, involve customers closely, and remain able to respond when reality invalidates the plan. Those ideas are supported by principles about frequent delivery, , sustainable work, simplicity, , and . Specific frameworks and methods provide different mechanisms for putting these ideas into practice.
In my view, the most important legacy of the movement is not speed. It is intellectual humility combined with disciplined action. accepts that complex software work contains uncertainty and then asks teams to expose that uncertainty through frequent delivery, feedback, collaboration, and technical quality. It replaces the illusion of control with a tighter relationship between decisions and evidence.
For a future , that history provides a useful foundation. is not " meetings," and is not " without rules." is a specific empirical framework that belongs to a broader tradition of adaptive product development. Understanding where that tradition came from makes the framework easier to apply with purpose rather than ritual - and prepares you to study the and principles in greater depth without confusing them with the rules of .
A Short Timeline: From to
A Short Timeline: From to
Period
Development
Why It Matters
Early 1990s
is developed by Jeff Sutherland and Ken Schwaber.
Shows that predates the .
1994-1996
Methods such as and emerge or take recognizable form; is presented at OOPSLA 1995.
Multiple communities are independently experimenting with adaptive delivery.
Late 1990s
, Adaptive Software Development, Feature-Driven Development, pragmatic programming ideas, ,, and others gain visibility.
The "" category begins to form.
2000
Practitioners discuss common ground at meetings and in articles; Martin Fowler publishes "The New Methodology."
Shared patterns are becoming visible before a shared name exists.
Feb. 11-13, 2001
Seventeen practitioners meet at Snowbird, Utah.
They synthesize common values rather than merge their methods.
2001 onward
The and Alliance give the movement a recognizable identity.
"" becomes the umbrella term for a broader family of adaptive approaches.
,, and Team Practices: Keep the Layers Separate
,, and Team Practices: Keep the Layers Separate
Layer
What It Provides
Examples
and principles
Broad preferences and principles for adaptive software development.
Collaboration, frequent valuable delivery, responding to change, , reflection.
A defined framework for generating value through adaptive solutions to complex problems.
Context-dependent techniques selected by teams or organizations.
User stories, ,, boards, workflows, / tools.
exam mindset
Do not answer a question by saying " is flexible, so anything can change." is adaptive, but it has explicit rules, accountabilities, timeboxes, commitments, and quality expectations. Separate from requirements and from optional practices.
Key Takeaways
The movement grew out of practical experiments during the 1990s; it was not invented from scratch in 2001.
Practitioners were responding to delayed feedback, changing requirements, costly handoffs, weak , and false certainty in predictive plans.
"" included several distinct approaches such as ,,,, Adaptive Software Development, and Feature-Driven Development.
Seventeen practitioners met at Snowbird, Utah, on February 11-13, 2001 and produced the .
The Manifesto expresses shared values and principles, not a universal software-development process.
is commonly described as a mindset, but the official 2001 artifact is a set of values and principles; the term should not be confused with a specific methodology.
predates the and remains a separately defined framework, even though its empirical approach aligns strongly with and principles.
User stories, ,,, and similar techniques may be useful but are not requirements of either the or .
Search and Study Vocabulary
Useful terms for further study and preparation
movement history; history; Snowbird 2001; lightweight software methods; software development; software industry 1990s; history; history; ; methods; Adaptive Software Development; Feature-Driven Development; and principles; ; vs ; adaptive software development; responding to change; ;;; incremental development; ; concepts.
Schwaber, Ken, and Jeff Sutherland. The Scrum Guide, November 2020. - The current official definition of and the source for distinguishing the from broader and optional team practices.
Historical note: software development in the 1990s was diverse; not every organization used a rigid process, and existed long before the . This chapter describes the tensions that motivated the lightweight-methods movement without implying a single universal pre- practice.
