Agile Methodology: Manifesto, Principles, and Practice

Created by The Agile Manifesto Authors (2001) - https://agilemanifesto.org

Overview

Agile is a way of building products in short cycles, getting feedback on each result, and changing the plan based on what the team learns. The Agile Alliance defines it as "the ability to create and respond to change" and calls it an umbrella term for frameworks and practices based on the Manifesto's values and principles (Agile Alliance, Agile 101). That distinction matters in practice. The agile methodology people talk about is a set of values and principles, and named frameworks such as Scrum, Kanban and Extreme Programming are concrete ways of acting on them.

The name and the shared definition come from one meeting. In February 2001, seventeen people met at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, according to Jim Highsmith's history of the Manifesto. They included representatives of Extreme Programming, Scrum, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming. The result was the Manifesto for Agile Software Development, signed by its seventeen authors, among them Kent Beck, Ward Cunningham, Martin Fowler, Jim Highsmith, Ken Schwaber and Jeff Sutherland. Highsmith notes that before the meeting, during 2000, a number of articles had grouped these approaches as "Light" or "Lightweight" processes, and that the group left Snowbird naming itself "The Agile Alliance."

The Agile Manifesto states four values. Its authors wrote that they had come to value "Individuals and interactions over processes and tools", "Working software over comprehensive documentation", "Customer collaboration over contract negotiation" and "Responding to change over following a plan." The sentence after the list is easy to skip and changes the meaning: "That is, while there is value in the items on the right, we value the items on the left more." Agile keeps plans, documents, contracts and tools. It ranks them below the people, the working product, the customer and the ability to change course.

The twelve principles behind the Manifesto turn those values into working rules. They ask for "early and continuous delivery of valuable software", for delivering working software "from a couple of weeks to a couple of months, with a preference to the shorter timescale", and they state that "Working software is the primary measure of progress." They also cover daily collaboration between business people and developers, motivated and trusted teams, sustainable pace, technical excellence, simplicity and regular reflection. Most arguments about whether a team is "really agile" can be settled by checking a practice against one of these agile principles.

Short, feedback-driven cycles are much older than the word. Craig Larman and Victor Basili's history of iterative and incremental development traces the practice back to the mid-1950s and describes NASA's Project Mercury in the early 1960s running half-day, time-boxed iterations. The same paper argues that Winston Royce's 1970 article, usually cited as the origin of waterfall, is widely misread: Royce himself recommended building a pilot version first and doing the job twice. In Larman and Basili's account, the 2001 meeting gave a set of existing lightweight methods a common banner, the Agile Alliance and the phrase "agile methods."

Martin Fowler, one of the authors, summarizes the idea in two contrasts: agile development is "adaptive rather than predictive" and "people-oriented rather than process-oriented" (Fowler, Agile Software Guide). He also warns that much of what is done under the name is "faux-agile", and names fighting the "Agile Industrial Complex" and its habit of imposing process on teams as one of three main challenges. In his words from a 2018 talk, "The team doing work decides how to do it. That is a fundamental agile principle" (Fowler, State of Agile Software in 2018).

Agile project management is therefore less about a specific set of meetings and more about how decisions get made. A team plans in small increments, shows working results to the people who will use them, and adjusts both the product and its own process. The steps below describe a common way to run that loop, and the skills linked from this page cover each part in depth.

Core Principles

Deliver Working Software Early and Often

The first principle calls for "early and continuous delivery of valuable software", and the third asks teams to deliver "from a couple of weeks to a couple of months, with a preference to the shorter timescale" (Agile Manifesto principles). Frequent delivery shortens the time between a decision and the evidence about whether it was right. It also forces work to be split into slices that are useful on their own. A team that reports progress in documents or ticket counts, and cannot show anything usable, has drifted from the principle that "Working software is the primary measure of progress."

Welcome Changing Requirements

The second principle reads: "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage" (principles). Agile assumes that requirements will change as the team and its customers learn. The practical consequence is to keep change cheap: short cycles, an ordered backlog that can be reshuffled, and designs that do not lock in decisions early. Highsmith's history puts the same idea as "We plan, but recognize the limits of planning in a turbulent environment" (history).

Business and Developers Work Together Daily

The Manifesto asks that "Business people and developers must work together daily throughout the project", and names "face-to-face conversation" as the most efficient and effective way to convey information within a team (principles). Conversation carries more information per minute than documents do, and questions answered in minutes by the person who knows prevent days of building the wrong thing. Distributed teams keep the principle by favoring live conversation over long written threads when something is ambiguous. A team that learns what the customer wanted only at the end of a cycle has lost this principle.

Trust Motivated, Self-Organizing Teams

The principles say to "Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done", and that "The best architectures, requirements, and designs emerge from self-organizing teams" (principles). Self-organizing means the team decides how to do its work, while leaders set direction and remove obstacles. Fowler calls the team choosing its own process "a fundamental agile principle" (Fowler, 2018). In the same talk he calls methods imposed on people by the Agile Industrial Complex "an absolute travesty."

Keep a Sustainable Pace

"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely" (principles). Short cycles make it tempting to treat every sprint as a deadline, and a team that ends each cycle exhausted will cut quality to keep up. Plan against what the team has actually finished in recent cycles, and treat regular overtime as a planning problem to fix.

Pay Attention to Technical Excellence and Simplicity

