There’s no hiding from Scrum. Pick a random software team and you’re likely to spot some elements of Scrum blended into their daily routine. Open the fridge and you’ll probably find your veggies running a daily standup under the watchful eye of your peanut butter jar.

Part of it is because Scrum gives teams an easy-to-implement approach to solving difficult problems. It’s quite universal and can be used in various industries, and with various professions involved.

While developing different products at Railsware, we’ve realized that one approach isn’t the right approach every time though. Different products and different circumstances require different ways of tackling a problem.

That’s why we’ve decided to gather a list of Scrum methodology alternatives that we believe address many of the issues that Scrum doesn’t.

You won’t find Kanban on the list, even though it meets this condition. It’s already used by more than half of the teams running on Scrum, and you probably already know how to implement it very well. And, if you don’t, Kanbanize has got you covered.

Everything else that we thought was worth your attention is here. So let’s begin!

Scrum of Scrums

The first approach is very easy to implement for teams already using Scrum. It’s sort of an add-on to traditional Scrum practices that makes it possible for several teams to stay in sync without changing anything in the daily routine of most team members.

Traditional Scrum teams shouldn’t include more than 7-9 people at a time. Above this number, the cooperation becomes ineffective and the duration of even daily syncs is close to unbearable.

For this reason, teams can take advantage of Scrum of Scrums. Under this approach, Scrum teams follow their usual rituals and run 2-4 week-long sprints as they used to. On top of that, each team delegates 1-2 members to attend an additional meeting – the Scrum of Scrums.

This way, representatives from each group join once or twice a week to discuss what’s been done, what the plans are, and how to best handle the dependencies between the teams.

Roles in Scrum of Scrums

• 1-2 members from each Scrum team – these are typically Scrum Masters and Product Owners, but teams can delegate different roles to a meeting too. Roles that are dependent on external resources should be especially considered for participation.
• Supplier – this role is defined as an external stakeholder that members of Scrum teams depend on. This can be, for example, a representative of another team (it doesn’t matter if that team works on Scrum or not) that’s working on a functionality that is essential for teams involved in SoS.
• Consultant – this optional role also involves an external stakeholder. It can be a technical leader or an expert in some field that the participants could use inputs from. The person may also join to simply stay in sync with whatever is happening and plan their/others’ priorities based on that.

How Scrum of Scrums works

The agenda is very similar to the typical Scrum daily sync. Each representative of a scrum team answers these three questions:

• What have we done since the last sync, and how does it impact the other teams?
• What are we going to do, and what is the impact going to be?
• What are the obstacles we’re facing, or anticipate we’ll be facing?

The meeting takes longer, typically 45 to 60 minutes. Reporting on done/plans is secondary and shouldn’t be focused on too much. The key of this meeting is to define and address touchpoints between teams and potential obstacles they may be facing.

Pros of Scrum of Scrums

• Very easy to implement for teams already working in Scrum.
• Doesn’t impact most of the team members in any way (as they’re not involved).
• Works well for up to 25-30 people involved within a few teams.

Cons of Scrum of Scrums

• More difficult (but not impossible) in larger organizations with many teams involved.
• Doesn’t specify how to approach artifacts of Scrum – product/team backlog, planning meetings, etc.

SAFe (Scaled Agile Framework)

As the organizations grow, Scrum of Scrums becomes more difficult to run. There are simply too many stakeholders involved, and dependencies between them cannot be sorted out in a single meeting. This is when SAFe enters the picture.

It’s an entire framework that tells organizations how to run projects in a lean and agile way. SAFe specifies various processes and describes the roles involved in each. It gives an organization guidance on running each of the four key aspects – Team, Program, Large Solution and Portfolio – in the most effective way.

Scaled Agile Framework is meant to improve the time and quality of each delivery, as well as boost employees’ engagement and productivity.

Roles in SAFe

There are plenty, and they depend on the level of focus:

