Agile frameworks have become an essential part of software development. They help businesses and teams create high-quality products faster and more efficiently. When most people hear about agility, they think of Scrum, however, there are many other agile methods.
From Kanban to SAFe to DA: Each agile framework exists for a reason and has different characteristics and strengths. In this guide, we'll provide you with a comprehensive overview of the most popular agile frameworks, what they're used for, and their advantages and disadvantages.
Agile Frameworks – A Brief Differentiation
What's the difference between an agile method and an agile framework? Since the two terms are often used interchangeably, we want to start with a few words about their differences.
Agile frameworks include all of the processes, structures, methods, and tools that are used in a particular setting. An agile framework should help teams develop an agile mindset and often include guidelines or rules that facilitate the implementation of an agile approach to work.
Scrum is commonly referred to as an agile method, however, this isn't entirely accurate. Instead, Scrum is an agile framework that uses agile methods, like planning poker.
All agile frameworks are flexible and adaptable to dynamic environments. They conform to the agile manifesto and are noted for their customer-centric approaches.
Overview of Common Agile Frameworks
Every agile framework has strengths and weaknesses. Below, we've briefly summarized the most important aspects of several popular frameworks, along with their advantages and disadvantages:
Scrum is perhaps the most well-known agile framework. The Scrum Guide offers teams and businesses a blueprint for how to implement an agile approach to work and incremental software development.
Scrum is an agile framework characterized by different meetings and events.
Agile project management and software development
Product owner, Scrum master, Development team
Meet customer needs, yield finished iterations and sprint goals
Events, pull principle, Sprint backlog, Sprint velocity
Easy to implement and can be quickly adapted
Fixed structure that ensures more efficiency and productivity
Sprint-based approach focuses on short-term goals
Ideal for small teams and can be scaled as needed with other frameworks
Teams must familiarize themselves with the framework and internalize its processes
Management needs to commit to the framework and not interfere
Significant responsibility often requires a change in thinking
Changes can only be reacted to in the next Sprint
Would you like to learn more about Scrum? If so, be sure to check out our guide below:
A Kanban board is an agile method that's often used in agile frameworks. This board is divided into several columns that indicate which stage a project or task is in. There are usually three columns: "Open", "In Progress", and "Done":
With a Kanban board, you can visualize a team's workload.
However, Kanban isn't just an agile method, but can also a framework that's adaptable to agile and other contexts.
Agile project management, visualize workload(s)
Visualize workload(s) and allocate resources as effectively as possible
WIP limits, pull principle
Very flexible - can be adjusted at anytime
Visualize processes and tasks to boost transparency
Improved stakeholder communications through visualizations
Simple process that can be easily used
See a team's workload
Not for long-term planning
Quickly becomes confusing as the team's size increases
Lack of time component can create deadline issues
Dependencies aren't visible
Those who use Kanban as a framework should be familiar with WIP limits and the pull principle. For more information about these, and everything else you need to know about Kanban, be sure to check out our guide here:
Scrumban combines aspects of Scrum and Kanban, such as the former's project meetings and Kanban's WIP limits. The result is a lean, agile project management framework.
Scrumban offers the best of both Scrum and Kanban.
Agile project management
Any; small-medium teams tend to benefit more
Establish a flexible and agile workflow that meets the company's needs
Scrumban board, WIP limits, pull principle, meetings (planning, review, retrospective
No fixed definition; organizations can adapt it to their needs
Flexible work approach thanks to elements from both Scrum and Kanban
New requirements or changes can be introduced at any time
Velocity doesn't need to be measured
Collaborate on an equal basis; no defined roles
In the race to improve and adapt, teams can lose sight of their focus
Management problems can arise since there are no clear leaders
You can read more about Scrumban here:
Extreme Programming (XP)
XP is an agile framework that's used to quickly respond to changes in customer requirements or needs. The framework can be traced to Kent Beck, who wanted to introduce quality assurance for software development projects.
Even from the name, it's possible to see that XP isn't for those who just want to try out an agile framework. XP has five main values:
- 1.Communication: Whether in a team or with customers, communication is always key.
- 2.Simplicity: Find the easiest solution that works.
- 3.Feedback: The team quickly receives feedback from customers and uses it to make adjustments.
- 4.Courage Team members should be ready to confront problems and risks, and experiment.
- 5.Respect: Collaboration on an equal footing is particularly important.
There are more guidelines and principles that shape XP's processes. One of these is to consider whether the framework is applicable during the planning stage.
Some of XP's methods include pair programming and test-driven development. With this, changes and errors can be reacted to at any time.
Even customer testing is envisioned since it allows the team to ensure their software's quality and conformity to requirements. These must adhere to strict cycles, which guarantee quick, incremental task completion and coordinated process planning.
10-12 developers (max)
Customer, developer, manager, coach
Maximum agility and fulfillment of customer expectations
Self-organization, customer feedback
High software quality
Maximum degree of agility
High customer satisfaction thanks to quick and regular releases and the fulfillment of requirements based on customer interactions
Teams can quickly identify and solve problems
High motivation because of successful experiences and identification with results
Considerable testing effort
Large amount of work required during introduction, since the team must familiarize itself with the framework
Significant amount of self-organization and the corresponding mindset and conditions
Not well-suited for every project
The framework developed by Alistair Cockburn is well-known for its flexibility and scalability to projects of different sizes and levels of complexity. Strictly speaking, Crystal isn't a single agile framework, but rather a family of variants with agile methods. These can be adjusted to meet the specific requirements and conditions of a particular project.
Crystal's key aspects include direct communication, incremental development, continuous improvement, and adaptability. People and teams are the method's focus. Its variants pertain largely to a project's level of risk, as well as the team's size.
The bigger the project and the greater the risk, the more roles and management methods a variant will have. With Crystal Clear, developers to test each other's results, however, with Crystal Orange, teams need to bring an external developer on board for this.
Depends on the variant: Clear (6 people), Red (80 people), Diamond (200+ people)
Depends on the variant: Executive sponsor, ambassador user, lead designer, programmer, coordinator, business expert, and tester
Provide a flexible framework that adapts agile methods to project requirements
Roles, structures, and meetings
High degree of adaptability and flexibility for different project scenarios
Encourages adherence to quality standards
More transparency thanks to focus on communication
Lots of familiarization and practice required because of different variants and method mixes
Wrong variant/method mix can reduce process efficiency
No clear implementation guidelines
Flexibility and lack of standardization can only be properly harnessed by mature teams
Feature-Driven Development (FDD)
Jeff De Luca introduced this agile framework in 1997 to emphasize the development of features. Each feature should generate value for the customer and be introduced iteratively through a feature plan.
FDD can be simplified into five process steps:
- 1.Develop an overall model
- 2.Build a feature list
- 3.Plan by feature
- 4.Design by feature
- 5.Build by feature
FDD users can also take advantage of the toolbox of different agile methods, roles, and structures that it includes. These help ensure that increments are delivered quickly.
5-8 people (recommended)
Developer, chief programmer, development manager, project manager
Quick delivery of features in increments
Roles and structures
Focus on the development of features that generate added value for customers
Straightforward process with clearly-defined steps
High degrees of transparency and accountability
Lots of effort during training
Not suited for large projects and teams
Less flexibility when requirements change (in comparison to other agile frameworks)
Design Thinking is all about teamwork and multidisciplinary. It encourages teams to think outside of the box and work differently than they're accustomed to. In this way, traditional thought patterns are abandoned so that innovative solutions to complex problems can be promoted.
Although many see it as an agile method, in practice, it's more accurate to refer to it as a framework with an iterative process. The user is made to understand challenges from other perspectives and encouraged to develop solutions that correspond to their needs and desires.
David Kelley developed the well-known Design Thinking Process, which is made up of five phases:
- 1.Empathize: Understand the user's problems, needs, and desires.
- 2.Define: Identify the problem, based on previous work.
- 3.Ideate: Brainstorm and constructively develop solutions and ideas through creative methods.
- 4.Prototype: Bring the ideas to life with experiments, tests, and models to quickly check their viability.
- 5.Test: Validate the developed products and services, and adjust them to customer needs through extensive testing.
The Design Thinking framework is used in many different different branches, both to solve problems, as well as to develop products, processes, and roles.
Problem-solving, product development, process design
Variable: Typically up to 10 people
None specified, however, team members should have different skills and knowledge to provide teams with a range of perspectives
Reach innovative solutions through user-centric focus
Iterative Design Thinking process
User focus drives the development of solutions that users actually need/want
Iterative process enables continual improvement and adjustment
Promotes creativity and innovation
Can be used to address a range of different problems and challenges across various branches
Requires an open and collaborative work culture
Not all solutions are practical or economically feasible
Success depends on a team's composition and dynamic
Dynamic Systems Development Method (DSDM)
DSDM is one of the oldest agile frameworks and debuted in 1994. It's guided by eight principles that determine how it approaches both processes and decision-making. Among others, these include a focus on the business's needs, empowered teams, and incremental development.
At its core, DSDM takes an iterative and incremental approach to projects. This makes it possible to flexibly design a project's course as well as to quickly react to changing requirements over the following seven phases:
- 1.Pre-project conceptualization: Define the project's vision and goals.
- 2.Feasibility: Determine whether the project is feasible.
- 3.Business study: Identify the project's business aspects - Who will participate? What's the best work plan? What resources, tools, and techniques are required?
- 4.Functional model iteration: Everything discussed in the previous three phases is decided upon and prioritized; a functional prototype is created.
- 5.Design and build: The product is developed and deployed.
- 6.Implementation: In this phase, the product becomes operational.
- 7.Post-project: During this phase, the usefulness and results of the project are reflected upon, and any required maintenance is performed.
Project management, software development
Variable, but well-suited for small and large teams
Up to 12, divided between the project and development levels. These include business sponsor, business visionary, project manager, technical coordinator, business analyst, team leader, solution developer, and tester
Delivery of processes and products that meet a business's needs
Principles, roles, and processes
Iterative and incremental approach provides flexibility and adaptability
Strong stakeholder involvement
Plenty of transparency and control thanks to regular reviews
Focused on business needs
Requires engaged stakeholders, which can be problematic in some organizations
Discipline and self-management required
May be overkill for small projects
Comprehensive documentation needed
Frameworks for Agile Scaling
Scrum is one of the most commonly used agile frameworks. However, when a project or organization grows, Scrum's limitations in terms of team size become quickly apparent.
For that reason, a number of frameworks have been introduced that take different approaches to scaling Scrum to work in larger teams. Below, we'll introduce you to a few of these.
Scaled Agile Framework (SAFe)
SAFe is a comprehensive framework designed to scale agile practices at the corporate level. It's beneficial for those organizations that already work with Scrum but would like a framework to grow with them and their business.
This framework comes with a set of organizational and workflow patterns that allow multiple agile teams to work with one another in a coordinated and synchronized fashion. Individual teams are part of a sort of team of teams, referred to as an "agile release train" (ART). This can include anywhere from 50-125 people. As with Scrum, every team has a Scrum master and a product owner, however, there are also three new roles.
- A Release Train Engineer (RTE) serves as the ART team's coach and is responsible for stakeholder communication
- Product Management defines the product, connects with the customer, and manages and prioritizes the ART backlog
- A System Architect/ Engineer manages technical dependencies and develops the system's design
If that still isn't large enough for your needs, you can scale up with a Solution Train, which can accommodate up to 1,000 people. Every Solution Train is comprised of multiple ARTs.
There are, however, a number of factors that make SAFe a complex framework: These include its structure and processes, such as the fixed length of product increments (PI), and their elaborate planning. To ensure that its implementation is a success, the organization creates an implementation roadmap. At the same time, many organizations don't know how to effectively implement such a roadmap.
A SAFe roadmap helps businesses to properly implement the framework.
From 50 to 1,000 team members
Product owner, Scrum master, development team, release train engineer, product management, system architect/engineer
Agile scaling for large organizations
Framework structure, roadmap, PI planning, and other meetings
Supports coordinated and synchronized work among multiple agile teams
Clearly defined roles and responsibilities
Well-suited for large organizations
Good for customer requirements that have lots of dependencies
Model takes business and portfolio development into account
Lots of effort required for implementation since experts must train the entire organization
Complex owing to the large number of requirements, roles, and guidelines
Teams lose agility because of the extensive structures
Large Scale Scrum (LeSS)
Is Scrum too small for your organization? With LeSS, you'll have another framework to scale agility.
Here, less is more, since the framework deconstructs hierarchies to streamline management and roles. It's great for organizations with multiple teams that work together on the same product. As with SAFe, there are different scaling options: LeSS and LeSS Huge.
LeSS is envisioned for two to eight teams and includes basic Scrum principles that can be applied to a larger group. How does it differ from Scrum? A product owner is responsible for multiple Scrum teams, which, in turn, have either their own Scrum master or share one with up to two other teams.
LeSS Huge is designed for eight or more teams.
LeSS Huge attempts to reduce complexity when scaling.
To efficiently manage the various subject areas, the framework does add its own hierarchy: Area Product Owners (APOs) interact with both teams and the product owner, and are assigned to specific teams or areas.
Depending on the scaling model, 8 teams or more
Product owner, Scrum master, development team, area product owner
Keep agile scaling as straightforward as possible
Roles, Scrum principles, and events
Straightforward scaling models
Reduction of hierarchies makes it possible to more quickly finish work
Overview through a PO
Easy implementation that doesn't require additional training for teams that are familiar with Scrum
Portfolio and business development are overlooked
Requires a considerable amount of self-organization
Not for very large organizations
Nexus is another framework that helps to overcome the challenges of scaling Scrum. This concept, developed by Ken Schwaber and his Scrum.org team, focuses on the discovery and management of dependencies between teams, to improve delivery and integration.
It adds new roles and events to Scrum that apply to more than just a single Scrum team. Collaboration and communication between teams should be improved. Nexus is designed for use by three to nine Scrum teams and is rooted in Scrum principles and practices. Ultimately, its goal is to minimize complexity to the greatest extent possible.
Nexus can be used by three to nine Scrum teams.
Each Scrum team has its own Scrum master and together, creates a Nexus. This is then organized into a Nexus Integration Team (NIT), which has a product owner, a Scrum master, and several team members.
The NIT should identify and resolve dependencies, as well as assist in project direction and create framework conditions for Nexus.
There are other Nexus events, such as a daily, planning, and a retrospective. To involve more than nine teams, there's another scaling option, Nexus+. However, there isn't a concrete roadmap for its use in practice.
Agile scaling for Scrum
Up to 9 (Nexus) or 81 (Nexus+) teams
Product owner, Scrum master, development team, NIT team
Agile scaling without additional complexity
NIT team, Nexus events
Enhanced collaboration and communication between teams that work on the same projects
Clear roles and responsibilities
Dependencies are more visible and manageable
Easy to implement when teams are already familiar with Scrum
Significant effort owing to additional Nexus events
No solid Nexus+ concept; not ideal for very large organizations
NIT team acts as an additional level of hierarchy
Disciplined Agile (DA)
With the next model, it becomes clear just how much methods and frameworks overlap with one another in practice. In fact, this model isn't even a framework: Discipline Agile (DA) doesn't provide any implementation guidelines and instead offers a technique toolbox that businesses or organizations can use to scale their efforts in an agile way.
Scott Ambler and Mark Lines from IBM developed this hybrid approach that incorporates Scrum, agile modeling, lean software development, and other concepts. In practice, teams see DA as a process decision framework.
DA emphasizes the importance of a well-thought-out, planned approach. However, it also takes into account the fact that every organization is unique and requires its own strategy. For this reason, DA offers an assortment of best practices and lifecycles, known as "Ways of Working" (WoW) that businesses can use to craft their own approach. This adheres to the motto "Choose your own WoW!"
Individual agile scaling through flexible processes and techniques
Self-organization, selected methods from the toolbox
Can be flexibly adjusted to every corporate and organizational environment
Large selection of processes, techniques, and tools
Possible to measure scalability
Lots of configuration required owing to the large number of options
Requires extensive preparation and planning as well as experience in selecting techniques
Lack of standardization can impair communication when teams select different approaches
The Spotify Model is an agile framework that can promote creativity and efficiency in large organizations. The framework's name comes from the music streaming provider and is characterized by its multiple structures and roles:
The Spotify Model emphasizes team autonomy.
- 1.Squad: This is a team that independently works on projects and is responsible for a feature's development from start to finish. Like its military counterpart, a squad is usually composed of eight to ten people. According to Spotify, these should act like a mini-startup.
- 2.Product Owner: Every squad has a PO who can also assist in prioritization. They communicate with one another in order to create a roadmap.
- 3.Agile Coach: Each squad also has an agile coach, who helps with the selection and application of agile methods.
- 4.Tribe: Multiple squads that work in the same feature area form a Tribe, which can consist of 40-150 employees.
- 5.Tribe Lead: Every Tribe has a lead, who encourages communication and collaboration between squads.
- 6.Trio: The tribe lead, product lead, and design lead form the TPD trio. If scaling (an alliance), this trio becomes responsible for collaboration with other trios to align their tribes with one another.
- 7.Chapter: Specialists come together in a chapter, to share insights and experiences with one another.
- 8.Guild: This is a voluntary interest group in which those involved exchange knowledge and experiences with one another. Unlike a chapter, these span the entire organization.
Thanks to its encouragement of autonomy and individual responsibility among squads, the Spotify Model stresses creativity and innovation. Organizations that use it can also react quickly and efficiently to change.
Agile scaling model for large organizations
Squads can have 8-10 members, which are then organized into larger tribes and alliances
Product owner, agile coach, tribe lead, trio, and chapter/guild leader
Promote creativity and efficiency through greater autonomy; scale agility
Autonomy, meetings, roles
Promotes creativity and innovation through increased team autonomy
Enables an exchange of knowledge across all levels
Helps to react more quickly to changes
Encourages a positive work culture
Lots of configuration needed since there are many roles and team development is a must
Significant training required before introduction
Communication between autonomous squads takes time
Scrum@Scale was developed by Jeff Sutherland, the co-founder of Scrum. It helps large businesses to easily scale Scrum to their needs, across all organizational levels.
Up to five Scrum teams can work on a superordinate team, known as the Scrum of Scrums (SoS). In addition to the existing Scrum roles, there are two new ones: the Scrum of Scrum Master (SoSM) and the Chief Product Owner (CPO). New coordination events and processes promote meaningful communication between teams.
Should the teams continue to grow and more than 25 of them exist, the framework can be scaled up further.
Scrum@Scale is well-suited for very large organizations thanks to its structure.
The product owner cycle, which tackles the "What" of a project, is reflected in the Executive Meta Scrum (EMS) team. The Scrum master cycle, responsible for answering "How?", is seen in the Executive Action Team (EAT).
The highest hierarchy is known as SoSoS (Scrum of Scrum of Scrums), which can be scaled to an organization's needs.
Agile scaling model for medium-large organizations
SoS (up to 5 teams), SoSoS (25 teams or more)
Scrum master, product owner, developer team, Scrum of Scrum master, chief product owner, executive meta Scrum, executive action team
Scrum scaling within an entire organization
Events, roles, principles
Allows nearly endless scaling and is well-suited for very large organizations
Easy to implement and manage when teams are familiar with Scrum
Businesses can easily try it out prior to implementation
Significant coordination needed owing to hierarchies
Difficult to apply to non-software projects
Training required for businesses that haven't worked with Scrum
How to Choose the Right Framework?
As you can see, there are a number of different agile frameworks available. But which is the right one for you and your organization? The answer depends to a large extent on your individual needs and the goals of your business.
We advise that you keep the following factors in mind:
Organization and team size
Type of project and level of complexity
Corporate or organizational culture
Scrum and Kanban can both be used outside of software development. Large businesses will likely find the Spotify Model a reliable choice, as long as they want to encourage creativity and autonomy. Scrum@Scale is only viable for organizations that are familiar with Scrum and want to scale it to the corporate level.
If you're not certain, that's okay. Consult with experts who have worked with different models. An agile coach, for example, can help you to implement or scale agility to your business.
Agility is no longer just an IT buzzword: There are many different approaches that are applicable to a wide variety of different branches and business sizes. Each uses agility to encourage adaptability, speed in change response, more efficient processes, and a high level of employee satisfaction.
Choosing the "right" agile framework and scaling approach depends on your business's requirements and goals. Each has strengths and can be useful in a particular context. Keep in mind, however, that agility is not a cure-all. Instead, agility is a tool that, when used correctly, can help your business boost its efficiency and innovation.
Agile frameworks are models that businesses can use to help support the execution of projects and development processes. They offer structure and direction for those who intend to work with agile methods. Some frameworks also assist in scaling agility.
Agile methods include a series of different techniques and practices that help in the implementation of projects. Agile frameworks, on the other hand, offer a structure and guidelines, and either pair well with or include certain agile methods.
Agile scaling refers to how a business adapts agile methods as it grows or changes. When a team grows, agile scaling ensures that the existing frameworks can still be used.
There isn't a single "best" agile framework that's equally good for all businesses or organizations. Finding the right framework depends entirely on your business's needs and goals.