Agile Frameworks Overview: Comparing Best Practices

Agile frameworks overview

Starting from the problems of traditional methods, different approaches have been developed since the 1970s. Towards the end of the 1990s, agile approaches became more important and were used in many software projects. With the publication of the Agile Manifesto, its awareness increased and its influence on the software world increased enormously.

After the publication of the Agile Manifesto in 2001, the concept of agility moved into the focus of many companies. The focus is on increasing target quality, responding faster to changes, reducing lead times, releasing new product variants more frequently and reducing costs. It was easier for small and medium-sized companies to adopt and transform agile management. Scrum is the leading agile framework that offers the fastest transformation for companies of this scale.

The transformation of traditional culture in large companies has not been easy. For this reason, new methods for the agile transformation of large companies have been developed with the concept of scaled agility. The most popular framework for a scaled agile approach today is SAFe (Scaled Agile Framework).

What are the most popular agile frameworks?

An agile framework is a specific approach to planning, managing and running businesses. Agile frameworks generally fall into two categories: frameworks built for teams, and frameworks at scale, designed to help organizations implement Agile at scale across multiple teams.

Scrum-Framework

Scrum is a framework that has been used to manage the complex software development process since the early 1990s. The concept of Scrum is not a methodology or a process, but a framework in which different processes and techniques exist. Scrum was developed by Ken Schwaber and Jeff Sutherland and is derived from the term rugby. In rugby, players meet for short periods of time and exchange ideas to decide their next move in the game. In the game of rugby, team self-organization, leadership, and collaboration formed the basis of the term scrum.

So to be able to say that you use Scrum, it is necessary to go through all the steps in the framework. Scrum is based on empiricism and uses an incremental and iterative approach. There are three pillars that Scrum supports: transparency, observation and adaptation. The responsible teams work by giving these three issues the importance they deserve.

• Transparency: The work done by the entire team, the work to be done should be traceable. Everyone should be able to draw the same conclusions from what they see.
• Observation: Frequent observations are made to detect deviations from the project earlier. These observations are not made to slow down the work, but to maximize the value of the product that will emerge at the optimal level.
• Adjustment: If it is found that the product is not in the desired shape, the product or process should be corrected quickly. This correction should be made as soon as possible.

There are values that guide the work done in Scrum and help define the work ethic that the Scrum team should have. These Scrum values are listed as follows:

• Commitment: Scrum Team Members make a personal commitment to achieving the Scrum Goal.
• Courage: Scrum team members have the courage to work through difficult problems and take the right path.
• Focus: Everyone is focused on the work of the Sprint and the goal of the Scrum Team.
• Openness: The Scrum Team and its stakeholders agree to be open about the work and the challenges encountered during development.
• Respect: Scrum team members respect each other to be capable and independent individuals.

The Scrum framework consists of the Scrum Team, Roles, Activities, and Deliverables. Each component within the framework serves a specific purpose and is necessary for Scrum to be usable and successful. The Scrum Team manages the relationships and interactions between them by linking roles, activities, and deliverables.

Mandatory meetings during the Scrum process

1. Sprint Planning: In this meeting, the needs specified by the list of requirements are broken down into small threads by the development team. Each team member takes on these tasks according to their own schedule. The Product Owner, the Development Team, and the Scrum Expert participate in this meeting. Sprints: are planned in such a way that at the end of each sprint, there is a presentation to the product owner. On average, sprints are spaced one to three weeks apart.
2. Daily Scrum: This is a standing meeting, lasting about fifteen minutes, held at a fixed time every day at a pre-determined and standardized location. Team members join this meeting directly and the next 24 hours are scheduled. Each team member shares what they did the previous day, what they will be doing that day, and what issues are hindering their work. When a problem arises, the Scrum specialist strives to solve this problem. If a member of the team is late or absent from the meeting, this does not prevent the meeting. If there is no majority in the team, the meeting is simply canceled.
3. Sprint Evaluation: Conducted at the end of each Sprint and that Sprint is reviewed. An assessment is made of the resulting work product. The goal here is to see if the product is evolving in line with the needs of the owner.
4. Retrospective evaluation of the sprint: Here it is evaluated whether the work performed during the sprint achieves the expected quality and whether the work is carried out correctly. A priority item identified at the end of each meeting will be included in the next sprint planning meeting.

Kanban

Kanban is an agile method introduced by Toyota in the 1950s. It was first used in the software development process in 2004 by David J. Anderson with a team at Microsoft. Kanban focuses on continuous production and delivery. Kanban limits the number of jobs worked on at each stage of the software development process. Unlike Scrum, Kanban does not have a specific expiration time.