• Team level – Agile team, Product Owner and Scrum Master
• Program level – Product Manager, Business Owner, Release Train Engineer, and System Architect/Engineer
• Solution level – Solution Manager, Solution Architect/Engineer, and Solution Train Engineer
• Portfolio level – Epic Owner and Enterprise Architect

How SAFe works

SAFe may look complicated at first. But a lot of what happens during SAFe will be familiar if you’re used to typical Scrum procedures.

The framework comes with four options, each suitable for a different number of participants. The most basic, aptly named ‘Essential’, will work for 50 to 125 folks, though 40 or 150 may also make use of it.

As the number of team members grows, so does the complexity of SAFe and the number of processes. Other available setups are ‘Portfolio’, ‘Large Solution’ and ‘Full Configuration’. Full Configuration is said to be suitable for an organization of 20,000 people.

The higher the complexity, the more different roles will be involved. For reference, follow the links to the roles we included above and review the SAFe White Paper along with the available resources.

Pros of SAFe

• Suitable for a wide array of organizations, from those consisting of just a few teams to large corporations with thousands of employees.
• Enables multi-team collaboration and alignment.
• The framework is constantly being developed, using the feedback from thousands of practitioners. Currently in its 5.0 release.
• Extensive knowledge base.
• Large network of certified trainers and courses.

Cons of SAFe

• Relatively complex compared to other frameworks.
• Limited flexibility and decision making for most participants.
• Longer feedback loops and lowered ability to react to changes, and longer planning cycles.
• The entire organization needs to work on SAFe and there’s no flexibility for teams to adopt it individually or use a different methodology.

LeSS (Large-Scale Scrum)

If it’s a bit too much and you’re already looking for SAFe Scrum alternatives, you’ve got to admit LeSS sounds promising (judging by the name, at least). It’s a lightweight framework that’s meant to help you scale good ol’ Scrum to more than one team. LeSS is suitable for 2 to 8 teams, while its twin brother, LeSS Huge, can cater for even thousands of participants.

LeSS puts less focus on the enforcement of rules, rituals or processes than SAFe. It also specifies fewer roles, and the ones it does are very well known from regular Scrum practices.

Roles in LeSS

• Product Owner – in charge of an entire product that multiple teams work on.
• Scrum Masters – run Scrum rituals with the teams and also coordinate with Product Owners and other Scrum Masters. One SM can work with more than one team.

How LeSS works

Spring planning in LeSS happens in two separate meetings.

In the first one, a Product Owner meets with the delegates from each participating team. They divide items from the Product Backlog between them, with the assumption that more than one team can share a particular deliverable.

The second meeting is the traditional Scrum planning within each team, where members commit to delivering specific tasks in the upcoming sprint. Often, team meetings can happen physically near to each other so that teams sharing responsibilities can easily coordinate the planning.

Daily Scrums also happen independently, with the caveat that, for the sake of better coordination, members of either team can join other teams’ standups in the role of passive listeners.

LeSS Huge

As we mentioned, there’s also LeSS Huge for a larger number of teams (8+), when a planning meeting with a representative of each team is no longer an option.

In many ways, it’s similar to LeSS. However, a new concept is introduced – Requirement Areas (RA). These are major areas that define the key parts of a product being shipped. They’re dynamic and can change over time – two can merge or one can be split into several smaller areas. Ultimately, new areas can just appear or disappear as the product grows.

Since the structure is much bigger than it was in LeSS (each area typically has 4-8 teams working on it), it calls for new roles to supervise the execution. That’s why each area has its own Area Product Owner, who takes the very same role a Product Owner had in LeSS. And, above all, there’s one Product Owner coordinating with POs from each area.

Pros of LeSS and LeSS Huge

• Scalable from just a few teams to even hundreds of them.
• Very easy to implement, especially on a smaller scale. Most practises mimic the typical Scrum processes.
• Members are empowered to make decisions.
• A lot of flexibility to adjust to the changing situation, and also to add or remove areas as the circumstances dictate.

Cons of LeSS and LeSS Huge

