The Agile philosophy has inspired specific interpretations – known as frameworks – for project management, team collaboration, and organizational change.
What all agile frameworks have in common is that they continuously iterate on the work process itself and aim to deliver value to customers quickly and frequently. But there are now countless frameworks and each one offers its own flavor of agile.
We spoke with several Agile coaches to help you decide which framework is right for your team or organization. And we organized the most relevant frameworks according to team size and your type of organization. We also compared some of the most important and confusing ones, so you can make an informed decision about which to choose for your team:
The most widely used and known Agile approaches focus on the activities of small individual teams over whole organizations. They aim to create more value for customers and establish the most productive and sustainable work environment for small teams of up to roughly 10 people.
Agile frameworks provide guidance on how teams should collaborate with each other and with key stakeholders outside of the team. Most frameworks also explain how to structure the work process through specific meetings and task management systems.
Scrum is the most popular Agile framework and is used by 66% of Agile teams, according to the 15th State of Agile report. Scrum is likely so popular because it walks a delicate balance between being prescriptive and lightweight. It gives teams enough instruction to get started quickly but not too much that it becomes overwhelming.
Scrum adds structure to the working process. Within Scrum, teams work in cycles called Sprints that create a sustainable cadence of releasing small, valuable increments of work regularly, instead of releasing large products all at once and rushing to get things finished as a deadline approaches. Scrum also leaves room for reflection and adaptation through so-called "Sprint Retrospectives", which take place at the end of each Sprint and help teams continuously improve how they work together.
Scrum teams organize their members into three different roles – developers who create the product, a product owner who prioritizes the work, and a Scrum Master who helps the team understand and practise Scrum. The group is cross-functional, so they have all the skills needed – within the team – to accomplish their work.
Kanban uses a central board with columns to visualize a team's workflow. In its most basic implementation, the board contains at least three columns – "Backlog," "Work In Progress (WIP)," and "Done." Some teams also add a "Stuck" column to flag items that need unblocking. Cards representing deliverables move through those columns depending on their status. Team members pick a new item from the top of the Backlog column whenever they've finished their previous deliverable.
Kanban is more flexible than most other agile frameworks because you can add or reprioritize items at any time. It restricts the number of tasks in the “WIP” or “Doing” columns – usually based on the number of team members – to avoid overload and highlight bottlenecks. This approach creates a calm and continuous flow of work, which one coach compared to “water continuously running down a stream.”
As the name gives away, Scrumban combines Scrum and Kanban. There's no "official" or prescriptive guide of what parts of Scrum and Kanban make up Scrumban, so it's up to teams to pick the parts that serve them best. That said, in Scrumban almost all teams tend to keep the Kanban board and limit the number of items in each column at any time.
Most Scrumban practitioners introduce a work cycle similar to Scrum's Sprints to create rhythm, and customization happens within those cycles. Many add Retrospectives and specific roles for team members, some a daily standup meeting or a planning session at the start of each Sprint.
The XP framework is specifically tailored to teams of programmers. It improves software development projects through a set of specific values and technical practices. Like Scrum, it emphasizes the inclusion of customers in the entire process, involves working in cycles of one to two weeks with frequent releases and planning sessions, and embraces standup meetings at the start of each day.
The most distinct values and technical practices that make XP different from Scrum are:
Many popular Agile frameworks like Scrum, XP, and Kanban were initially created for single teams of not more than a dozen people. However, they don't provide guidance on how to scale practices to multiple teams or entire organizations. Scaled Agile frameworks like SAFe, LeSS, and the Spotify Model fill this gap by helping coordinate the work of large groups and departments.
The SAFe framework provides an answer to scaling Agile processes, which many teams struggle to do. According to the most recent research, 37% of organizations said SAFe helps them scale Agile. The next most popular answer was “I don’t know”, showing the extent of confusion around how to scale agile to larger organizations.
🤯 Just looking at this visualization of the SAFe model is enough to give mere mortals a headache. It makes you wonder how something so complex can still be agile. (Source: scaledagileframework.com)
SAFe is more prescriptive than other frameworks and for that reason, it's also one of the most controversial among agile coaches. It packages elements from Agile, Lean management, and systems thinking into modules with formal names like "Lean governance" and "Agile portfolio operations". SAFe also includes traditional management practices, like a quarterly planning process. It leaves less room for experimentation within teams, which is why some Agile practitioners consider SAFe just partially agile, and others think it’s anti-agile.
In LeSS, all agile teams are in one Sprint to deliver a common shippable product. A comprehensive mobile app, for example, where each team is responsible for a separate part of the product but which gets released in one combined delivery at the end of each Sprint.
Whereas Scrum and Scrum of Scrums use one list of work items per team—the so-called Backlog—, LeSS has one Backlog and one Product Owner for the entire product across all teams. Teams coordinate at the start of each Sprint what specific parts from that shared list each team will work on. Then each team goes through the normal Scrum process with their selection. At the end of the Sprint, all teams regroup to consolidate the work into one delivery and start the next cycle.
DA was born from Scott Ambler and Mark Lines’ book “Find your WoW”. It contains a comprehensive collection of strategies and practices taken from agile frameworks and other methodologies like Lean and Waterfall.
It’s often considered a toolkit rather than a process framework like Scrum or SAFe that tells you what to do. Still, many teams talk about adopting a ‘Disciplined Agile’ approach in their work because it lets teams design an agile process for their specific situation. Think of it like an à la carte menu, whereas Scrum is a fixed three-course set menu.
Jagriti Kapoor, who has managed several large DA implementations, says it’s a "process-decision toolkit." DA gives teams the knowledge and tools to select agile practices and create a personalised approach that’s right for their situation. This means most teams adopting DA spend time reflecting and talking about what’s important to their team and how they want work to be structured, often with the help of a coach.
DA is much less prescriptive than most other frameworks. SAFe, for example, says: "PI (Program Increment) planning is essential, and here's how it works. If you are not doing it, you are not doing SAFe." DA, instead, would help you figure out if PI planning is right for you through training, coaching, and tools similar to the pictured option table.
Scrum of Scrums works well for organizations that are scaling up from regular Scrum. Each team keeps their existing Scrum elements – the Backlog, meetings, and roles –but representatives of each team meet once per day in the so-called "Scrum of Scrums." During this meeting, they discuss upcoming work to create a shared understanding at the group level and manage any dependencies between teams effectively.
As Agile Coach Chris Wolff put it: "It's a lightweight tool for ensuring everyone understands what the hell is going on." He gave the example of two teams using a shared piece of code. If team A starts working with it, team B becomes aware of it through the Scrum of Scrums and can say: "Hey, hang on a minute. That's actually going to impact how we use that common piece of code. Can we have a conversation to make sure you don't break our work?"
The Spotify model differs from other frameworks by organizing teams into a matrix structure. Agile teams are called "Squads." They can choose their own agile way of working, like Scrum or Kanban. Related Squads organize in larger groups called “Tribes.” Each Tribe has a Product Owner, Agile Coach, and Technical Leader.
To this structure of Squads and Tribes, the Spotify model adds "Chapters" and "Guilds." These are groups of people with the same competency—like testers, marketers, or software developers—who can share knowledge and management support, even though they're not within the same Squad or Tribe. Chapters form within Tribes, while Guilds form across the entire organization.
- Squad – An agile team using a framework of their choice
- Tribes – A collection of agile teams working on the same feature or product
- Chapter – Groups of specialists who come together across disciplines but within a tribe (i.e. all designers in a tribe)
- Guild – Communities of interest that involve people from multiple squads who want to pursue a topic further (e.g. an a11y guild).
Despite its fierce critics and Spotify itself abandoning the model, other organizations such as ING have found a lot of value in the matrix structure of chapters and guilds. Agile Coach Murray Robinson said: “The Spotify model is effective because it provides agile team members with coaching, training, and support from functional experts in their field.”
Comparing Agile frameworks is hard because even many experts don't agree on the make-up of each approach or on what basis to make such comparisons. Many of the frameworks have emerged organically and also do not have any documentation. We're going to be foolish trying to compare several agile frameworks anyway. 🙉
The diagram below compares most of the Agile frameworks we've discussed earlier on two dimensions:
Kanban is more flexible and responsive than Scrum because Scrum usually works in two-week Sprints in which work items are more or less fixed based on the Sprint goal a team has committed to. In Kanban, work items can be pulled back and replaced by new deliverables at any time.
Agile Coach Murray Robinson explained how Scrum can be inflexible sometimes: "Let's say you're doing a two-week Scrum. If, in the middle of that, your product manager comes and says, 'We've got something urgent,' you can't interrupt the Scrum team to do something new. You've got to wait for the next Sprint. So, it's probably going to take you about three weeks to get to anything new."
Comparing SAFe and Scrum is almost like comparing a truck with a car. You can drive both, and they share some similarities like wheels and engines. But their purpose, size, and operation are vastly different.
Scrum is designed to be practised by single teams of between three and nine members. Whereas SAFe uses elements from Scrum but tries to provide a complete agile solution for an enterprise organization with hundreds or thousands of people and departments.
LeSS keeps all the elements of standard Scrum but adds a few extra touches to ensure the Scrum process can scale from a single team to an entire organization. SAFe feels more like it started from traditional management practices taking a top-down view, then adding Agile elements where possible.
If they were people, LeSS is a casually dressed executive at a fast-growing startup. In contrast, SAFe is a buttoned-up head of department at a traditional corporate company.
Working with Agile frameworks is like cooking. When you're a new chef and trying a recipe for the first time, you'd better follow it to the letter. But as you gain more experience and learn more recipes, you start to mix and match. You add an idea from another recipe and alter the preparation steps because you've found a way to speed up the process.
Perhaps most importantly, you start to make changes that better suit your tastes and those of your guests. The purpose of cooking is not to follow the recipe successfully or change things for change's sake. It's for whoever's eating the dish to have a delicious and enjoyable meal.
Which Agile framework you pick or whether you follow it to the letter is much less important than how you implement and evolve it to get the results you want.
As Agile coach Rebecca Sassine said:
Thanks to Rebecca Sassine, Chris Wolff, Erwin van Maren, Jonas Lidman, and Scott Weiner for taking the time to share their insights with us and reviewing early drafts of this article. An especially scaled thanks to Jagriti Kapoor and Murray Robinson for their extraordinary efforts to help get this article into good shape.
"Always [be] figuring out if it's bringing the team value or not, and then pick and choose from whatever framework you want. At the end of the day, it's all under the Agile umbrella. We just want to help teams produce better work that will be received really well at the other end."