The next stage is not expected for the changes and can be intervened immediately depending on the priority. There are no special roles in Kanban. With Kanban, the focus is on visuals. The process is visualized and the board with the work packages named "Board" is visible to everyone. Kanban is preferred over Scrum to reduce the amount of work in progress, speed up change management, and improve visualization.

Extreme Programming (XP)

In 1996, the Extreme Programming method was developed as part of a project by Kent Beck and his friend at Chrysler. Extreme Programming is an engineering practice that helps software project teams develop bug-free and successful software when requirements are constantly changing and uncertainty is high. XP provides a simple but effective environment that enables teams to be highly productive.

In Extreme Programming, managers, clients, and developers work together, and project teams can self-organize to solve problems as efficiently as possible. The XP is based on 5 core values, 15 principles, and 12 practices.

The main features of XP are:

1. Ongoing development,
2. Continuous integration,
3. Short repetitions,
4. Publishing minor versions,
5. Get quick feedback,
6. Customer participation and feedback,
7. Continuous communication and coordination,
8. Pair programming,
9. Continuous testing.

With XP, the focus is on testing. Before coding is completed, test scenarios are prepared by the software development teams, coding is done, and then testing is done immediately. Software development cannot begin without knowledge of the scope of the test. Customers also create business-oriented, testable, and functional test scenarios for iterations, and the collected components are planned to pass all these tests successfully. In the case of unsuccessful test scenarios, this scenario can be dispensed with for cost and time reasons, depending on the customer's wishes. In XP, the customer collaborates with the continuous development team. This leads to strong communication, early detection of problems, and division of responsibilities.

Comparative interpretation of agile frameworks

Tailored agile frameworks

The main purpose of scaled agile approaches is to ensure coordination between teams in cases where there is more than one team, maintain portfolio loyalty between projects, and scale agility of large organizations. In these situations, where the number of teams increases and the portfolio needs to be managed, many organizational roles in the models used are changed and new roles are added.

The Most Popular Scaled Agile Frameworks are:

SAFe (Scaled Agile Framework)

SAFe is one of the agile development methodologies that provides guidance to overcome the challenges encountered in the development and deployment of large-scale projects with the shortest lead time. The Scaled Agile Framework is a set of best practices that draw on Lean and Agile approaches to bring together, synchronize and align Agile teams on larger projects in particular. SAFe's main philosophy is to create value - an organization's precious time should not be wasted on an application or user story that does not create value.

With the latest updated version 5.1, Scaled Agile Framework - SAFe offers four different configurations that can support different company sizes and development environments.

Scaled Agile Framework (SAFe®) Training

Explore Courses

❖ Essential SAFe: This is not only the basis of the SAFe approach but also the simplest starting point for implementation. Essential SAFe defines the critical elements necessary to better realize most of the benefits of the Scaled Agile Framework. In addition, Essential SAFe is the basic building block for all other SAFe configurations. The team and program layers form the organizational structure, called the Agile Release Train (ART), where agile teams, key stakeholders, and other resources are allocated to a critical and ongoing solution.

❖ Large Solution SAFe: Used for developing very complex and problematic solutions. Also, Large Solution SAFe includes multiple suppliers as well as ARTs, but not at the portfolio level. The model's solution train structure aims to help solve the development problems faced by organizations that develop large-scale, multidisciplinary software, hardware, and complex information technology systems. Organizations that develop standalone systems or that can be developed with a small number of implementers may not need this configuration.

❖ Portfolio SAFe: Configuring Portfolio Scaled Agile Framework helps align portfolio management and organizational strategy, taking into account the strategic value that development activities provide. It encompasses the people and processes that create the systems and solutions that the organization needs to achieve its strategic goals. Portfolio SAFe practices and principles provide a business agility framework for portfolio strategy, investment finance, agile portfolio management, and lean management. In large organizations, it is possible to implement multiple SAFe portfolio configurations.

❖ Full SAFe: This is the most comprehensive version of the framework. Suitable for organizations that require hundreds of employees or more, it enables the development and maintenance of large-scale integrated solutions spanning all SAFe layers (Team, Program, Solution, and Portfolio). In very large organizations, multiple instances of different SAFe configurations may be required.

Another definition derived from SAFe is DevOps teams:

