Kanban vs Scrum vs XP – an Agile comparison

When you’re new to Agile the various methodologies and frameworks competing for your attention can be a source of confusion. In this post I’ll try to make as clear as possible the differences (and similarities) between the three most popular flavours of Agile: Scrum, Kanban and XP.

What’s Scrum?

Regular readers of this blog will be all-too-familiar with Scrum as it’s the project management methodology we use most at Manifesto (in fact, Manifesto is run entirely using Scrum). It was developed by Jeff Sutherland and Ken Schwaber in the early 90s.

In simple terms, Scrum breaks down organisations into small, self-organising teams. These teams then break the features they’ve been tasked with delivering down into small, manageable items of work which they tackle in time-boxed iterations called sprints.

The most prescriptive of the three frameworks considered in this post, Scrum insists that teams comprise of three distinct roles – the Product Owner, the ScrumMaster and dev team members.

There are also four prescribed meetings in Scrum: the Sprint Planning Meeting, the Daily Stand Up, the Sprint Review and the Sprint Retrospective.

What’s Kanban?

Kanban developed  as a subcomponent of the Toyota Production System and has its origins in these Lean and Just In Time (JIT) manufacturing processes.

In Kanban the workflow is visualised: work is broken down into small, discrete items and written on a card which is stuck to a board; the board has different columns and as the work progresses through different stages (e.g. ready, in progress, ready for review etc) the card is moved accordingly.

In Kanban the number of items that can be in progress at any one time is strictly limited.

The average time it takes to complete an item (sometimes called the ‘cycle time’) is tracked and optimised so that the process becomes as efficient and predictable as possible. The elimination of waste is paramount.

What’s XP?

XP is short for eXtreme Programming, a framework which focuses heavily on ensuring the quality of delivered software and which prescribes engineering solutions towards that end.

An XP team (comprised of all who contribute to the project) engage in Release Planning and Iteration Planning. They work in very short development cycles so that changes requested by the customer (who works on-site with the team) can be incorporated frequently.

Through more than a dozen core practices which include Test Driven Development, Customer Testing, Continuous Integration, Small Releases and Pair Programming, XP works towards a continuously improving, high quality product which can respond to changes in customer requirements.

Kanban vs Scrum

Scrum is more prescriptive than Kanban, which eschews defining roles and teams and which has no formal structure of meetings. Kanban doesn’t prescribe iterations either – though they can be incorporated if desired.

The process visualisation techniques of Kanban make it ideally suited to co-located teams who are working on a backlog of items that is subject to frequent change (for example, Kanban is often used by support teams).

The Kanban board though is often adopted by  Scrum teams in the form of a task board and is used to track progress throughout a sprint.

The limit to Work In Progress rule in Kanban also makes it suitable for teams with limited resources or where input from every member is required on each item. This could apply, for example, to a communications team within a large organisation.

While Scrum limits the amount of work going into each sprint, the workload is determined by the relative estimation of the size of each story (in points) and is agreed by the Scrum team in each planning session.

While a Kanban team tracks ‘cycle time’ and optimises for lead times that are as short and as predictable as possible, a Scrum team aims to improve its output over successive sprints and to improve the ‘velocity’ of the team (the number of relative estimation points completed in a sprint). This arguably makes Scrum more suitable for scaling – it certainly feels more familiar and predictable which can be reassuring for large organisations.

Scrum vs XP

In Scrum, teams and meetings are fairly set in stone whereas the question of how work actually gets done is left to the teams to decide themselves. XP on the other hand comes with a set of core practices that could seem overwhelming to the Agile beginner.

It could be said that Scrum is a methodology, which is more concerned with productivity while XP is more concerned with engineering.

The value that XP practices can add though is undisputable and many organisations which use Scrum adopt Pair Programming, Test Driven Development and Refactoring as practices which improve quality, speed up the release process and/or reduce the need to revisit work due to technical debt.

Alongside shorter iterations, some other important things which differentiate XP from Scrum are:

• XP teams work on items in a strict priority order whereas a Scrum team might not necessarily tackle each item in priority order once in sprint
• XP teams can bring new items of work into an iteration and switch out items of equivalent size (as long as they haven’t been started) if the customer decides on a new priority

In terms of similarities, the role of the customer in XP is very similar to that of the Product Owner in Scrum – in that they help write user stories, prioritise them and are always available to developers – though less well defined.

Both Scrum and XP mandate a daily stand up meeting.

While both stress the importance of co-location, only XP makes it deal-breaker.

Conclusion

The object of this comparison was never to choose a ‘best’ methodology but to explore the differences between them and to tease out potential reasons for choosing one over another in a specific scenario.

All three methodologies adhere to the principals laid out in the Agile Manifesto which aims at providing as much value to customers as possible in the time available. The differences between them are a result of trying to uphold the Agile principles in radically different contexts.

Kanban is a really useful way for teams with a continually changing backlog of items to increase efficiency by limiting the amount of work-in-progress, whilst respecting existing roles and responsibilities.

Scrum is more suitable for teams who can devote their collective time to a project or product. It brings much more in the way of structure to help teams make major productivity gains through frequent communication and planning while still providing the freedom to decide among themselves how to engineer solutions.

XP adds another level of sophistication, bringing a strong focus on quality by insisting on a set of core engineering practices which keeps code clean and software stable.

As we’ve seen in the comparisons, elements can be added/subtracted from a methodology to find a framework that fits your specific context. It might take a bit of trial and error to get there, but if you keep the Agile principles foremost in your thinking you’ll undoubtedly be on the right path.

And if you’re interested in further exploring the elements which make up Agile methodologies, and where they overlap, there’s a great tube-map-style visualisation over at Agile Alliance.