Agile Methodologies

Almost every product team now says it works in an agile way, and almost no two of them mean the same thing by it. The difference lies in the methodology: the specific set of roles, events, and rules a team adopted, borrowed from, or quietly stopped following. Knowing which methodology a team actually runs explains more about its week than the word agile does, which is why designers and product managers joining a team benefit from asking that question first.

What are Agile methodologies?

Agile methodologies are the named, documented ways of working that put the values of the Agile Manifesto into practice: Scrum, Kanban, Extreme Programming, Lean software development, Crystal, Feature-Driven Development, Dynamic Systems Development Method, and the scaling frameworks that coordinate many teams at once. Each one answers the same questions differently: who decides what gets built next, how long a cycle of work lasts, what the team produces at the end of it, and how it learns from the result.

The plural matters. There is no single Agile methodology, and the Manifesto does not describe one. Several methods predate it: Scrum was presented at a conference in 1995, Extreme Programming took shape in the late 1990s, and DSDM was published in 1994. The 2001 meeting that produced the Manifesto brought their authors together to name what they had in common. A methodology is one family member's answer to the Manifesto, never the Manifesto itself.

How does a methodology differ from Agile itself?

Agile is a set of values and principles. The Agile Manifesto states four value pairs, such as responding to change over following a plan, and twelve principles behind them. It names no roles, no meetings, and no artifacts, and a team can honor all of it without ever holding a standup.

A methodology is a specific set of roles, events, artifacts, and rules that claims to honor those values. Scrum says there is a Product Owner; the Manifesto says nothing of the kind. Kanban says work in progress has a limit; the Manifesto only asks for a sustainable pace. The values are the test, and the methodology is one way of passing it, so a team can follow a methodology to the letter and still fail the test, or pass it with a process nobody has named.

What are the main Agile methodologies?

Scrum is the most widely adopted. Work happens in fixed-length sprints of one month or less, each producing a usable increment. The Scrum Guide defines three accountabilities (Product Owner, Scrum Master, Developers), five events (the sprint, sprint planning, the daily scrum, the sprint review, the retrospective), and three artifacts (product backlog, sprint backlog, increment).

Kanban has no sprints at all. Work flows continuously across a visual board, each column has a limit on how many items it may hold, and the team pulls the next item only when capacity frees up. It measures lead time and throughput rather than velocity, and it changes an existing process gradually instead of replacing it on a start date.

Extreme Programming, or XP, is the engineering-heavy member of the family. Kent Beck's method prescribes practices rather than meetings: pair programming, test-driven development, continuous integration, small releases, refactoring, and an on-site customer who answers questions as the code is written. Lean software development, adapted by Mary and Tom Poppendieck from Toyota's manufacturing system, is a set of principles rather than a process: eliminate waste, build quality in, decide as late as possible, deliver as fast as possible, and see the whole.

Above the single team sit the scaling frameworks. The Scaled Agile Framework is the largest and most prescriptive, adding release trains, planning intervals, and portfolio management on top of team-level Scrum or Kanban; Large-Scale Scrum, Nexus, and Scrum@Scale do the same job with less added structure. The methods differ most in how much they prescribe, from XP's engineering practices at one end to Kanban's deliberate minimum at the other.

How do teams choose and combine them?

The choice follows the shape of the work. Work that arrives in plannable batches with a clear end state, such as a feature release, suits a sprint-based method where the team commits to a scope and delivers it. Work that arrives continuously and unpredictably, such as support, operations, or a platform team serving many requesters, suits flow-based Kanban, where a two-week commitment would be fiction by Wednesday. Teams with a fragile codebase and a high cost of defects add XP's engineering practices whatever rhythm they plan in.

In practice most teams combine. Scrumban keeps Scrum's planning and review rhythm but replaces the sprint commitment with Kanban's WIP limits and pull system, and many Scrum teams run XP practices inside their sprints without calling them XP. Hybrids are the normal state, not a compromise, because the methods were designed by different people for different problems and were never meant to be exclusive. The Agile Practices lesson sets the main frameworks side by side and works through when each fits.

What does an Agile methodology look like in practice?

Kanban is the method whose mechanics are easiest to see, because the board is the method. Columns stand for stages, cards for items, a number at the top of each column caps how many cards may sit in it, and a card moves right only when the next stage has room. The limit is what turns a to-do list into a method: without it the board only records where work is, and with it the board forces the team to finish before starting.

The Kanban framework as a board: each column is a stage, each card an item, and the numbers on Doing and Review are the work-in-progress limits that keep items flowing instead of piling up. From the lesson Agile Methodologies.

What do Agile methodologies mean for designers and product managers?

Each method gives design a different place. In Scrum, design that must exist before a story can be built tends to run one sprint ahead of development, with designers shaping the next sprint's items while the current one is under way. The risk is a miniature waterfall inside each sprint pair, and the usual remedy is treating sprint planning as the moment design evidence has to be in the room.

In Kanban, design is a lane on the same board with its own WIP limit, and nothing waits for a sprint boundary, which suits continuous discovery but makes design debt easy to defer. In XP the designer sits closest to the on-site customer role, answering questions as the code is written rather than handing over a finished spec. The method decides when design gets to influence the work, not whether it does, and that timing is the variable worth negotiating.

For product managers the difference is ownership. Scrum gives the Product Owner sole authority over the backlog; Kanban has no such role, so prioritization is agreed through policies on the board; scaling frameworks split the job across levels. The How UX Can Adopt Agile lesson covers the working arrangements for design and product in each rhythm.

What are the common misreadings of Agile methodologies?

The first is mistaking the ceremony for the method. A team that holds a standup, a planning session, and a retrospective every two weeks has adopted Scrum's calendar, not Scrum; the method lives in the commitment, the increment, and the inspection of both. The second is "doing Agile" versus being agile: running every event in the Scrum Guide and never changing a plan in response to what was learned.

The third is waterfall with sprints: requirements fixed up front, sprints used to schedule the build, and a review that shows progress toward a plan nobody may question. It looks like Scrum from outside and behaves like the process the Manifesto was written against. Every misreading keeps the vocabulary and drops the feedback loop, so the test of a methodology is not how many events a team holds but how often something changes because of them. Continuous backlog grooming, where new evidence reorders the work, is usually the first thing a misread methodology stops doing, and restoring it is where most agile transformations begin.