• Difficult to work with if there are heavy dependencies between teams.
• Location-specific ceremonies, hard to use LeSS with remote or multi-location teams.
• A single Product Owner may be overseeing hundreds if not thousands of participants (indirectly).

Nexus

Another framework, or more of an add-on to Scrum, is Nexus. It allows you to scale Scrum to the point of around 100 participants and effectively manage dependencies between teams. 3 to 9 teams are typically involved in Nexus.

This framework is similar in many ways to Scrum of Scrums, but it introduces a new structure for smoothing out the cooperation between teams – the Integration Team.

Roles in Nexus

• Product Owner – handles the entire Nexus Product Backlog.
• Scrum Masters – for each team involved.
• Nexus Team – gathering one or two members from each Scrum team, responsible for planning the bigger picture of the product and coordinating with other Scrum teams.
• Nexus Integration Team – an external structure that makes sure the teams are well coordinated and that blockers are resolved quickly. Members of this team can be external trainers, product leads or other positions not directly involved in Scrum teams.

How Nexus works

As was the case with SoS and LeSS, a Product Owner meets with representatives from each team to determine the items from the Product Backlog that will be tackled in an upcoming sprint. Teams should try to pick tasks with as few dependencies on the others as possible, communicating with each other when doing so. By the end of the meeting, the shared backlog is created and participants define goals for the upcoming sprints.

As the sprint gets underway, Daily Scrums happen in the teams. A part of a daily routine is also Daily Integration, during which representatives of each team communicate any challenges they’re facing and resolve dependency issues with the help of the Integration Team.

At the end of the sprint, Scrum teams meet with the product owners to review what was and wasn’t done during the sprint. No individual team sprint reviews are held.

Pros of Nexus

• Very similar to other Scrum add-ons and, as such, easy to adapt.
• Very focused on tackling dependency issues and suitable for projects where teams need to actively cooperate.

Cons of Nexus

• Integration Team is not involved in the development, not contributing to the product.
• Limited to only about 9 teams and 100 people (though a LeSS Huge-style iteration is being developed).

XP (Extreme Programming)

Extreme Programming is another Agile framework for quickly shipping products. It was the dominant approach back in the 90s, as well as the 2000s. Today, it has lost a bit of its momentum and fallen behind some of the Scrum practises we have already covered. But many of its elements are still widely used in thousands of development teams.

XP introduces very short, 1-2 week-long sprints during which teams aim to quickly ship new iterations, get feedback from users, iterate on it, and ship again. XP values adaptability over predictability and is most suitable for an environment where requirements change dynamically. Change is seen as an opportunity rather than a challenge.

XP is also big on engineering practices that it introduces and encourages all practitioners to follow. These include pair programming, automated testing, simplicity in design, test-driven development, refactoring, and many others.

Roles in XP

• Customer – represents a customer, creates user stories, and sets priorities for the team.
• Tracker – monitors the progress of software development, makes sure everything’s going as expected.
• Programmer – defines the tasks prioritized by the customer, estimates them, and codes them into a project.
• Tester – takes responsibility for testing the code and ensuring its quality.
• Coach – supervises the team, runs daily and weekly meetings, and ensures the team implements the best practices. They’re also responsible for passing the information to the Tracker.

How XP works

The process starts with the team describing user stories – the desired results of a project. These are then estimated and prioritized. With this information, the team moves on to creating a release plan and defining the key features of the future code.

The development team then gets to coding the solution in short sprints and refactoring it on the go. Simultaneously, unit testing, as well as customer acceptance testing, happens, with the information flowing between both roles on a regular basis.

At the end of a sprint (typically by the end of a week), a sprint summary is held. The aim is to sum up the progress, hear user feedback, and break down the tasks for the following weeks. The next sprint then follows.

Pros of Extreme Programming

• Very quick sprints allow teams to quickly react to changing requirements.
• XP puts a strong focus on improving the quality of programming, introducing a number of techniques that have gained a wide popularity among developers.
• Feedback loops are heavily reduced, with the active participation of customer feedback in the daily work.
• Continuous development, new iterations (nearly) every week.

