Introduction to Classical Agile: Scrum and Kanban

What is Agile?

If you've ever been part of a project that spent months building something, only to discover at launch that the market had moved on or customers wanted something completely different, you'll understand why Agile exists. I've seen this happen more times than I'd like to admit, and it's painful every single time. (I've written about and how my thinking has evolved over the years, from following frameworks religiously to finding what actually works.)

Agile is fundamentally about learning fast and adapting quickly. Instead of betting everything on one massive release, you break work into chunks you can actually ship and get feedback on. Multiple checkpoints where you can course-correct, rather than driving blindly toward a destination that might not exist anymore.

Here's what I find most interesting: Agile isn't a set of rules. There's no Agile police checking whether your standups are done right. The is four sentences of priorities, not process:

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

Those preferences still leave room for documentation, tools, contracts, and plans. The question is whether they're helping people do useful work and learn from it.

Scrum gives a team a regular rhythm for setting goals and inspecting progress. Kanban makes the movement and accumulation of work explicit. Both can support frequent releases, and plenty of teams benefit from using them together. That is a more useful distinction than deciding which one gets to call itself more Agile.

The example below lets you try both. Release an increment before the Sprint Review, then switch to Kanban and see what happens when a review queue fills up. The team, work items, days, and limits are fictional.

Scrum: a shared rhythm

I get asked all the time whether Scrum and Agile are the same thing. Agile is the philosophy, the why. Scrum is one way to put it into practice, with enough structure to make the feedback loops hard to forget. You can adapt the techniques you use within it. If you remove parts of the framework, be clear that you're borrowing from Scrum rather than describing the whole thing. ¹

Scrum builds on two ideas. Empiricism: decide based on what you observe, not what you assumed three months ago. And lean thinking: cut what doesn't contribute. The framework admits upfront that you don't know everything at the start, and its whole structure (short cycles, frequent reprioritization, constant inspection) exists to make that admission safe.

The team

A Scrum team is intentionally small, typically ten people or fewer, and I've found the best ones are five to seven. The current guide calls these three accountabilities within one team:

• Product owner: accountable for product value and an ordered, understandable backlog. Keeping that list useful is harder than it sounds. One critical rule I've learned the hard way: you need exactly ONE product owner. Teams get whiplash when multiple people fill this role with conflicting priorities. Product owner and product manager can be the same person, but the responsibilities aren't interchangeable. Who authorizes a production release depends on the organization.
• Scrum master: a coach who helps the team become effective and ensures its events happen productively. Facilitating a meeting can help; owning every meeting can make the team dependent on them.
• Developers: everyone creating the increment, including designers, testers, and other specialists. They plan and manage their own work. Cross-functional means the team collectively has the skills it needs; it doesn't mean every person can do every job.

What makes these teams work is ownership. The team agrees what "done" means while respecting any organizational quality standards. Giving a team that much autonomy feels risky the first time, but what I've consistently observed is that trusted teams exceed what anyone thought was possible. That trust also needs room for honest forecasts and a sustainable pace.

The artifacts

Three shared pieces of information keep everyone aligned:

• Product backlog: the evolving work needed to improve the product, guided by a Product Goal. Items that felt critical last month can become irrelevant this month as the team learns.
• Sprint backlog: the Developers' plan around a Sprint Goal. Selected items are a forecast. Scope can be renegotiated with the product owner as more is learned, without endangering that goal.
• Increment: usable work that meets the Definition of Done. It can be released during the Sprint; the Sprint Review is never a release gate. ¹

That last point matters in practice. A team can have a two-week planning rhythm and release several times a week. Waiting for a calendar boundary adds delay unless there is a reason the product needs it.

The events

Scrum's meetings have a bad reputation, and honestly, some of it is earned. My advice is to get clear on what each event should change about the team's next decision. If the answer is "nothing", investigate the format, who participates, and whether anyone can act on what comes up.

