- Introduction
- 1. What Is Agile
- 2. Scrum in Detail
- 3. Kanban in Detail
- 4. Scrum vs Kanban
- 5. Estimation
- 6. Anti-Patterns — Fake Agile
- 7. Adoption Guide
- Conclusion
- References
Introduction
Almost every team has heard the phrase "we work in an agile way." Yet when you look closely, the daily check-in meetings drag on, sprints never seem to finish, and retrospectives slide into a formality. The word agile is familiar, but surprisingly few people can clearly explain what Scrum and Kanban are and how they differ.
This article starts from the root — the Agile Manifesto and its 12 principles — and then compares the two flagship frameworks, Scrum and Kanban, from a practical standpoint. It walks through roles, events, artifacts, WIP limits, and estimation, and then covers the fake-agile anti-patterns teams often fall into, along with a realistic adoption guide. The goal is not to memorize tools or meeting names, but to understand why we work the way we do.
1. What Is Agile
The Agile Manifesto
In 2001, seventeen software developers gathered in Snowbird, Utah, and published the Manifesto for Agile Software Development. Born from a reflection on heavyweight, document- and plan-driven traditional development, the manifesto lays out four values.
The four values of the Agile Manifesto
Over processes and tools ──▶ Individuals and interactions
Over comprehensive docs ──▶ Working software
Over contract negotiation ──▶ Customer collaboration
Over following a plan ──▶ Responding to change
"While there is value in the items on the left,
we value the items on the right more."
The most common misreading here is to think the left-hand items should be discarded. Documentation matters and planning matters. The manifesto is a statement of priority: when forced to choose between the two, lean toward the right.
The 12 Principles of Agile
Behind the manifesto sit twelve principles that make it concrete. You do not need to memorize them all, but grouped by theme they look like this.
- Customer satisfaction and value delivery: Satisfy the customer through early and continuous delivery of valuable software.
- Welcome change: Welcome changing requirements, even late in development; change creates competitive advantage for the customer.
- Short delivery cycles: Deliver working software frequently, favoring shorter timescales from a couple of weeks to a couple of months.
- Collaboration: Business people and developers work together daily throughout the project.
- Motivated people: Build projects around motivated individuals, give them the environment and support they need, and trust them.
- Face-to-face conversation: The most efficient way to convey information is a face-to-face conversation.
- Working software is the measure of progress: Running results, not document volume, indicate how far along you are.
- Sustainable pace: A constant pace you can sustain indefinitely, not heroic overtime.
- Technical excellence: Continuous attention to good design and technical excellence enhances agility.
- Simplicity: The art of maximizing the amount of work not done is essential.
- Self-organizing teams: The best architectures and designs emerge from self-organizing teams.
- Regular reflection and improvement: At regular intervals, the team reflects on how to become more effective and adjusts accordingly.
Compressed into one sentence: "Deliver in small increments often, get fast feedback, and keep improving." Scrum and Kanban are two different concrete methods for putting that philosophy into practice.
2. Scrum in Detail
Scrum is the most widely used agile framework. Built around the Sprint — a fixed-length iteration — it defines clear roles, events, and artifacts.
2.1 The Three Scrum Roles
A Scrum team is made up of three responsibilities. We often call them "roles," though the latest Scrum Guide describes them as accountabilities.
- Product Owner: Accountable for maximizing the product's value. Owns and orders the backlog and decides what to build. The owner of "What" and "Why."
- Scrum Master: A servant leader who helps Scrum work as intended. Removes impediments and coaches the team toward self-organization. A facilitator rather than a manager.
- Developers: The people who actually create the Increment. Includes developers, QA, designers — everyone who builds the result. They decide "How."
The ideal Scrum team size is usually ten people or fewer. Too large and communication cost balloons; too small and the team struggles to cover the needed skills.
2.2 The Sprint Cycle
A Sprint is a fixed period, usually one to four weeks. Within a single Sprint several events occur in a defined order.
Sprint cycle (2-week example)
┌──────────────────────────────────────────────────────┐
│ Sprint (2 weeks) │
│ │
│ Sprint Planning │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────┐ │
│ │ Day 1 ── Day 2 ── ... ── Day 9 ── Day 10 │ │
│ │ │ │ │ │ │ │
│ │ Daily Daily Daily Daily │ │
│ │ Scrum Scrum Scrum Scrum │ │
│ └─────────────────────────────────────────────┘ │
│ │ │
│ ▼ │
│ Sprint Review ──▶ Sprint Retrospective │
└──────────────────────────────────────────────────────┘
│
▼
Next Sprint starts
2.3 The Five Scrum Events
The Sprint itself is treated as an event, containing four further events.
- Sprint: The container for all activity. When one ends, the next begins immediately.
- Sprint Planning: The start of the Sprint. Decides "what, why, and how" to build this Sprint, and sets the Sprint Goal.
- Daily Scrum: A short, time-boxed check held within 15 minutes by the developers. Synchronizes progress and adjusts the plan toward the Sprint Goal. It is not a status report to a boss.
- Sprint Review: At the end of the Sprint, the completed Increment is demonstrated to stakeholders to gather feedback and inspect the product direction together.
- Sprint Retrospective: The final event. The team reflects on people, relationships, process, and tools — what went well and what to improve — and produces improvement items for the next Sprint.
The three classic questions often used in the Daily Scrum are these.
The traditional 3 questions of the Daily Scrum
1) What did I do yesterday?
2) What will I do today?
3) Is anything blocking the Sprint Goal?
Note: the current Scrum Guide does not mandate a format.
The point is "inspect progress toward the Sprint
Goal and adapt the plan."
2.4 The Three Scrum Artifacts
- Product Backlog: An ordered list of everything the product needs. Owned by the Product Owner and continuously refined.
- Sprint Backlog: The items selected for this Sprint plus the plan to deliver them. Owned by the developers.
- Increment: The result of the Sprint. A potentially releasable sum added to all prior increments.
Each artifact carries a commitment that increases transparency. The Product Backlog has the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done.
Backlog flow
Ideas / requirements
│
▼
┌───────────────┐ refinement ┌───────────────┐
│ Product │ ─────────────▶ │ Sliced and │
│ Backlog │ refine │ estimated │
│ (ordered) │ │ items │
└───────────────┘ └───────────────┘
│
│ top items chosen in Sprint Planning
▼
┌───────────────┐ ┌───────────────┐
│ Sprint │ ───────────▶ │ Increment │
│ Backlog │ build/integ. │ (releasable) │
│ (this cycle) │ │ │
└───────────────┘ └───────────────┘
2.5 The Definition of Done
The Definition of Done is the shared standard for saying "this is finished." Writing the code is not the end — the team agrees on test passes, code review, documentation, and a deployable state. When the Definition of Done is vague, "it is almost done" repeats every Sprint and the quality of the Increment becomes untrustworthy.
Definition of Done example
[ ] Functional requirements met
[ ] Unit tests written and passing
[ ] At least one code-review approval
[ ] Lint/format checks pass
[ ] Documentation updated
[ ] Verified deployed to staging
3. Kanban in Detail
Kanban is a flow-management method that originated in the Toyota Production System. The Japanese word means "signboard" or "signal card," and in software it is used to visualize the flow of work and limit how much work is in progress at once.
Where Scrum works in fixed-length batches, Kanban pursues an uninterrupted, continuous flow. It mandates neither defined roles nor a fixed iteration cadence.
3.1 Core Kanban Practices
Kanban has principles for managing change and a set of practices. The core practices are these.
- Visualize the workflow: Turn every piece of work into a card on a board so the flow is visible.
- Limit WIP: Set an upper bound on the number of items that can be in progress at each stage.
- Manage flow: Measure and improve so work moves smoothly between stages.
- Make policies explicit: Clearly write down the entry and exit criteria for each stage.
- Implement feedback loops: Hold regular meetings to inspect the flow.
- Improve collaboratively: Improve incrementally, grounded in data.
3.2 The Kanban Board
A Kanban board represents the flow of work as columns. The simplest form looks like this.
Kanban board (with WIP limits)
┌──────────┬──────────┬──────────────┬──────────┬──────────┐
│ Backlog │ To Do │ In Progress │ Review │ Done │
│ │ (WIP 3) │ (WIP 2) │ (WIP 2) │ │
├──────────┼──────────┼──────────────┼──────────┼──────────┤
│ [ #12 ] │ [ #08 ] │ [ #05 ] │ [ #03 ] │ [ #01 ] │
│ [ #13 ] │ [ #09 ] │ [ #06 ] │ │ [ #02 ] │
│ [ #14 ] │ [ #10 ] │ │ │ │
│ [ #15 ] │ │ │ │ │
└──────────┴──────────┴──────────────┴──────────┴──────────┘
│ │
└─── pull ───┘
(when a stage frees up, pull the next card = Pull system)
Here, "WIP 2" on the In Progress column means at most two items may be in progress at once. Even if you want to start a third, you must first move one in-progress item to Review to free a slot.
3.3 Why WIP Limits Matter
Limiting Work In Progress is the heart of Kanban. Counterintuitively, juggling more work at once does not raise throughput — it lowers it.
- Context-switching cost: Bouncing between tasks forces you to reload your mind each time. The switching cost accumulates.
- Bottleneck visibility: When work stalls against a WIP limit, that point is the bottleneck. The problem becomes visible.
- Faster completion: Focusing on fewer items finishes each one sooner and builds a culture of finishing what you start.
Little's Law gives this intuition a mathematical footing. Average lead time is proportional to the number of items in progress divided by the throughput. In other words, at the same throughput, more work in progress means each item takes longer to finish.
Little's Law (concept)
Average lead time = items in progress / average throughput
More items in progress → longer lead time
Reduce WIP → each item finishes sooner
3.4 Kanban Metrics
Kanban emphasizes data-driven improvement. Commonly used metrics include these.
- Lead Time: Total time from when work is requested to when it is completed.
- Cycle Time: Time from when work actually starts to when it is completed.
- Throughput: The number of items completed in a given period.
- Cumulative Flow Diagram (CFD): A time-axis graph of how much work sits in each stage. It reveals bottlenecks and pile-ups at a glance.
4. Scrum vs Kanban
The two frameworks share the same agile philosophy but emphasize different things. Neither is superior; fit depends on how the team works and the nature of the work.
| Aspect | Scrum | Kanban |
|---|---|---|
| Rhythm | Fixed-length sprint iterations | Continuous, uninterrupted flow |
| Roles | PO, Scrum Master, Developers | No roles mandated |
| Change timing | Avoid scope change mid-sprint | Re-prioritize anytime |
| Key metrics | Velocity, burndown | Lead/cycle time, throughput |
| WIP management | Implicit limit per sprint | Explicit WIP limit per column |
| Events | Planning, daily, review, retro | No mandated meetings |
| Artifacts | Product/sprint backlog, increment | Board, policies, flow metrics |
| Best fit | Plannable feature development | Operations, support, irregular intake |
| Change intensity | Introduce a new way of working | Apply incrementally over existing |
In practice, a blended approach called Scrumban is common — keeping Scrum's rhythm and retrospectives while adding WIP limits to the board. A framework is only a means to an end, so there is no need to cling dogmatically to one side.
Selection guide (rough intuition)
Work is plannable and periodic releases fit
└──▶ Scrum
Work arrives irregularly from outside (ops/support), flow matters
└──▶ Kanban
Overhauling the existing process feels too costly
└──▶ Start with Kanban and improve incrementally
The team wants both autonomy and rhythm
└──▶ Scrumban
5. Estimation
Agile handles "how long will this take" differently from traditional methods. The goal is not to hit a time estimate exactly, but to build a shared understanding of relative size and complexity.
5.1 Story Points
Story points express the size of work as a relative number rather than time. It is a comparison along the lines of "this is roughly twice as complex as that." They usually weigh three things together.
- Complexity: How technically difficult it is.
- Effort: How much hands-on work it takes.
- Uncertainty: How much is unknown, how big the risk.
The reason to use points instead of time is that people work at different speeds and an absolute estimate like "three days" misses often. Relative sizing is agreed on more consistently. As sprints accumulate, the team's average throughput — its Velocity — emerges, and you can plan ahead on that basis.
5.2 Planning Poker
Planning Poker is the classic technique for estimating story points together. It commonly uses cards based on a modified Fibonacci sequence.
Planning Poker cards (modified Fibonacci)
0 1 2 3 5 8 13 20 40 100 ? (coffee)
The gaps widen as numbers grow
→ reflects that larger items carry more uncertainty,
making precise estimates meaningless
→ "?" signals "I do not know," "coffee" signals "let us take a break"
The process is simple.
Running Planning Poker
1) The PO explains the backlog item
2) Each member reveals a card simultaneously
3) If numbers diverge widely, the highest/lowest explain why
4) Discuss, then re-estimate
5) Repeat until consensus is near
The point is not the "right answer" but "alignment of understanding"
Diverging values are themselves a valuable signal. If one person plays a 5 and another a 13, the gap usually comes from a difference in understanding the requirement. The conversation that closes that gap is the real purpose of estimation.
5.3 The Burndown Chart
A burndown chart shows how the remaining work declines over the Sprint. By comparing the ideal straight line with the actual trend, you gauge progress and risk.
Sprint burndown (concept)
Remaining
work
│＼
│ ＼ ＼ ideal line (even decline)
│ ● ＼
│ ＼● ＼
│ ＼ ● ＼
│ ＼ ● ＼
│ ＼ ●● ＼
│ ＼ ● ＼
└────────────────────────────────▶ time
start end
If the actual line stays above the ideal → risk of delay
A burndown should be used as a tool for conversation, not surveillance. Use it to interrogate "why are you late" and the team starts padding estimates, and the metric loses its meaning.
6. Anti-Patterns — Fake Agile
Following the form of agile while missing its spirit is commonly called "Fake Agile" or "Dark Scrum." The meetings and tools are in place, but in reality they have degraded into instruments of control and pressure.
Common Anti-Patterns
- Daily Scrum turns into a status meeting: Instead of developers adjusting plans together, it becomes a time to report progress to a manager. Fifteen minutes stretches to thirty, then an hour.
- Velocity used for performance review: Velocity is a planning metric; using it for team comparison or appraisals triggers point inflation. Everyone pads their estimates.
- Retrospectives skipped or perfunctory: Skip the engine of improvement "because there is no time," and the same problems recur every Sprint.
- Fixed scope + fixed schedule + fixed staff: All three are locked and it is still called agile. This is just waterfall sliced into sprints, with no room to respond to change.
- No Definition of Done: "It is almost done" repeats every time, and the quality of the Increment cannot be trusted.
- WIP limits ignored: A Kanban board is drawn but no limits are set, so every card piles into In Progress. You see pile-up, not flow.
- Scrum Master as manager: The facilitator becomes a supervisor who assigns and controls work, and self-organization disappears.
Real agile vs fake agile
Real Fake
───────────────── ─────────────────
Focus on the goal vs Focus on the ritual
Self-organizing team vs Top-down controlled team
Welcome change vs Block change
Learn from metrics vs Punish with metrics
Improve via retro vs Skip the retro
Done = releasable vs Done = "almost there"
The common root of fake agile is the urge to control. Agile fundamentally presupposes trust in the team. Introduce the form without the trust, and every event degrades into a surveillance tool.
7. Adoption Guide
When bringing agile to a new team, it is wise to drop the urge to apply everything from the book at once. Starting small and refining gradually is itself the agile way.
A Step-by-Step Approach
Incremental adoption roadmap
Step 1 Visualize the current flow
└ draw how work is done today, as-is, on a board
│
Step 2 Add one small rule
└ introduce a biweekly retro, or a WIP limit on one column
│
Step 3 Start measuring
└ track just one or two metrics like cycle time, throughput
│
Step 4 Adjust via retrospective
└ add or remove rules based on the data
│
Step 5 Repeat
└ keep improving until it converges to fit the team
Criteria for Choosing a Framework
- Is intake irregular?: For operations, customer support, and bug response where work arrives unpredictably, Kanban fits well.
- Is it plannable product development?: With a roadmap and periodic releases, Scrum is effective.
- What is the organization's tolerance for change?: If overhauling the existing process is hard, starting with Kanban, which layers on top, meets less resistance.
- How mature is the team?: For a team with low autonomy, Scrum's clear structure can serve as a learning scaffold.
Common Traps During Adoption
- Buying tools first: Adopting a board tool does not make you agile. The way of working and trust come first.
- Changing everything at once: Forcing all events and roles simultaneously overwhelms the team.
- Weaponizing metrics: Measurement is for learning, not punishment.
- Dropping the retro first: Skip the retro because you are busy and you lose the engine of improvement. If nothing else, protect the retrospective.
Conclusion
Agile is not a set of specific meetings or tools — it is a mindset of building small, getting frequent feedback, and improving continuously. Scrum structures that mindset with a fixed rhythm and roles; Kanban approaches the same goal through flow and WIP limits. Either way, what matters is not the form but the spirit inside it: trust in the team and continuous improvement.
What to guard against most is fake agile that merely imitates the rituals. The moment the Daily Scrum becomes a status meeting, velocity becomes an appraisal tool, and the retrospective disappears, the framework is left a hollow shell. Start small, learn from data, and adjust through retrospectives. The very process of converging to fit your team is the most agile practice of all.