![\"Scrum-Alternatives\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2020\/03\/Scrum-Alternatives-Illustration-r.jpg\")
<\/p>\nThere\u2019s no hiding from Scrum. Pick a random software team and you\u2019re likely to spot some elements of Scrum blended into their daily routine. Open the fridge and you\u2019ll probably find your veggies running a daily standup under the watchful eye of your peanut butter jar.<\/p>\n
Part of it is because Scrum gives teams an easy-to-implement approach to solving difficult problems. It\u2019s quite universal and can be used in various industries, and with various professions involved.<\/p>\n
<\/p>\n
While developing different products at Railsware, we\u2019ve realized that one approach isn\u2019t the right approach every time though. Different products and different circumstances require different ways of tackling a problem.<\/p>\n
That\u2019s why we\u2019ve decided to gather a list of Scrum methodology alternatives that we believe address many of the issues that Scrum doesn\u2019t.<\/p>\n
You won\u2019t find Kanban on the list, even though it meets this condition. It\u2019s 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\u2019t, Kanbanize has got you covered<\/a>.<\/p>\n Everything else that we thought was worth your attention is here. So let\u2019s begin!<\/p>\n The first approach is very easy to implement for teams already using Scrum. It\u2019s 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.<\/p>\n Traditional Scrum teams shouldn\u2019t 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.<\/p>\n 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 \u2013 the Scrum of Scrums.<\/p>\n This way, representatives from each group join once or twice a week to discuss what\u2019s been done, what the plans are, and how to best handle the dependencies between the teams.<\/p>\n The agenda is very similar to the typical Scrum daily sync. Each representative of a scrum team answers these three questions:<\/p>\n The meeting takes longer, typically 45 to 60 minutes. Reporting on done\/plans is secondary and shouldn\u2019t 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.<\/p>\n 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.<\/p>\n It\u2019s 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 \u2013 Team, Program, Large Solution and Portfolio \u2013 in the most effective way.<\/p>\n Scaled Agile Framework is meant to improve the time and quality of each delivery, as well as boost employees\u2019 engagement and productivity.<\/p>\n There are plenty, and they depend on the level of focus:<\/p>\n SAFe may look complicated at first. But a lot of what happens during SAFe will be familiar if you\u2019re used to typical Scrum procedures.<\/p>\n The framework comes with four options, each suitable for a different number of participants. The most basic, aptly named \u2018Essential\u2019, will work for 50 to 125 folks, though 40 or 150 may also make use of it.<\/p>\n As the number of team members grows, so does the complexity of SAFe and the number of processes. Other available setups are \u2018Portfolio\u2019, \u2018Large Solution\u2019 and \u2018Full Configuration\u2019. Full Configuration is said to be suitable for an organization of 20,000 people.<\/p>\n 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.<\/p>\n If it\u2019s a bit too much and you\u2019re already looking for SAFe Scrum alternatives, you\u2019ve got to admit LeSS sounds promising (judging by the name, at least). It\u2019s a lightweight framework that\u2019s meant to help you scale good ol\u2019 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.<\/p>\n 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.<\/p>\n Spring planning in LeSS happens in two separate meetings.<\/p>\n 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.<\/p>\n 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.<\/p>\n Daily Scrums also happen independently, with the caveat that, for the sake of better coordination, members of either team can join other teams\u2019 standups in the role of passive listeners.<\/p>\n As we mentioned, there\u2019s 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.<\/p>\n In many ways, it\u2019s similar to LeSS. However, a new concept is introduced \u2013 Requirement Areas (RA). These are major areas that define the key parts of a product being shipped. They\u2019re dynamic and can change over time \u2013 two can merge or one can be split into several smaller areas. Ultimately, new areas can just appear or disappear as the product grows.<\/p>\n 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\u2019s 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\u2019s one Product Owner coordinating with POs from each area.<\/p>\n 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.<\/p>\n This framework is similar in many ways to Scrum of Scrums, but it introduces a new structure for smoothing out the cooperation between teams \u2013 the Integration Team.<\/p>\n 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.<\/p>\n 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\u2019re facing and resolve dependency issues with the help of the Integration Team.<\/p>\n At the end of the sprint, Scrum teams meet with the product owners to review what was and wasn\u2019t done during the sprint. No individual team sprint reviews are held.<\/p>\n 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n The process starts with the team describing user stories \u2013 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.<\/p>\n 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.<\/p>\n 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.<\/p>\n Crystal is a collection of methods for product development. Contrary to Scrum-related methods we already covered, Crystal prioritizes the team that\u2019s going to deliver a project over the processes it is to follow.<\/p>\n This conclusion came to Crystal\u2019s 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\u2019t 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.<\/p>\n Crystal framework is built on two beliefs: 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.<\/p>\n Some Crystal colors<\/strong> include:<\/p>\n In general, the suggested maximum number of people for each of the methods is shown in the chart below:<\/p>\n Diamond and Sapphire Crystals can also be used for the most critical projects, regardless of the number of participants.<\/p>\n 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:<\/p>\n 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.<\/p>\n 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\u2019s why there can be more than one iteration being worked on at a time.<\/p>\n 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.<\/p>\n Regardless of which Scrum alternative you choose, we highly recommend using BRIDGeS during agile product development<\/a>. 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. <\/p>\n\n\n\n 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<\/a>). <\/p>\n\n\n\n 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.<\/p>\n\n\n\nScrum of Scrums<\/h2>\n
Roles in Scrum of Scrums<\/h3>\n
\n
![\"\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2020\/03\/Scrum-Alternatives-scrofscr.jpg\")
<\/p>\nHow Scrum of Scrums works<\/h3>\n
\n
Pros of Scrum of Scrums<\/h3>\n
\n
Cons of Scrum of Scrums<\/h3>\n
\n
SAFe (Scaled Agile Framework)<\/h2>\n
Roles in SAFe<\/h3>\n
\n
![\"SAFe](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2020\/03\/Scaled-Agile-Framework-_Portfolio_web.png\")
<\/p>\nHow SAFe works<\/h3>\n
Pros of SAFe<\/h3>\n
\n
Cons of SAFe<\/h3>\n
\n
LeSS (Large-Scale Scrum)<\/h2>\n
Roles in LeSS<\/h3>\n
\n
How LeSS works<\/h3>\n
LeSS Huge<\/h3>\n
![\"LeSS\"](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2020\/03\/Scrum-Alternatives-owner-scaled.jpg\")
<\/p>\nPros of LeSS and LeSS Huge<\/h3>\n
\n
Cons of LeSS and LeSS Huge<\/h3>\n
\n
Nexus<\/h2>\n
Roles in Nexus<\/h3>\n
\n
![\"Nexus](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2020\/03\/scaled-agile-nexus.png\")
<\/p>\nHow Nexus works<\/h3>\n
Pros of Nexus<\/h3>\n
\n
Cons of Nexus<\/h3>\n
\n
XP (Extreme Programming)<\/h2>\n
![\"XP](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2020\/03\/Scrum-Alternatives-XP.jpg\")
<\/p>\nRoles in XP<\/h3>\n
\n
How XP works<\/h3>\n
Pros of Extreme Programming<\/h3>\n
\n
Cons of Extreme Programming<\/h3>\n
\n
Crystal<\/h2>\n
* Each project is unique and is constantly changing. As such, it\u2019s 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.<\/p>\n\n
![\"Crystal](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2020\/03\/Scrum-Alternatives-chrystal.jpg\")
<\/p>\nRoles in Crystal<\/h3>\n
\n
How Crystal works<\/h3>\n
Pros of Crystal<\/h3>\n
\n
Cons of Crystal<\/h3>\n
\n
BRIDGeS for decision-making and ideation<\/h2>\n\n\n\n
![\"bridges](\"https:\/\/railsware.com\/blog\/wp-content\/uploads\/2021\/11\/bridges-banner-1024x536.jpg\")
<\/a><\/figure>\n\n\n\n