1. Sprint planning: agree why this Sprint is valuable and make a realistic plan for it. Everyone should understand the goal and what currently looks achievable.
2. The daily scrum: fifteen minutes for Developers to inspect progress toward the Sprint Goal and adapt their plan. When it degrades into people reading their calendars aloud (and it will), change the format rather than abandoning it.
3. Sprint review: work with stakeholders to inspect results and decide what to do next. A demo can help that conversation, but save time for the things everyone learned and what they mean for the product.
4. Retrospective: the team inspects itself rather than the product: what to keep, what to drop, what to try. Skipping retros is how process debt accumulates.

Alongside the events runs backlog refinement (you may know it by its older name, grooming): breaking down and clarifying work as the team learns. It isn't a formal Scrum event. I find it more useful to think of it as an ongoing habit than to assume one meeting will keep the backlog healthy.

The values

Scrum names five values: commitment, courage, focus, openness, and respect. That can sound like poster material. The useful questions are more personal: can we tell each other a plan isn't working? Can someone ask for help without looking weak? Do we support the shared goal when our own task is blocked? The mechanics are easier to use when those answers are yes.

Kanban: make the flow visible

While Scrum dominates the Agile conversation, Kanban has quietly become one of my favorite approaches for certain teams. Its roots reach back to Toyota's production system, long before software. The appeal for me is the attention it puts on work that has started but hasn't yet delivered anything.

You can start from the workflow and responsibilities you already have. There are three connected practices: define and visualize the workflow, actively manage the work moving through it, and improve that workflow. A board helps, but it needs agreements about what the team does when work gets stuck. ²

The board and the cards

Start with your actual workflow. To Do, In Progress, Done may be enough; Review or Ready for QA may make an otherwise invisible wait easier to see. Each work item needs enough context for the team to understand what it is and where it's stuck.

Then make the policies explicit: what counts as started and finished, what lets an item move, how you control work in progress, and what delivery expectation the team uses. "Done" might mean ready for release or already in production. Decide which, because the distinction changes what your measurements tell you.

WIP limits turn waiting into a shared problem

Work-in-progress limits make the cost of starting visible. Having more work open can bring more context switching and longer waits, especially when it all queues for the same person or review step. Limits give the team a reason to look at finishing before reaching for the next item.

A concrete example: cap Review at two items. When it fills, a third item cannot enter Review. That alone doesn't block the whole board; another stage might still have capacity. The team can also agree to help clear reviews before pulling more work. The number is an experiment in this example, not a universal recommendation.

This is where a useful conversation starts. Is the reviewer unavailable? Are changes too large? Are we waiting for a decision outside the team? A limit exposes the queue. The people still have to resolve it.

Four flow measures help you see what is happening:

• WIP: items started and not yet finished.
• Throughput: items finished per unit of time.
• Work-item age: how long a currently unfinished item has been in progress.
• Cycle time: elapsed time from the agreed start to the agreed finish of a completed item.

Use historical cycle times to make an expectation with a probability attached. For example, a fictional team might say, "85% of comparable items finish within eight days." That is a forecast to revisit, not a promise about every item. Age helps the team notice current work at risk of exceeding it. ²

Kanban works well alongside continuous delivery, but it doesn't prescribe a release schedule. The interesting question is how much waiting your workflow creates between an idea and something useful reaching a customer.

Picking between them

After working with both, I've stopped treating this as a choice of identities. I ask what the team needs help seeing or deciding:

Support work, roadmap work, and platform work can all benefit from inspecting flow. A product team can also keep a Sprint Goal while using WIP limits and item age to manage its work. Neither a Sprint nor a board removes the need to negotiate interruptions.

The failure mode I've seen in both is following the mechanics while ignoring what they reveal. The useful part begins when the team changes something because of what it learned.

Where to go next

This post is the first of a three-part series on classical Agile. The second covers : sprint burndowns, velocity, cycle time, and the anti-patterns hiding in each. The third covers , a Toyota-born practice for making continuous improvement an actual habit rather than a retro bullet point.

For a closer reading, the is short enough to read with your team; pay particular attention to the Sprint Goal and the meaning of an increment. The is a useful companion when agreeing workflow policies and choosing which flow measures to use.