DevOps is a set of technical practices that enable communication, integration, close collaboration, and automation. Derived from the combination and abbreviation of the development and operations of the word, this word refers to the harmonious and cooperative work of these two groups. Thus, ARTs can operate continuous production lines more efficiently. DevOps teams aim to increase the quality and frequency of deliveries, improve risk-taking and innovation, improve recycling times (revert bugs to old practice after deployment), reduce the frequency and severity of release failures, the times to reduce troubleshooting, and get products to market faster.

The fact that the Scaled Agile Framework can be used for large-scale agility and that we have more knowledge and experience about SAFe than other frameworks as well as the clearly defined framework principles, values, and practices and the minimum level of process gaps in the framework are effective makes SAFe agile Framework unbeatable.

LeSS (Large Scale Scrum)

LeSS was published in 2008 by Craig Larman and Bas Vodde and is a broad version of the Scrum technique. LeSS offers two different major Scrum frameworks. Most LeSS scaling elements focus on bringing all teams' attention to the whole product and not "my team". For LeSS, the end-to-end focus is perhaps the most important issue to solve when scaling.

Here are two frameworks that scale Scrum, which is basically a one-man team:

1. LeSS: Eight teams (more than eight each).
2. LeSS Huge: Up to several thousand people in one product.

This framework provides:

● Simplicity

● Scrum is scaled

● Be extensible from the bottom up at the desired scale, rather than harmonization spreading downwards.

● One of its features is that it uses feature sets and their advantages.

In addition to Scrum, LeSS has the following details:

● A single product backlog

● A done definition for all teams,

● A potentially moving Product Increment at the end of each Sprint,

● A Product Owner,

● A large number of complete, functional teams (without individual expert teams).

In LeSS, all teams work in a common sprint to deliver a common shippable product in each sprint.

The difference to Scrum is:

1. Sprint planning part 1: In addition to a product owner, it includes people from all teams. Allows team members to self-manage to decide on Product Backlog item sections. Team members also discuss ways to work together on particularly relevant topics.
2. Sprint Planning Part 2: It is done by each team independently (and often in parallel), but sometimes two or more teams can meet in the same room for easy coordination and learning.
3. Daily Scrum: Also conducted by each team independently, but Team A members increase knowledge sharing by observing Team B's Daily Scrum.
4. Coordination: Prioritizes communication with language.
5. General Product List Development: An optional short general product list development meeting may be held, attended by a Product Owner and people from all teams. The main goal is to decide which teams will implement which items and therefore select those items for later detailed development of product listings for individual teams. It's also a chance to improve alignment with the product owner and all teams.
6. Product backlog refinement: The only requirement in LeSS is a single-team product backlog as in single-team Scrum. However, a common and useful variation is the development of a multi-team product listing, where two or more teams are in the same room to improve learning and coordination.
7. Sprint Review: In addition to a product owner, includes people from all teams and relevant customers, users, and other stakeholders.
8. General Retrospective: A new non-Scrum meeting whose purpose is to examine overall system improvement, rather than solely focusing on how a team will perform better in subsequent sprints by looking at the relevant sprint. The maximum session length is 45 minutes per week. It includes the Product Owner, the Scrum Masters, and the recurring representatives of each team.

SoS (Scrum of Scrums)

It's a scaled, agile approach defined by Ken Schwaber in 2004. Essentially, this approach is an evolution of the Scrum framework previously described. In contrast, SoS refers to the meetings held with the upstream team in addition to the daily meetings of SoS' normal Scrum teams. SoS is a team formed by selecting one or two ambassadors from each Scrum Team when more than one Scrum Team needs to coordinate. This team meets daily, weekly, or monthly at the frequency determined by the team itself and conducts similar meetings to the daily Scrum meetings described in the Scrum framework.

The agenda items of the SoS meetings are as follows:

● What each team has accomplished since the last meeting

● What each team will work on (commit to finalize) by the next meeting.

● Which risks, problems, and obstacles affect other teams?

● Dependencies between the teams' work and their current status

These meetings also avoid the risk of teams doing additional (unnecessary) work in equal measure. The duration of the SoS meetings can still be determined by the team. It is adjusted according to the number of Scrum teams included in the SoS. Although there is no limit to the number of teams that should be included in the SoS, the practice has shown that when more than 10 teams are involved, meeting times increase, and members cannot focus on the meeting.

DAD (Disciplined Agile Delivery)

DAD is a process-oriented, learning, and solution-oriented framework published by Scott Ambler in 2007. Key features of this framework are:

