What is agile methodology
Agile is not a process, it is a set of values about dealing with uncertainty. Scrum, Kanban and XP are methods that try to put them into practice, and they are not the same thing.
The first imprecision is the name. "Agile methodology" in the singular does not exist: what exists is a set of values published in 2001 in the Manifesto for Agile Software Development, and a family of methods that declare themselves aligned with it.
That distinction is not pedantry. It is what separates a team that adapts its own process from a team following a ritual because someone said that is how it is done.
Individuals and interactions
over processes and tools.
Working software
over comprehensive documentation.
Customer collaboration
over contract negotiation.
Responding to change
over following a plan.
The part of the manifesto almost everyone forgets
The four values above end with a sentence usually cut from the quote: "that is, while there is value in the items on the right, we value the items on the left more".
That changes everything. The manifesto never said to abandon documentation, plans, process or contracts. It said not to sacrifice the outcome in their name. The popular reading, "agile means not documenting", inverts the original text.
Beyond the four values, the manifesto carries twelve principles, among them delivering value frequently, welcoming changing requirements even late in development, and maintaining a sustainable pace indefinitely.
Scrum, Kanban and XP: what differs
Scrum organizes work into fixed-length sprints, with three accountabilities (Product Owner, Scrum Master and Developers) and defined events: planning, daily meeting, review and retrospective. It is the most adopted method, and also the most frequently applied only on the surface.
Kanban requires neither iterations nor roles. It visualizes the flow, limits work in progress and evolves the existing process incrementally. It serves well when demand is unpredictable and does not fit into closed cycles.
Extreme Programming (XP) focuses on technical practices: pair programming, test-driven development, continuous integration and constant refactoring. It is the method that says the most about how code is written, not only about how work is organized.
What became folklore
"Agile means going faster." It does not. Agile means shortening the interval between a decision and feedback on it. Agile teams frequently deliver less scope per cycle, they just find out sooner which scope mattered.
"The daily meeting is for reporting status to the manager." Its purpose is for the team to sync the day's plan and surface impediments. When it becomes accountability theater, it loses its function and turns into a fifteen-minute tax.
"Agile means no planning." The manifesto says to respond to change over following a plan, which presupposes a plan exists. The difference is treating it as a revisable hypothesis rather than an immutable commitment.
How to tell whether it is working
The best test is not how many ceremonies the team runs, but how much time passes between someone having an idea and that idea reaching whoever uses it. If that interval has not shrunk, the rituals are running with no effect.
The second test is the retrospective: if the actions agreed there change something in the following cycle, the process is alive. If they repeat quarter after quarter, the team is recording frustration, not improving.
Frequently asked questions
- Is agile methodology the same as Scrum?
- No. Agile is a set of values and principles published in the Agile Manifesto in 2001. Scrum is a specific framework that seeks to implement them, with fixed-length sprints, defined accountabilities and events. Kanban and XP are other methods aligned with the same values, making quite different choices.
- Does agile work for non-software teams?
- The values and principles apply well to any work with high uncertainty, marketing, product, research, operations. What usually does not transfer well are XP's technical practices, which presuppose code. It is worth adopting the reasoning and adapting the practices, rather than importing whole rituals.
- Which method should I start with?
- If the team's demand arrives unpredictably and a process already exists, Kanban tends to be the gentler start, because it does not require reorganizing roles. If there is scope worth protecting for a few weeks and a product with a defined direction, Scrum gives more structure. Many teams end up hybrid, and that is not a problem.
- Does agile work with a distributed team?
- It does, but it requires compensating for the context physical presence gave away for free. In practice that means documenting decisions accessibly, keeping rituals at fixed times and reducing dependence on synchrony, otherwise the team trades collaboration for an excess of meetings.
Keep reading
- What is KanbanKanban is a workflow management method that makes work visible and limits how much is done at once. The board is the visible part; the limit is the part that works.
- Project management without scattering the work across five toolsKanban, Gantt scheduling, dependencies, dashboards and the project inbox in one place. Workspacefy brings together what normally takes four separate subscriptions.
- What is an OKROKR is a goal-setting method that separates where you want to get to (the objective) from how you will know you got there (the key results). The most common mistake is confusing a key result with a task.
- Team management when nobody sits in the same roomVisible workload, rituals that take real room on the calendar, and all the context in the same place the work happens.
A workspace that follows the method, not the other way around
Kanban with WIP limits for continuous flow, timeline with dependencies for dated scope, on the same task collection.
Start free