Agile Software Development: Scrum, Kanban & XP

Agile Software Development

Agile software development is a way of building software in small, frequent increments with continuous feedback, so that a team can change direction as it learns instead of following a plan written when it knew least. The term comes from the 2001 Manifesto for Agile Software Development, written by practitioners frustrated with document-heavy processes that delivered the wrong thing late.

Agile is a set of values and principles, not a single method. Scrum, Kanban, and Extreme Programming (XP) are concrete frameworks that put those principles into practice in different ways. Many teams adopt the ceremonies of a framework without its substance — sprints without working software, stand-ups without collaboration — and conclude that Agile does not work. Understanding the underlying ideas makes it possible to tell the difference.

TL;DR

Agile favours working software, collaboration, and responding to change over comprehensive plans and documents — while still valuing both.
Deliver in small increments that real users can see; feedback from working software beats speculation.
Scrum organizes work into fixed-length sprints with defined accountabilities and events; Kanban manages continuous flow with work-in-progress (WIP) limits; XP supplies the engineering practices both need.
Technical excellence — automated tests, continuous integration, refactoring — is what makes frequent change safe.
Measure flow (cycle time, throughput, WIP) and outcomes, not velocity as a productivity score.
Agile fails when it becomes ritual: ceremonies kept, feedback and adaptation dropped.

Quick Example

Flow metrics from a team's completed work items — the data behind realistic forecasts.

"85% of our items finish within 8 days" is a forecast stakeholders can use — and it comes from history rather than from estimating each item.

Core Concepts

The Agile Manifesto

The Manifesto states four value comparisons:

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 items on the right still have value; the items on the left are valued more. Twelve supporting principles add specifics: deliver frequently, welcome changing requirements, measure progress by working software, sustain a constant pace, pay continuous attention to technical excellence and good design, and reflect regularly to improve.

Iterative and Incremental Delivery

Incremental delivery ships the product in usable slices; iterative delivery revisits and improves those slices based on feedback. Together they shrink the distance between a decision and evidence about it. The slice should be vertical — a thin piece of user-visible value through every layer — rather than a horizontal layer such as "the database schema".

The Backlog

A product backlog is a single ordered list of everything the team might do. Items near the top are small, well understood, and have acceptance criteria; items lower down are coarse ideas. Backlog refinement — splitting, clarifying, and estimating upcoming items — is ongoing work, not a quarterly event.

Definition of Done

The Definition of Done is the team's shared quality bar for any increment: code reviewed, tests passing, documentation updated, deployed to an environment, accessibility and security checks met. Without it, "done" quietly means "done except for testing", and unfinished work accumulates.

Frameworks

Scrum

Scrum organizes work into sprints of one to four weeks, each producing a usable increment.

Accountabilities: a Product Owner who orders the backlog and maximizes value, a Scrum Master who helps the team and organization use Scrum effectively, and Developers who build the increment.
Events: Sprint Planning, the Daily Scrum, the Sprint Review (inspect the increment with stakeholders), and the Sprint Retrospective (inspect how the team works).
Artifacts: the Product Backlog, the Sprint Backlog, and the Increment, each with a commitment — the Product Goal, the Sprint Goal, and the Definition of Done.

Kanban

Kanban manages a continuous flow of work rather than fixed iterations. Its core practices are visualizing the workflow on a board, limiting work in progress, and actively managing flow using measurements such as cycle time and throughput. Limiting WIP is the counterintuitive key: starting less work finishes more, because unfinished work waits in queues and hides problems.

Extreme Programming (XP)

XP focuses on engineering practices: test-driven development, pair programming, continuous integration, small releases, collective code ownership, simple design, and refactoring. Scrum and Kanban say how to organize work; XP says how to keep the code changeable enough for that organization to work.

Comparing the Frameworks

Many teams combine them: Scrum or Kanban for organizing work, XP practices for building it.

Planning, Estimation, and Forecasting

Teams estimate to decide what fits and to forecast delivery. Common approaches:

Story points — relative size estimates used to plan sprint capacity. Useful within one team; meaningless across teams.
Counting items — when work is sliced to similar sizes, simply counting items forecasts as well as points.
Probabilistic forecasting — using historical cycle time and throughput, often with Monte Carlo simulation, to say "85% likely by 14 March" instead of committing to a single date.

Whatever the method, estimates are forecasts with uncertainty, not promises. Communicate ranges and update them as work completes.

Measuring an Agile Team

Velocity — story points completed per sprint — is a planning aid for the team itself. Used as a productivity target, it inflates estimates and stops meaning anything.

Best Practices

Ship Working Software Every Iteration

Each sprint or cycle should end with something users or stakeholders can see and react to. If increments only reach users quarterly, the feedback loop that justifies Agile is missing.

Limit Work in Progress

Finish before starting. Fewer items in progress means shorter cycle times, faster feedback, and earlier discovery of problems.

Invest in Technical Excellence

Automated tests, continuous integration, and continuous refactoring keep the cost of change low. Without them, frequent change becomes frequent breakage, and teams slow down until they abandon iteration.

Make Retrospectives Produce Changes

Pick one or two concrete improvements per retrospective, assign an owner, and review the result next time. Retrospectives that never change anything teach the team that reflection is pointless.

Keep Teams Stable and Cross-Functional

Agile assumes a team that can take an item from idea to production without waiting on others. See Team Topologies for structuring teams around flow.

Common Mistakes

Velocity as a Performance Metric

Sprints Without Increments

Agile as "No Planning"

Mandated Ceremonies, Missing Feedback

FAQ

What is Agile in simple terms?

A way of building software in small pieces, getting feedback on each piece from real users, and adjusting the plan based on what you learn. Instead of designing everything up front and delivering at the end, Agile teams deliver something useful every few weeks.

What is the difference between Agile and Scrum?

Agile is a set of values and principles; Scrum is one specific framework for applying them, with sprints, defined accountabilities, and events. You can be Agile without Scrum — for example, with Kanban — and you can perform Scrum's ceremonies without being Agile at all.

Do we need a Scrum Master?

Scrum defines a Scrum Master accountability, but small teams often share it or combine it with another role. What matters is that someone helps the team remove obstacles and keep improving how it works. Kanban and XP do not require the role.

How do Agile teams handle deadlines?

By fixing time and flexing scope. The team delivers the most valuable work first, so when a deadline arrives the most important parts are done. Probabilistic forecasting from cycle time and throughput gives stakeholders early, honest warning when scope will not fit.

Is Agile only for software?

It started in software but its ideas — small batches, fast feedback, limiting work in progress — now appear in marketing, operations, and hardware. Its engineering practices, such as continuous integration and test-driven development, are specific to software.