1. Creating corporate awareness
2. Concentrate on learning
3. Be solution-oriented
4. First have a human philosophy
5. Have a hybrid structure
6. Have a risk-assessed lifecycle
7. Be goal-oriented
8. Visualize the end-to-end deployment lifecycle

Essentially, this framework was created to fill the process gaps that were not defined in Scrum. What makes the DAD framework hybrid is that it is fueled by many methods such as agile modeling, Kanban, edge programming, and lean software development. The roles in the DAD framework are largely similar to Scrum.

Unlike Scrum, the DAD framework has a team leader role. The definition of the role is a mixture of the Scrum Master role in Scrum and the role of the architectural owner in agile techniques. The team leader is the person who always knows the architecture and DAD process, and directs and guides the team.

The roles of the product owner and team member in DAD are the same as in Scrum. There are also secondary roles in DAD, these are: independent testing expert, domain expert, technical expert, and adapter (integrator).

The DAD framework is a goal-oriented framework. Different goals are defined in each phase of DAD. If we list these goals under the phases of DAD, they are as follows:

Goals of the initial phase:

1. Creation of the starter/first team
2. Creating the overall vision
3. Be consistent with the company's vision
4. Exploring the first scope
5. Define the initial technical strategy
6. Development of the first release plan
7. Find funds
8. Determination of the work environment
9. Identify risks

Build phase goals

● Generation of a possible consumption solution

● Taking into account the changing needs of stakeholders

● Transition to deliverable version

● Quality improvement

Goals of the transition phase

● Make the solution usable

● Presentation/deployment of the solution

Continuous goals while DAD

● Feed team members

● Coping with the team task

● Use (use) and improve the existing structure

● Risk Reduction

● Improvement of team processes and environment

● Coordinate activities

Since DAD is a learning-oriented framework, the loops are operated in each iteration in a way that also increases the learning abilities of the team members within the DAD. The people-first philosophy of DAD aims to value team members, to strengthen them as in other agile methods, to increase their self-confidence, and thus to form self-organized agile teams with decision-making power.

Scrum@Scale

The Scrum@Scale framework was created by Jeff Sutherland, one of the creators of the Agile Manifesto, which lays out the values and principles of the Agile mindset. Scrum@Scale is a framework that enables organizations to achieve business agility and create greater impact by extending the Scrum framework to teams. Scrum@Scale strives to deliver products and services of the highest possible value while supporting team networks across industries and disciplines to tackle complex problems.

Scrum@Scale provides the tools companies need to build high-performing teams. It enables their teams to work at a sustainable pace while adding value to the client. Scrum@Scale extends the Scrum framework to deliver productive outcomes across industries and disciplines, including software, hardware, services, operations, and R&D (research and development).

While Scrum provides a framework for the development and maintenance of complex products by a single team, Scrum@Scale (S@S) focuses on the entire ecosystem of teams to change the entire corporate culture. The Scrum@Scale approach is based on building a healthy Scrum team and positively influencing change throughout the organization.

SAFe® Scrum Master   Training

Visit Course

The Basic Concepts of Scrum@Scale are:

1. Small Teams: Small teams are critical not only for Scrum but also for Scrum@Scale. If there is more than one team, each team must consist of three to nine members.
2. Scaling across the organization: The better each team works, the more likely Scrum@Scale is to succeed.
3. Implementation of the minimum applicable bureaucracy: The minimum time required to make and implement decisions helps to overcome obstacles in a short time.

The same meetings as in the Scrum process are also available in Scrum@Scale.

● The sprint

● Sprint planning

● Scaled Daily Scrum

● Sprint Review

● Retrospective

The only difference to Scrum here is the Scaled Daily Scrum. Like the Daily Scrum in Scrum, it is a daily meeting that a representative of each team must attend. Participation of the entire team is not required. It is enough if someone is present who knows what is going on in their team.

The Scaled Daily Scrum is a 15-minute meeting that brings members together to discuss bottlenecks or issues that might be preventing teams from meeting their sprint goals, share knowledge, and maintain transparency and trust between all teams.

Scrum@Scale roles:

Since Scrum@Scale is based on Scrum, it uses the Product Owner and Scrum Manager roles which are the same competencies defined in the Scrum Guide. Various responsibilities are exercised on a larger scale. There are two main roles in this scaled framework: the Scrum of Scrums Master (SoSM), who is responsible for the Scrum Master cycle, and the Chief Product Owner (CPO), who is responsible for the product owner cycle. These roles are similar to the Product Owner and Scrum Manager positions in other Scrum methodologies.

