The MANY Alternatives to Scrum
Many say, "Scrum is the worst development process—except for all the others." Mysteriously, they seem to believe there are no alternatives.
But that’s simply not true!
Progressive software organizations have already moved beyond Scrum. Big tech companies have left Scrum in the rearview mirror, and new processes are emerging everywhere.
Below is a list of thriving Scrum alternatives, along with brief summaries and resources for further exploration. So, the next time someone tells you Scrum is the only option, send them this guide and shatter that myth once and for all.
This page is designed to be a resource you can return to time and again. I’m committed to keeping it up-to-date with new and interesting alternatives, as well as deeper insights into specific processes.
It’s an exciting, post-Scrum world out there.
Can you feel the energy of a software industry eager to break free from the low-trust environments we’ve grown used to?
But remember, these solutions work because freedom-oriented organizations were bold enough to experiment and iterate until they found something that clicked. And they're likely still evolving to keep pace with our fast-changing world.
Their discoveries can inspire and guide your journey, but they can’t define it—let alone be your final destination.
Don’t expect to pick one of these options and suddenly see perfect results. Each solution is tailored to the unique DNA of its source. If you try to force it onto your company, it could be rejected—like a mismatched blood transfusion.
At most, use it as a starting point. The most essential ingredient for success is creating an environment centered on worker autonomy: the freedom to continuously experiment and improve. Without this, your solution will remain a hollow managerial mandate, masquerading as a progressive idea. The results will be underwhelming.
So, don’t misuse this information. See it as proof of the incredible outcomes you can achieve in a self-managed organization—a grab bag of ideas for future experiments. Not turn-key solutions to be fiercely obeyed until the desired results are achieved.
Kanban
We’re all familiar with the Kanban board since we already use it in Scrum.
But Kanban is different from Scrum—there are no sprints (rejoice!). When you finish a task, you simply pull the next one from the top of the backlog, which should always be in priority order. Because there are no sprints, you don’t have to worry about whether something fits into a sprint, which means there is no need for estimates. No backlog refinement/grooming meetings and no sprint planning! You just work in a continuous flow.
If an emergency arises, everyone pauses their work (with a physical board, I’ve seen teams rotate their cards by 90 degrees to visually indicate the halt). A new emergency ticket is created, and the whole team focuses on pushing it across the board as quickly as possible. Once it's resolved, the paused tasks can be resumed.
Kanban also enforces Work in Progress (WIP) limits for each column on the board. In other words, there’s a maximum number of items that can be in progress at any given time in any column. The team can set and adjust these WIP limits as needed, and they’re usually written at the top of the board above each column. This helps focus attention on bottlenecks where work may be piling up. Before pulling new tasks, you’re encouraged to first look to clear out columns that are at capacity.
Kanban is simple, effective, and a lot less stressful than sprints, which often run counter to the Agile principle of “sustainable development” at a “constant pace.”
References:
Valve (Cabal Development Process)
You can get a good sense of how Valve operates just from the subtitle of their New Employee Handbook:
A fearless adventure in knowing what to do when no one’s there telling you what to do.
At Valve, “there is no management and no one reports to anyone else.”(1) Everyone has wheels on their desks, and employees are encouraged to constantly ask themselves, “Where can I move to be the most useful?” There are no closed doors either—anyone can join any project that interests them.
Because employees choose which projects to work on, projects thrive or fade away based on their ability to attract talent. There’s no central authority deciding the company's next move.
Valve is always evolving. Temporary, cross-functional work groups, known as cabals, form spontaneously around important work. Project teams create temporary internal structures to meet immediate needs. The closest thing to a team lead is the person who, by keeping track of the project in their head, naturally becomes a hub of information.
Notably, unlike many other game companies, Valve views crunch mode or excessive overtime as a sign of a problem, not something to be celebrated.
Compensation is determined by a peer-driven stack ranking process that happens each year. There’s also a formalized peer feedback system in place to provide specific, actionable insights.
Valve pushes the limits of minimal organizational constraints and maximum employee trust—and it seems to be working. They’re one of the most efficient companies in the world, making more profit per employee than Google, Amazon, or Microsoft.
References:
Agile
Don’t forget, the Agile Manifesto and the Principles Behind the Agile Manifesto are excellent foundations for building your process. If you set aside everything you think you know about Agile and focus solely on these documents, you’ll have a strong base to begin your journey.
In fact, you could do what we all should have done back in 2001 when the Manifesto was first created: instead of looking for a pre-defined system like Scrum, XP, or Crystal, each team should have sat down and started iterating on a process of their own invention. From scratch.
With a little creative thinking, you can imagine countless processes that fit the pure Agile definition while avoiding the pitfalls we’ve encountered with existing Agile frameworks.
Notice that Agile recommends demonstrating working software frequently, but it says nothing about rigid, back-to-back iterations of the same length. Agile urges talking to business and product people daily, but it never mentions the need for product owners.
There’s no mention of estimates or sizing either. No references to tasks, backlogs, or specific leadership roles—just principles for a healthy software development process.
So, clear your mind of what’s been done before and let it fill with new ideas that you can experiment with and refine within your own organization. If they’re rooted in the wisdom of Agile, you’re already pointed in the right direction.
References:
Basecamp (Shape Up)
At Basecamp, feature work runs in six-week sprints, followed by a two-week break where developers have unscheduled time. They can use this time for anything they want—bug fixes, research, training, etc. This is a huge improvement over the constant strain of back-to-back sprints that leave no room for engineers to pursue their own initiatives.
Each project cycle is time-boxed. If work isn’t finished after six weeks, it’s not automatically renewed but must instead go through further planning to determine if more work should be done.
During the six-week cycle, teams have full autonomy to adjust their project scope to fit within the time frame. They also handle their own task planning and release strategy, aiming to deliver the best version of the project that can be completed in six weeks. This approach avoids the painful and wasteful sizing rituals common in Scrum and gives developers more time and energy for implementation.
Basecamp's process, known as Shape Up, is well-documented online, with a wealth of information available. Additionally, individuals at Basecamp share their insights through personal blogs and several excellent books.
References:
Open Source
We often forget that programmers have already invented a powerful model for software development—perhaps the most productive, self-organizing effort the world has ever seen: Open Source.
There’s no reason why we couldn’t design a corporate process around the principles of Open Source.
While each Open Source project is unique, they traditionally follow a model where an individual with full authority (often called the "benevolent dictator") leads the project. This person owns every aspect—coding standards, design, release cadence, quality level, CI strategy. Essentially, they run their project like it’s their own little company.
Other programmers either run their own projects or volunteer their efforts to existing ones.
Project owners attract contributors by showing promise through working code. They release frequently, even if the code is buggy or incomplete—it just needs to demonstrate potential.
Owners serve as gatekeepers, rigorously reviewing contributor code to ensure it aligns with the project’s vision before integration. However, owners have write permissions and can push their own changes whenever they want. Since they handle most of the coding, this avoids the painful bottlenecks around code reviews that plague many software organizations today.
There’s no central planning to prevent duplication of effort, which leads to the natural benefits of competition and "survival of the fittest" for project adoption. If disagreements arise and can’t be resolved within a project, forking is always an option, allowing for alternate solutions.
Essentially, Open Source operates like a free market, driven by reputation and gifting rather than money. While traditional management might scoff at this type of arrangement, some large corporations are finding internal markets to be an effective way to run their business. Haier, for example, operates with 4,000+ micro-enterprises that compete for each other’s business. Even service groups like HR are encapsulated within these micro-enterprises and face competition. Their survival depends on being chosen by other micro-enterprises.
Markets work stunningly well for both Haier and Open Source, not to mention the economy at large. It’s certainly a process worth considering.
References:
Just for Fun: The Story of an Accidental Revolutionary by Linus Torvalds
The Cathedral and the Bazaar by Eric Raymond.
Spotify
Spotify has publicly shared the evolution of their own development model. Notably, they started with Scrum but found that some of its practices were becoming obstacles, so they made them optional.
Scrum Masters were renamed Agile Coaches.
Today, Spotify is made up of small, cross-functional squads — self-organizing teams responsible for their own missions. They are free to choose their own methodologies and even release software independently.
Rather than having standard practices mandated by leadership, squads naturally converge on certain practices that become de facto standards.
Squads and individuals are further organized into broader groupings. Tribes are collections of squads. Guilds are groups of individuals who share common interests (e.g. Leadership, Continuous Integration, AI). Chapters bring together individuals in the same discipline (e.g. QA, Agile Coaching, Web Development).
Check out their excellent videos for more juicy details.
References:
Extreme Programming (XP)
Extreme Programming (XP) is a significant improvement over Scrum. At first glance, this might seem surprising, given how similar the rituals are: you still do planning, you still run iterations (which Scrum calls sprints), and you still break the work into small tasks. But XP stands out because it includes the engineering practices that make this collaboration style not only feasible but sustainable.
One major practice in XP—and Scrum—is shared code ownership. In both approaches, all code belongs to the team. Anyone can work on any task or submit changes to any repository. However, this introduces a challenge: every developer is responsible for a much larger body of code than if the codebase were divided into clearly defined areas of individual ownership. Where XP excels is in how it addresses this challenge.
In XP, developers collaborate closely to manage shared code ownership. Most notably, all work is done in pairs. Pair programming ensures that no one gets stuck for long and that knowledge is shared continuously. This is essential for maintaining momentum and handling the complexity of a collectively owned codebase. Pairing also lightens the load of constant iterations by reducing individual performance pressure and replacing it with the energy and camaraderie of close collaboration.
In contrast, Scrum teams often work independently, even with shared code ownership. This is extremely inefficient. Developers frequently get stuck, and finding help is difficult because everyone else is focused on their own tasks—or stuck themselves. Without pairing, Scrum can feel exhausting and stressful, especially with an intense focus on task completion metrics. Burnout becomes the norm, not the exception.
XP encourages several other practices to get faster, better feedback. For example:
Shorter iterations: XP uses one-week iterations, while Scrum iterations typically last two weeks or more. This provides faster feedback cycles and allows the team to adjust more quickly.
Test-Driven Development (TDD): Writing tests before writing code improves code quality and provides a safety net for continuous changes.
Continuous Integration (CI): By integrating and testing code frequently, teams catch issues early and avoid painful merge conflicts.
Another crucial advantage of XP is its focus on direct customer interaction. Unlike Scrum, which relies on a Product Owner to act as a proxy between the team and the customer, XP emphasizes direct collaboration. This approach shortens feedback loops, helps the team better understand the problem domain, and enables them to focus on delivering the right solution. Product Owners, by contrast, are a poor substitute.
Finally, XP seems to have avoided one of the key pitfalls of Scrum: certification. Scrum introduced a certification ecosystem that brought hordes of non-technical practitioners into technical teams as Scrum Masters and Product Owners. While XP teams also adopted rituals like planning and retrospectives, these rituals were owned and managed by the developers themselves. This self-management made XP more reasonable and less prone to micromanagement.
For teams looking for true collaboration, sustainable practices, and better outcomes, XP remains a vastly superior choice.
References:
Extreme Programming Explained: Embrace Change by Kent Beck
“Real Scrum”
Some of my readers will want me to include an entry for “Scrum done right.” But after years of experience, I’ve come to believe that’s nearly impossible. (Here’s an article where I twist myself into a pretzel trying to come up with a form of Scrum that doesn’t make me want to scream into the void.) Still, if your engineering team is filled with Scrum zealots—go ahead and give it a shot.
But remember this: The world is littered with hideous Scrum-like monsters—implementations that have caused mountains of heartache and suffering. Why? Because engineers didn’t own their own processes, and as a result, they couldn’t iterate their way out of the problems they encountered.
Don’t make the same mistake!
No matter how well you know Scrum —whether you’re a programmer or a certified Scrum Master, let the team run the show. Don’t cling so tightly to “your way” that the team can’t change it. Let them change whatever they think will make them more effective. Let them do irregular sprints that don’t run back-to-back; let them add items to the backlog without the PO’s permission; let them do stand-ups once a week; let them ban estimates. Whatever works!
“It’s not Scrum anymore!” you might say.
Exactly!
That’s where you want to be. It’s the team’s process, not Scrum’s—even if it started as Scrum. If you can’t call it Scrum anymore, you’re on the right track.
You have to let go.
Otherwise, the Scrum monster will eat you too.
It's only a matter of time till we start having methodology stacks. WoW Stacks? Meth Stacks? That's one way of terming it, I guess. "Hey bro, my team uses XP/Open-souce/Kanban". Alright but seriously, Open-source does sound like a cool idea. But why not just leave this at the behest of the engineers of the team? Just get them to congregate for an hour or two (preferably two), to discuss how the team should work together and collaborate (might require a couple of get-togethers)? "Alright, we've agreed to using SBE, BDD, Collective Code Ownership, Trunk-Based Development, Feature Flagging and GitHub Actions for CI. And a Google Sheet to track our work. Everything else is up to you, you manage your own work, yada yada yada."
I know that this might seem horridly "disorganised" - but what's wrong with the traditionally successful method of just picking people you think can do the job, who agree they can do the job, and just letting them do it?
Without anything even vaguely resembling any kind of 'methodology' at all?
I know this gives Project Managers conniption fits - but good PMs, with experience of what works and what doesn't, can often cope well and work well with herding that kind of assemblage of cats.
Upper management might hate the thought - but who says they have to know? The right kind of PM can feed them whatever BS they need, while concealing what's really happening below. The last few (very successful) projects I've worked on have been like that.
(Full disclosure and fair call, though, these have not been software development projects: they've been mainly "infrastructure with a bit of code re-writing". But I have previously worked on mostly-new-code projects that work - and worked! - like that too.)