Agile Frameworks: A Complete Overview

The Agile manifesto 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:

Agile frameworks for teams

Scaled Agile frameworks for organizations

Agile frameworks compared

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.

Parabol’s agile product team at a recent meetup in Mexico

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.

🤷‍♀️ When to use it:
Scrum is a great way to get started with Agile, especially for smaller organizations. Since it’s one of the most popular agile frameworks, more resources are available to help you along. Scrum also works well for disciplines beyond software development, such as for marketing or design teams.

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.”

🤷‍♀️ When to use it?
Kanban suits teams that need to respond to incoming requests quickly or have fast-changing product requirements. It’s also useful for teams that want to remain focused thanks to WIP limits. 

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.

🤷‍♀️ When to use it?
Scrumban is a great fit for teams with Agile experience that feel Scrum is too rigid or Kanban too loose. Scrumban lets you tailor your own middle ground. It’s also worth trying when you find Scrum throwing your team into last-minute crunches at the end of each Sprint or you want to help your team focus on just one task at a time rather than multi-tasking or context-switching.

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:

🤷‍♀️ When to use it?
XP is great for teams of programmers that want to dial up the output and quality of their work through a framework that’s specifically tailored to software development. Since one of the key parts of XP is pair programming, teams with a mix of junior and more senior members may find it valuable.

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.

🤷‍♀️ When to use it?
SAFe is best for large organizations with a traditional management style that want to take baby steps to a new way of working. It’s like “training wheels” for Agile transformations, Agile Coach Jonas Lidman said. But SAFe is a huge, heavy framework. It often appeals most to people at the higher levels of an organization – executives and program managers – because it gives them a sense of control, often at the expense of making teams and the organization truly 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.

🤷‍♀️ When to use it?
LeSS is a lightweight alternative to SAFe. It works well for organizations with many autonomous teams that already use the Scrum process and collaborate on one large product or deliverable. It makes Scrum easy to scale.

Disciplined Agile (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.

🤷‍♀️ When to use it?
DA is a good option for organizations that find SAFe too heavy and other scaled frameworks too light. Because DA takes a ‘choose your own adventure’ approach to agile it can also work well for teams that want to evolve their existing agile practices in a more structured and guided way than, as one coach put it, the “end of agility that comes with the tree-hugging hippie end where we’re all friends… We already work together, and everything’s flexible, and we don’t necessarily know exactly where we’re going.”

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?”

🤷‍♀️ When to use it?
Scrum of Scrums suits teams that are outgrowing Scrum and just need an extra layer of coordination between them, but not much else. It differs from LeSS in that each team keeps their own Backlog, roles, and meetings. Scrum of Scrums is great for organizations that want to maintain Scrum as far as possible on the individual team level.

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.

For example:

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.”

🤷‍♀️ When to use it?
The Spotify Model is a good alternative to SAFe because it’s not overly prescriptive but still provides sufficient guidance on structuring many teams. It’s certainly more flexible than SAFe and leaves room for Squads to use frameworks like Scrum or Kanban, or for entire Tribes to use a framework like LeSS.

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.”

📌 Scrum vs. Kanban essential differences:

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.

📌 SAFe vs. Scrum essential differences:

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.

📌 SAFe vs. LeSS essential differences:

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.