• Chief Product Owner (CPO): The Chief Product Owner is responsible for setting the overall direction of the product. The role of the CPO is very similar to that of the PO, but only up to a point. This role helps coordinate production across multiple teams. CPOs also coordinate priorities between different POs working with individual teams. The CPO is responsible for creating a single backlog for everyone. They work with SoSM to ensure all teams are working towards the same goal and that each team understands what they need to do.
• Scrum of Scrums Master (SoSM): Responsible for coordinating the efforts of multiple Scrum teams. He acts primarily as a link between teams and helps to resolve any dependencies or conflicts that may arise. In addition, SoSM is responsible for ensuring that each team has the resources it needs. As a Scrum Master, he is responsible for collaborative release efforts and similar tasks.

Scaling Scrum of Scrums (SoS)

Depending on the size of the organization or application, multiple SoS may be required to deploy a very complex product. In such cases, a Scrum of Scrums (SoSoS) can be created among many SoSs. The SM organization (SoS, SoSoS, and EAT) works as a whole to complement the other components of the Scrum Master cycle.

Executive Action Team (EAT)

When Scrum is scaled, organizational problems can multiply. In this case, Scrum@Scale needs an Executive Action Team (EAT). The function of the Executive Action Team is to coordinate a large number of SoS (or SoSoSs). This team is responsible for the transformation strategy and has the implementation of Scrum values, roles, and support in decision-making and removing barriers. An important prerequisite for EAT is the will and power of the top executives to change the organization.

Executive MetaScrum (EMT)

The Executive MetaScrum Team (EMT) has the organizational vision and sets strategic priorities for the organization. Just as SoSs can grow as SoSoS, MetaScrums can expand through the same mechanism. This team is responsible for changing organizational direction or deciding which products or services need to be restructured or discontinued. It further aligns business with a roadmap and can be maintained at a regular or transient pace.

This team consists of financial, human resources, and customer commitments of the CPO and the business owner. EMT and CPO work closely together to address necessary changes in strategy, funding, or resource allocation.

Nexus

The Nexus framework is a scaled agile framework created by Ken Swabber and published by Scrum.org in 2015. According to the Nexus Guide, Nexus is a framework that connects the work of approximately three to nine development teams working on a single product backlog to create an integrated product piece that serves a specific purpose and is made up of roles, activities, artifacts, and rules.

It is recommended to have a maximum of 9 and a minimum of 3 scrum teams in a Nexus team. Any number of Nexus teams can be set up within an organization, depending on the size of the organization and the number of products to be developed.

Nexus extends Scrum with a new role and some advanced events and artifacts.

The first of the roles defined with Nexus is the Nexus Integration Team (NIT). The Nexus integration team deals with the resolution of any technical or non-technical integration issues between Scrum teams. These include problems, risks, obstacles, and dependencies. Members of this team may also work in different roles within Scrum teams, but should always prioritize the integration team's work first. Because any problem that will disrupt the functioning of the teams is much more important. This team consists of the Product Owner, a Scrum Master, and elected representative members. The NIT may change over time, except for the product owner.

There are three works defined by the Nexus framework:

1. Nexus Target,

2. Nexus Sprint Backlog and

3. Integrated product part.

The Nexus Goal is a common goal for all Nexus teams. The Nexus Sprint Backlog is the result of the first session of the Nexus Sprint planning meetings. This list is the sum of the work items that all Scrum Teams have committed to completing in this Sprint. They are updated with daily Nexus meetings. The integrated product part is the final output of Nexus.

At the end of each sprint, each Nexus team must produce a functional, value-added product piece that can be integrated into the core product. The integrated product part is presented to the stakeholders at the Nexus Sprint Review Meeting, which takes place at the end of each Sprint. This part of the product is expected to meet the definition of Done.

Activities identified with Nexus are:

● Nexus Sprint Planning,

● Nexus Daily Scrum,

● Nexus Sprint Review and

● Nexus Sprint Retrospective Meetings.

These meetings are also timed events as specified in the Scrum framework.

The principles and values that apply in Scrum also apply in Nexus. The main principle of Nexus is that the teams, and how they function, work and communicate are transparent. Nexus has absolutely no place for information hiding, trying to make mistakes invisible, and opaque behaviors like customer misinformation.

Agile scaling @ Spotify

As Spotify's development teams worked to increase their agility, they shared their experiences and knowledge. Now, their documented practices, known as the Spotify model, are inspiring many software companies to better organize their work.

