Agile is a set of values and principles for doing project work in short cycles with frequent feedback, written down in 2001 for software development and since applied well beyond it. Scrum is one specific framework for working that way, with defined roles, meetings, and a fixed-length iteration called a sprint. The relationship is nesting, not competition: every Scrum team is an Agile team, but an Agile team might use Scrum, the Kanban Method, Extreme Programming, or a homegrown mix. "Agile vs. Scrum" is a comparison people search for, so this page answers it, but the useful decision underneath it is Scrum vs. Kanban, and both of those grew out of the same Lean thinking that runs the rest of this site.
What Agile is
In 2001, seventeen software practitioners published the Manifesto for Agile Software Development: four value statements and twelve principles. The values:
- 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 manifesto notes that the items on the right have value; the items on the left have more. The principles add the mechanics: deliver working output frequently in short cycles, welcome changing requirements, have the people doing the work and the people who need it talk daily, build around motivated self-organizing teams, and reflect regularly on how to become more effective. Agile is the orientation. It does not tell you how to run a meeting or how long a cycle is.
The alternative Agile was reacting against is usually called waterfall: define everything up front, build it all, test it at the end, deliver once. Waterfall works when requirements are stable and well understood. It fails when they are not, which in product development is most of the time.
What Scrum is
Scrum is a framework for Agile work, defined in the Scrum Guide maintained by its creators, Ken Schwaber and Jeff Sutherland. It is deliberately small: a few roles, a few events, a few artifacts, and the rules that connect them.
Accountabilities
- Product Owner. Owns the product backlog: what gets built and in what order, based on value to the customer and the business.
- Scrum Master. Coaches the team on the framework, removes obstacles, facilitates the events. A servant-leader and process owner, not a project manager.
- Developers. Everyone who does the work of producing the increment. Cross-functional and self-managing; in Scrum the team decides how much it can take on and how to do it.
Events
- The Sprint. A fixed-length iteration of one month or less (two weeks is most common) in which a usable increment is produced. Sprints run back to back; the sprint is the container for the other four events.
- Sprint Planning. The team selects backlog items for the sprint, sets a sprint goal, and plans the work.
- Daily Scrum. Fifteen minutes, same time and place, Developers only: what is the plan for the next 24 hours, what is in the way.
- Sprint Review. The team shows the increment to stakeholders and gets feedback that shapes the backlog.
- Sprint Retrospective. The team examines how it worked and picks improvements for the next sprint.
Artifacts
- Product Backlog. The ordered list of everything that might be built.
- Sprint Backlog. The items selected for this sprint plus the plan to deliver them.
- Increment. The usable, done work at the end of the sprint, meeting an agreed definition of done.
Backlog refinement (clarifying and sizing upcoming items) happens continuously but is not a formal event.
So what is the difference?
| Agile | Scrum | |
|---|---|---|
| What it is | A philosophy: values and principles | A framework: roles, events, artifacts, rules |
| Prescribes | What to value and why | How to organize the work week to week |
| Iteration | "Short cycles," unspecified | Sprints of one month or less, fixed length |
| Roles | None defined | Product Owner, Scrum Master, Developers |
| Meetings | None defined; "daily conversation" is a principle | Five events with set purposes and time limits |
| Relationship | The umbrella | One thing under it, alongside Kanban, XP, and others |
You cannot choose Agile instead of Scrum any more than you can choose Lean instead of 5S. If a team is "doing Agile" without Scrum, it is using some other framework or none, which is a legitimate choice but a different one.
The real choice: Scrum or Kanban
The two most used Agile frameworks are Scrum and the Kanban Method (the knowledge-work adaptation of manufacturing kanban). They differ in how they regulate the flow of work.
| Scrum | Kanban Method | |
|---|---|---|
| Cadence | Fixed sprints; work is batched and committed per sprint | Continuous flow; items pulled one at a time as capacity frees |
| Flow control | The sprint commitment limits how much is in progress | Explicit work-in-progress limits per column |
| Roles | Three defined | None required; keep existing roles |
| Change during the cycle | Sprint scope is protected; new items wait for the next sprint | Items can be reprioritized at any time; only the WIP limit is fixed |
| Metrics | Velocity (work completed per sprint) | Lead time, cycle time, throughput |
| Adoption | Revolutionary: install the framework | Evolutionary: start with what you do now, visualize it, limit WIP, improve |
| Fits | Product and project work with a team that can commit to a plan for two weeks | Request-driven work with unpredictable arrivals: support, maintenance backlogs, improvement follow-ups |
Many teams run a hybrid: a Scrum cadence of planning and reviews with a Kanban board and WIP limits inside the sprint. The Scrum Guide itself is compatible with that.
How this connects to Lean
Agile did not come from nowhere. Scrum's name and core idea trace to a 1986 Harvard Business Review article by Takeuchi and Nonaka on Japanese product development teams (Honda, Canon, Fuji-Xerox) that worked as overlapping, self-organizing units rather than in sequential handoffs, which the authors compared to a rugby scrum. Those companies were practicing the same management philosophy as the Toyota Production System. Mary and Tom Poppendieck's Lean Software Development (2003) made the mapping explicit, and the Kanban Method borrowed its name and mechanism directly. The correspondences:
| Lean | Agile / Scrum / Kanban |
|---|---|
| PDCA | The sprint: plan, do, review, retrospect |
| Kaizen and the retrospective habit | Sprint Retrospective; "reflect regularly" principle |
| Pull and WIP limits | Kanban Method WIP limits; sprint commitment |
| Small batches, short lead time | Short iterations, frequent delivery |
| Daily huddle at the board | Daily Scrum |
| Visual management | The task board, burndown chart |
| Standard work, then improve | Definition of done; working agreements |
| Respect for people, self-managing teams | Self-organizing Developers; Scrum Master as facilitator not boss |
| Eliminating waste | Working output over documentation; just-in-time requirements |
A plant that runs Lean on the floor and Scrum or Kanban in engineering, IT, or the continuous improvement office is running one philosophy in two vocabularies.
Where it fits in a manufacturing company
Scrum and the Kanban Method are for project and knowledge work, not for repetitive production, which has its own Lean tools. Inside a manufacturing business they apply to:
- Product and process engineering. New product development, tooling design, process changes; the work Takeuchi and Nonaka were describing.
- IT and systems. ERP changes, MES, plant software.
- The improvement program itself. A continuous improvement office with a backlog of kaizen events, 5S rollouts, and projects is a Kanban Method candidate: visualize the backlog, limit how many are in flight (see scope creep), track lead time.
- Maintenance and facilities backlogs. Request-driven, unpredictable, high in WIP: the Kanban Method's home ground.
A sprint-based cadence with a review and retrospective is also a reasonable way to run a multi-month rollout that is too long for a single event and too fluid for a fixed Gantt chart.
Frequently asked questions
Is Scrum the same as Agile?
No. Agile is the set of values and principles; Scrum is one framework for putting them into practice. All Scrum is Agile; not all Agile is Scrum.
Should I choose Agile or Scrum?
The question is malformed. Choose whether to work in an Agile way at all, and then choose a framework: Scrum, the Kanban Method, or a hybrid. That is the decision with trade-offs.
How long is a sprint?
One month or less, fixed for the team. Two weeks is the most common length.
What is the difference between Scrum and Kanban?
Scrum batches work into fixed sprints with defined roles and events. The Kanban Method is continuous flow with explicit WIP limits and no required roles. Scrum suits planned product work; Kanban suits request-driven work with unpredictable arrivals.
Is Agile a Lean method?
It is a close relative. Scrum and the Kanban Method both trace to Japanese product development and the Toyota Production System, and Lean software development made the connection explicit. Short cycles, pull, small batches, daily huddles, visual boards, and retrospectives are Lean practices under Agile names.
Can Scrum be used outside software?
Yes, and it was conceived from non-software work. It is used in product development, marketing, research, construction planning, and operations improvement. It does not apply to repetitive production, where standard work and kanban replenishment do the job.
Related resources
The Lean side of these ideas is on the Lean manufacturing, kaizen, and kanban pages; the project planning tools they sit beside are project timelines, Gantt charts, and scope creep control. The canonical sources are the Agile Manifesto and the Scrum Guide; for Lean's own account of the relationship, the Lean Enterprise Institute's What is Lean? is the starting point.