Agile vs Scrum: The Mindset and One Way to Do It

Agile and Scrum are not rivals; one sits inside the other. Agile is a set of four values and twelve principles for building things in short cycles and adapting as you learn, written down in the 2001 Manifesto for Agile Software Development. Scrum is one framework that puts those ideas into practice, with fixed roles, events and artifacts. Every Scrum team is trying to be agile, but plenty of agile teams do not use Scrum: they use Kanban, Extreme Programming, or a light cadence of their own. So the useful question is rarely “agile or Scrum?” It is “is Scrum the right way for this team to be agile?”

Agile: values, not a process

The Manifesto for Agile Software Development↗ (opens in a new tab) is four lines long, and each line is a preference, not a rule:

• “Individuals and interactions over processes and tools”
• “Working software over comprehensive documentation”
• “Customer collaboration over contract negotiation”
• “Responding to change over following a plan”

It ends: “while there is value in the items on the right, we value the items on the left more.” Twelve principles follow, such as delivering working software frequently and reflecting at regular intervals on how to become more effective. None of them names a meeting, a role or a tool. The Agile Alliance↗ (opens in a new tab) sums agile up as “the ability to create and respond to change.” What is agile covers the meaning in full.

Scrum: one framework, with rules

Scrum is far more specific. The Scrum Guide↗ (opens in a new tab) defines it as “a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems,” and then sets rules: a Scrum Team with a Product Owner, a Scrum Master and Developers; Sprints of one month or less; four events inside each Sprint; three artifacts with a commitment each. What is Scrum explains the pieces, and the Scrum Guide, summarized separates what the Guide requires from what teams add.

The two are closely related by history as well as idea: Ken Schwaber and Jeff Sutherland, who wrote the Scrum Guide, are both among the seventeen signatories of the Agile Manifesto.

The difference between agile and Scrum, side by side

• What it is. Agile: a philosophy, four values and twelve principles. Scrum: a framework with defined accountabilities, events and artifacts.
• Source. Agile: the 2001 Manifesto and its principles. Scrum: the Scrum Guide, current edition November 2020.
• Rules. Agile: none; it states preferences. Scrum: a short list of rules, and the Guide says implementing only parts of it means “the result is not Scrum.”
• Roles. Agile: none named. Scrum: Product Owner, Scrum Master and Developers.
• Cadence. Agile: “frequently”, with a preference for the shorter timescale. Scrum: fixed Sprints of one month or less, back to back.
• Scope. Agile: a stance you can apply to almost any work. Scrum: built for complex product work by a small team.
• How you know you are doing it. Agile: you deliver often, learn from it and change course. Scrum: the events happen within their timeboxes and the artifacts meet their commitments.

Scrum vs agile: four common confusions

• “We are agile because we hold standups.” A meeting is a practice. If the plan never changes after the standup, the team is following a ritual, not responding to change.
• “Agile means Sprints.” Sprints are Scrum’s. Kanban teams work in continuous flow and are just as agile.
• “Agile means no plan.” The manifesto values responding to change over following a plan; it does not say plans have no value. Scrum plans every Sprint.
• “Scrum is a methodology.” The Guide calls it a framework and says it is “purposefully incomplete”: it leaves the techniques to you.

Kanban: the other common way to be agile

Kanban is the main alternative to Scrum for small teams. The Kanban Guide↗ (opens in a new tab) defines it as “a strategy for optimizing the flow of value through a process,” built on three practices: defining and visualizing a workflow, actively managing the items in it, and improving it. It names no roles and no events; what it does require is explicit control of work in progress. What is Kanban explains the method, and Kanban vs Scrum compares the two head to head.

There are others. Extreme Programming focuses on engineering practices such as pairing and test-first development, and Scrumban mixes Scrum’s cadence with Kanban’s flow; project management methodologies lines them all up.

Pick by situation

Agile is the stance you take in every case below. The choice is which way of working carries it.

• You build a product with a roadmap, stakeholders want to see progress on a rhythm, and you can plan two to four weeks ahead: Scrum.
• Most work arrives unplanned, such as support tickets, fixes and client requests: Kanban. A Sprint plan torn up every week helps nobody.
• You are two or three people: start with Kanban or a light weekly cadence. Scrum’s accountabilities assume enough people to fill them.
• The team keeps starting work and not finishing it: Kanban, with a limit on work in progress before anything else.
• The team rarely agrees on what matters this month: Scrum. Agreeing on a Sprint Goal forces the conversation.
• Some of the work is done by AI assistants that pick up tasks as they come: Kanban fits more naturally, because it is about the flow of items rather than a team’s shared rhythm.
• Scope, budget and date are fixed by contract and unlikely to change: you may not want an agile approach for the whole project. Agile vs waterfall covers when a sequential plan wins.

1. Can you plan the next 2-4 weeks and expect the plan to mostly hold?
   no  -> Kanban (visualize the flow, limit work in progress)
   yes -> go to 2

2. Do you have a product owner, enough people for a team,
   and stakeholders who want a regular review?
   yes -> Scrum (Sprints, the five events, the three artifacts)
   no  -> Kanban now; add a planning and review rhythm later (Scrumban)

Either way: deliver often, look back regularly, change what is not working.
That last line is the agile part.

Being agile on a simple board

fenbs is kanban-style: a board has four fixed lanes, To Do, Next Up, In Progress and Completed, and no sprints, story points or velocity chart. The agile habits still have a place to land. Each task has a note for the problem, a plan for how it will be done, and a test status with test notes, so “working software” is checked rather than claimed. History records who changed what, including which AI assistant moved a task. And a team that decides to change how it works can record that on the Decisions and rules page, where a rule holds from now on and every connected assistant reads it first. If you run Scrum by the book with burndown charts and Sprint reports, a dedicated Scrum tool will suit you better.