Two principles work together here: "Continuous attention to technical excellence and good design enhances agility" and "Simplicity--the art of maximizing the amount of work not done--is essential" (principles). Fowler's "Flaccid Scrum" describes what happens without the first: teams adopt Scrum's practices, and "After a while progress is slow because the code base is a mess" (Fowler, Flaccid Scrum). Simplicity means building what the current goal needs and deferring the rest. Both keep change cheap, which is what the other principles depend on.

Reflect and Adjust at Regular Intervals

The last principle: "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" (principles). This is how an agile team improves its own process instead of waiting for a new one to be imposed. The Scrum Guide builds the same idea into its retrospective, whose purpose is "to plan ways to increase quality and effectiveness" (Scrum Guide). A reflection that never changes anything is a sign the team is going through the motions.

Steps

1. Check that the work suits agile Agile pays off when the team does not know in advance exactly what to build or how, and can learn by shipping small pieces. List what is uncertain: customer needs, technology, market, regulation. If almost nothing is uncertain and the requirements are fixed, a plan-driven approach may cost less. The output is a short statement of which uncertainties the first few cycles should reduce. The agile vs waterfall skill gives a structured way to make this call.

2. Form a small cross-functional team with one product owner Put together the people needed to take an idea to working software without waiting on other groups. The Scrum Guide describes a team of "typically 10 or fewer people" and a Product Owner who is "one person, not a committee" (Scrum Guide). One accountable owner of priorities prevents the backlog from being pulled in several directions at once. Agree who that person is and which decisions the team can make without escalation.

3. Build and order the product backlog Collect the work into one list, written as outcomes users care about, and order it so the most valuable item is at the top. Keep the items near the top small and clear, and let items further down stay rough. The Agile Alliance describes refinement as reviewing the backlog so that "the items at the top of the backlog are ready for delivery" (Agile Alliance, Backlog Refinement). A backlog nobody can rank is a sign the product goal is unclear.

4. Choose a cadence or a flow model Decide whether the team works in fixed timeboxes or in continuous flow. Scrum uses Sprints that are "fixed length events of one month or less" (Scrum Guide). Kanban has no sprints and instead asks the team to "explicitly control the number of work items in a workflow" (Kanban Guide). Timeboxes suit planned product work, and flow suits work that arrives unpredictably, such as support or operations.

5. Plan each cycle around a goal Start each cycle by agreeing on why it is valuable, what can be finished, and how. Those are the three Sprint Planning topics in the Scrum Guide. Pick backlog items that serve the goal and fit the team's recent pace, and leave room for the unexpected. The output is a goal every team member can state and a visible list of the work behind it.

6. Coordinate daily and keep work visible Hold a short daily standup where the team checks progress toward the goal and adjusts its plan. The Scrum Guide sets the Daily Scrum at "a 15-minute event for the Developers" and leaves its structure to the team (Scrum Guide). Keep a board that shows every item in progress so bottlenecks are obvious. If the daily standup in your agile team turns into status reports to a manager, the coordination has stopped.

7. Review the increment with stakeholders At the end of each cycle, show working software to the people who will use or pay for it and ask what should change. The Scrum Guide calls the Sprint Review "a working session" and says the team "should avoid limiting it to a presentation" (Scrum Guide). Show what did not work as well as what did. Leave with changes to the backlog, because feedback that changes nothing was not needed.

8. Reflect, adjust, and repeat Close the loop with a retrospective on how the team worked, then pick one or two changes to try in the next cycle. Check at the next retrospective whether the change helped. Over several cycles, adjust the process itself: meeting lengths, cadence, board columns, even the choice between Scrum and Kanban. This is the twelfth principle in practice.

Agile vs Waterfall and Other Approaches

Agile sits at the level of values. Scrum and Kanban are frameworks that put those values into practice, and scaling frameworks coordinate many agile teams. Waterfall is the plan-driven alternative agile is usually compared with. Hamster's catalog covers Scrum, Kanban and Waterfall as separate methods.

Kniberg and Skarin's comparison of Scrum and Kanban makes a point that applies to the whole table: "There is no such thing as a good or bad tool", only decisions about when and how to use one (Kanban and Scrum).

When to Use

• You are building something new and customer needs are uncertain. Short cycles let the team test its assumptions with working software before committing months of effort to them.
• The market, technology or regulation around the product is changing during the project. An ordered backlog and frequent planning let the team re-prioritize without abandoning its process.
• You can form a small, stable, cross-functional team with one person who owns priorities. The Manifesto's principles of daily collaboration and self-organization assume such a team exists.
• You are running and evolving a live product with a steady stream of feedback, bugs and requests. Agile planning cycles give that stream a regular point where it is ranked against planned work.
• Leadership is willing to fund outcomes and let the team change what it builds. Agile needs room to act on what each review teaches.

When Not to Use

• Requirements are fixed, well understood and unlikely to change, such as reproducing a published calculation exactly. Iterating to discover requirements adds cost when there is nothing left to discover.
• Every decision needs sign-off from groups outside the team. Short cycles stall at approval gates, and the team ends up waiting for most of each sprint.
• Leadership mandates agile ceremonies without giving teams authority over how they work. Fowler's warning about process imposed from outside describes the likely result: rituals without the values.
• One person is doing well-scoped work alone. A simple task list or personal board captures the useful parts, and the team ceremonies have nobody to coordinate.