Alternatives to Scrum

alternatives to scrum

I’ve talked a lot about Scrum on this blog recently. Scrum has some strengths and some weaknesses. You need to know about those to understand it and use it properly. I think Scrum is a good tool and a great start for people new to Agile. But you might be interested in alternatives to scrum. Scrum is by far the most popular form of Agile software development, but there are other options. In this article, I’ll run through the various alternatives to scrum and their strengths and weaknesses. Let’s look at the first one.

Some alternatives to Scrum

Extreme Programming or “XP”

Kent Beck started Extreme Programming in the 1990s, with some help from Ron Jeffries. It’s a more “extreme” and prescriptive form of Agile than Scrum. The main difference is it dictates some specific technical practices that Scrum does not. More specifically, Pair Programming and Test Driven Development.

Pair Programming means two people programming at a time, but on one computer. They work together and discuss the code as they are writing it. The advocates of this say it is more productive, not less, because there are fewer errors and better code. Test Driven Development means you write automated tests for everything. In fact, you write tests first, before you write code. Write a (failing) test, then write code to make the test pass, then refactor the code. This pattern is known as Red, Green, Refactor.

Extreme Programming involves a few controversial changes and may not be for everyone. Many organisations do not even attempt to implement it. I haven’t much experience with it directly, but from what I have seen, Pair Programming can work well for some people and not well for others. So I think mandating it for everybody is a bad idea. Test Driven Development is a good practice, though. It will be hard and slow to implement at first, but the long-term returns on investment are great.


Kanban is not actually a software development methodology, but simply a way of visualising and tracking work. It is very lightweight, abstract and flexible. It is easy to implement and fits well with other frameworks and methodologies. That is why many organisations will do Kanban in addition to something like Scrum or Extreme Programming. Some people call the combination of Scrum and Kanban “Scrum-ban”.

The ideas behind Kanban are very simple: start from where you are (don’t change anything just yet), and visualise the work. Put the work people are doing on some kind of visual tool and describe it in discrete units, in discrete states. A good way to do this is a Visual Management Board (VMB) with vertical “swimlanes” representing work states: Backlog, Ready for Dev, In Dev, etc. And you make sure that work that is in a “doing” state has a person assigned to it. And you make sure you clearly mark any blocked work. You can take this further by implementing WIP (Work In Progress) limits. The idea is to maximise flow and throughput, so that:

  • all work is represented on the board and is in a particular state
  • all work is assigned to one and only one person
  • as little work as possible is blocked
  • as little work as possible is in a “ready for” state
  • there are roughly even numbers of work in each column.

If you want to read more about Kanban, here is a good book about it: Kanban in Action. Or David Anderson’s classic, Kanban: Successful Evolutionary Change for your Technology Business.


This is one of the lesser known alternatives to scrum. Crystal was designed by Alastair Cockburn, one of the original signatories on the Agile manifesto. It promotes some familiar Agile principles, such as short communication loops, co-located cross-functional teams, and short iterations. It is pretty flexible and actually comes in different variations (Crystal Clear, Crystal Orange, etc.), depending on the constraints of the work. The ideas here are pretty sound but Crystal didn’t really take off, I’m not sure why.

Lean Software Development

Tom and Mary Poppendieck took many of the ideas from the Japanese systems of Lean Manufacturing and the Toyota Production System and applied them to software. Lean Software Development has the following principles:

  • Eliminate Waste
  • Amplify Learning
  • Decide as Late as Possible
  • Deliver as Fast as Possible
  • Empower the Team
  • Build Integrity In
  • See the Whole.

While some Lean ideas are more suited to repetitive industrial work (as opposed to iterative creative work), this is a good system. Unlike Scrum it has no specific roles or rituals, so you can tailor those as you see fit. Like Kanban, you can use many of the ideas here are in conjunction with a formal system like Scrum or XP. Rather than as a stand-alone system. If you want to know more, check out the articles I wrote on the difference between Lean and Agile, or the Lean wisdom at the heart of Agile.

Scaled scrum

Many large organisation struggle to implement Scrum because they might have hundreds or even thousands of people working on software. And Scrum is ideally for one team of about seven people. I talked about this when I wrote about the problems with Scrum. So there are some “scaled scrum” systems, that tell you how to use Scrum / Agile in a large organisation. So these aren’t really alternatives to scrum, more like extensions or modifications. The main ones are SAFe (Scaled Agile Framework, by author Dean Leffingwell), LeSS (Large Scale Scrum, an older system from 2005), DAD (Disciplined Agile Delivery, with more of a focus on DevOps), and a newer entrant X-SCALE.

History will show us how these systems will fare. So far, SAFe is probably the most popular, but it certainly has its critics. I believe that XSCALE and Large Scale Scrum are the superior choices and that SAFe is a significant move away from agility for many organisations.


Leave a Comment:

Add Your Reply