Alternatives to Scrum:
In the article ‘Is Scrum Even Agile?’, we discussed how Scrum can be quite a rigid framework to start off with. Keeping that in mind, we may ask the question “What framework alternatives are available for potential use?” For your convenience, I’ll compare Scrum to some of the most commonly used ones. Feel free to treat the article as a cheat sheet and a basic introduction to the most popular frameworks and their relation to Scrum.
As of writing, there are over 50 Agile frameworks in existence. Rather than spend time analyzing each one to find a perfect fit, it’s better to go back to basics and think of general concepts from the Agile Manifesto such as:
- Early, continuous and regular delivery of working, valuable software.
- Business people and developers working closely together.
- Focus on the right things, maximize the amount of work not done (to reduce waste).
- Empowered, Motivated, self-organizing teams.
- Good design and good quality.
- Regular reflection points to improve the product and process.
Scrum vs Kanban:
A very lightweight way to start working in an Agile way is to utilise Kanban, the next most popularly used framework. Originally created as a lean framework for use in Japanese car manufacturing, this can often be a good starting point, and the general concepts are:
- Limit work in progress to increase focus and reduce context switching.
- Make the work transparent so that everyone knows where effort is being spent.
- Make working processes explicit. If it’s written down then it can be improved.
- Implement feedback loops to allow the product and process to be revisited.
- Manage flow to identify where bottlenecks are.
- Improve collaboratively to allow everyone to input into team improvements.
The main differences to Scrum are that Kanban lists a general set of rules to follow and then you just get started working development item by development item, rather than Scrum which has a weighty guide (albeit slimmed down as of 2020) and a set of mandatory regular meetings.
As a rough guide, if you know what you need to achieve and how you are going to achieve it, it’s likely that Kanban will work better for you than Scrum, which is more geared towards ‘test and learn’ software development.
| Scrum | Kanban | |
| Cadence | Regular fixed-length sprints (ie, 2 weeks) | Continuous flow |
| Release methodology | At the end of each sprint | Continuous delivery |
| Key roles | Product owner, scrum master, the development team | No required roles |
| Change philosophy | Teams should not make changes during the sprint. | Change can happen at any time |
Scrum vs XP:
Extreme Programming or XP is a set of recommendations for how small teams of computer programmers should work together. Unlike Scrum, XP does not purport to be an industry-agnostic framework and solely deals with software development.
XP allows you to fill in a lot of the blanks about how your software development team should work together, with recommendations about estimation, testing and how developers can collaborate to ensure quality code is written.
Generally speaking, you should look to implement aspects from XP into any software development team.
| Scrum | XP | |
| Cadence | Regular fixed-length sprints (ie, 2 weeks) |
The iterations are 1-2 weeks or less. For very aggressive teams, it can go up to a day.
|
| Release methodology | At the end of each sprint |
Frequent releases in short development cycles to improve software quality and allow developers to respond to changing customer requirements.
|
| Key roles | Product owner, scrum master, the development team |
Developer, Customer, Manager (also called a tracker), Coach
|
| Change philosophy | Teams should not make changes during the sprint. | Response to changing customer requirements. |
Scrum vs SAFe:
The Scaled Agile Framework (SAFe) is a framework based loosely on Scrum, designed to fit into large organizations. SAFe makes a series of recommendations about how to layer a hierarchy on top of Scrum teams in order to make it palatable and consumable by senior executives in an organization.
It is often described as being quite unwieldy and complicated and regularly comes in for criticism from industry practitioners for these reasons. It’s definitely not a good starting point for a new agile team, rather something that large organizations tend to aim for to exert some level of control over their teams.
| Scrum | SAFe | |
| Cadence | Regular fixed-length sprints (ie, 2 weeks) | Series of iterations within a PI (Program Increment) |
| Release methodology | At the end of each sprint | Release on demand |
| Key roles | Product owner, scrum master, the development team | Product Owner, Product Manager, Solution Manager, Business Owner, Development team |
| Change philosophy | Teams should not make changes during the sprint. | Proper alignment is needed to keep pace with fast change. |
A Program Increment (PI) is a timebox during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software and systems. PIs are typically 8 – 12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration.
Summary:
Starting off with the wrong agile framework can be counter-productive and may result in your team or organization rejecting agile altogether. By taking a step back, understanding the objectives of the team, what you are trying to build, and the available frameworks, you can start off on the right foot with a happy, productive team. Take small steps and review regularly to build the right approach for you!