Cons of Extreme Programming

• Scalability issues, difficult to use with more than a few teams.
• Too much focus on delivering code and little attention to the design of a product and its usability.
• Difficult when a client is in a very different time zone and cannot actively participate in the process. Can also cause difficulties in distributed teams.

Crystal

Crystal is a collection of methods for product development. Contrary to Scrum-related methods we already covered, Crystal prioritizes the team that’s going to deliver a project over the processes it is to follow.

This conclusion came to Crystal’s creator, Alistair Cockburn, after he ran detailed research on teams developing IBM products in the 90s. Eventually, he concluded that teams that were the most successful didn’t necessarily have great processes in place. Instead, they collaborated and communicated in an efficient way, and these human-centered qualities allowed them to understand their clients and ship the right products.

Crystal framework is built on two beliefs:
* Each project is unique and is constantly changing. As such, it’s not possible to create universal processes that will always work.
* Because of that, teams should be trusted to improve their processes and determine how to best tackle a project.

Crystal is a family of multiple methods, each represented with a different color. Different colors are suitable for different numbers of people involved. The complexity of each project is also taken into consideration.

Some Crystal colors include:

• Crystal Clear
• Crystal Yellow
• Crystal Orange
• Crystal Red
• Crystal Maroon
• Crystal Diamond
• Crystal Sapphire

In general, the suggested maximum number of people for each of the methods is shown in the chart below:

Diamond and Sapphire Crystals can also be used for the most critical projects, regardless of the number of participants.

Roles in Crystal

There can be a number of roles in the most complex methods, including the likes of Architect, Requirements Gatherer, Design Mentor or Technical Facilitator. The most basic method, Crystal Clear, indicates the need for four different roles:

• Sponsor – allocates funds to run a project.
• Expert user – tests a product and provides regular feedback.
• Lead designer – takes the role of a technical lead.
• Designer-Programmer – handles both design and coding.

How Crystal works

Crystal methods follow Agile practices for delivering new iterations. Without external supervision, the teams decide which items they want to include in the next iterations. The frequency of releases is not fixed and can vary from a week to even 2-3 months, depending on the complexity of the project.

By releasing frequently, Crystal teams aim to quickly test an iteration and give it to users to try and provide feedback. Sometimes though, it may not be feasible to release each new iteration right away. That’s why there can be more than one iteration being worked on at a time.

Crystal focuses on a number of practices, mainly involving inter-human relations within a team. As there are no strict processes in place, teams also regularly take a break from development and reflect on how the process can be improved.

Pros of Crystal

• Adaptive approach lets teams quickly adjust their approach in light of changing requirements.
• Can be used with other Scrum or non-Scrum methodologies.
• Empowers team members to find the way to work most effectively.
• Because there are a number of variations available, Crystal will work well for a few participants, as well as for 100 of them (or even more).

Cons of Crystal

• Only suitable for more experienced teams that can build their own processes without external guidance.
• Crystal Colors can’t be changed while the project is underway.
• May be difficult for distributed teams due to its focus on constant communication.

BRIDGeS for decision-making and ideation

Regardless of which Scrum alternative you choose, we highly recommend using BRIDGeS during agile product development. BRIDGeS is a robust framework for ideation and decision-making crafted by Railsware. It’s ideal for helping product managers, owners, and other stakeholders solve problems quickly and creatively.

BRIDGeS has a simple setup (virtual whiteboard and cards to keep track of benefits, risks, issues, and more). It’s easy for remote teams to collaborate in real-time (check out this free Figma template).

During a session, you and your carefully-chosen team of experts will move from the Problem Space to the Solution Space. Everyone has a chance to contribute, but the structured nature of the session ensures you don’t spend too much time lingering on the problem. So, at the end of a BRIDGeS session, you will have a list of epics and nested tasks that can be added to your Jira board. This means that participants (and/or your development team) can start implementing the solution almost immediately.

Visit our dedicated BRIDGeS page to find out more about how it works and how to prepare for a session.