The Spotify model is a human-centric, autonomous approach to scaling agility that emphasizes the importance of culture and networks. This model has helped Spotify and other organizations drive innovation and productivity with an emphasis on autonomy, communication, accountability, and quality.

Spotify Squad

The basic development unit at Spotify is Squad. The squad is structured similarly to the Scrum team. This team, which carries out design, development, and testing activities together, is a self-organized team (8 members or fewer) using agile frameworks, some Scrum, others Kanban or a mixture of both. Not every squad has an officially appointed team leader. However, there is a product owner.

This structure increases autonomy which makes people happier as it is a powerful source of motivation. In addition, the structure in squads is fast, avoiding approval systems, decision bottlenecks at the top, and dependencies on other teams. The Product Owner is responsible for prioritizing the work to be done. How the work is done is not his responsibility. A team can also have access to an agile coach to help them develop and improve the way they work. Spotify has renamed the Scrum Master in Scrum to "Agile Coach". Coaches hold retrospectives, sprint planning meetings, and one-on-one coaching.

Spotify Tribe

Another structure in Spotify is expressed by tribes. There is a Tribes Leader who is responsible for providing the best possible living space for these structures formed by the coming together of multiple squads. Tribes are designed to be smaller than 100 people. A tribe consists of squad groups that work in related areas such as the backend system infrastructure.

Chapter and Guild roles are also available on Spotify. A chapter is defined as a small family of people from the same tribe with similar skills and the same specialty (that's the glue that holds the company together). Each chapter meets regularly to discuss specific issues related to its area of expertise. For example chapter test engineers, chapter web developers, or chapter backend.

The Guild is an "interest group" made up of people who wish to share knowledge, tools, code, and practices more organically and with greater participation. Guilds usually encompass the entire organization, while chapters are always a group within the tribe's locale. Some examples of guilds are Web Technology Guild, Test Engineers Guild, Agile Coaches Guild, etc. in fact Spotify is a kind of matrix organization.

Spotify System Owner

The risk of this model is that the infrastructure of the system will collapse if nobody focuses on the integration of the system as a whole. To prevent this, another role, the “system owner”, comes into play. All systems have one or two system owners. The system owner is the person(s) who will be contacted in case of technical or architectural problems related to the system. This person is the coordinator and directs those who develop the codes on the system. The System Owner focuses on issues such as quality, documentation, technical debt, stability, scalability, and the rollout process, among others.

Conclusion

In summary, there are many different agile frameworks that can be used depending on the situation and requirements. Each framework has its own pros and cons, and it's important to choose the right framework for your project and team.

If you want to learn more about what agile frameworks exist and how they can be used in project management, we recommend our "Scaled Agile Framework" page. Here you will find various SAFe courses, including our "Leading SAFe" course, which teaches you the basics of Agility and SAFe and prepares you for the corresponding SAFe certifications.

And if you also want to expand your knowledge and skills in other IT areas, have a look at our "Academy" page. There you will find a variety of training courses and certifications on various IT topics, including agile methods. We look forward to helping you achieve your career goals!

SOURCES

• Scrum.org. (n.d.). scrum https://www.scrum.org/
• Scrum.org. (2020). The Scrum Guide. https://scrumguides.org/scrum-guide.html
• Scrum Inc. (n.d.). Scrum Inc. https://www.scruminc.com/
• Scaled Agile, Inc. (n.d.). Scaled Agile Framework. https://www.scaledagileframework.com/
• Scaled Agile, Inc. (2023). Scaling Agile [website]. https://scaledagile.com/
• Kanban University. (n.d.). Kanban Guide. https://kanban.university/kanban-guide/
• Extreme programming. (n.d.). extreme programming. http://www.extremeprogramming.org/
• Large-Scrum Scrum (LeSS). (n.d.). Large-Scrum Scrum (LeSS). https://less.works/
• Most agile (n.d.). most agile https://www.agilest.org/
• Agile modelling. (n.d.). agile modelling. http://agilemodeling.com/
• OpenXcell. (2019, February 19). Disciplined Agile Delivery - A Comprehensive Guide. https://www.openxcell.com/blog/disciplined-agile-delivery/
• Methods & Tools. (2014, March 1st). Introduction to Agile Methods [website]. https://www.methodsandtools.com/archive/archive.php?id=104
• Scrum@Scale. (n.d.). Scrum@Scale. https://www.scrumatscale.com/
• Scrum.org. (n.d.). The Online Nexus Guide. https://www.scrum.org/resources/online-nexus-guide
• Spotify. (2012, November 21). Engineering culture [blog post]. https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf