Agile Fundamentals

Choosing the Right Agile Approach in 2026

24 Mar 2026·5 min read
Choosing the Right Agile Approach in 2026

This is the second post in our Introduction to Agile series. The first covered the core characteristics of agile ways of working. This one helps you navigate the real choices teams face when deciding how to put those principles into practice.

When this post was first written in 2020, the conversation was about which framework to pick. In 2026, the conversation has moved on. Many experienced teams have stopped identifying with a specific framework altogether. But the underlying question hasn't changed: how do we organise ourselves to deliver value in the face of uncertainty?

Why Agile Frameworks Exist

The growth of agile frameworks was a response to the historic failures of legacy project management. Predictive, sequential approaches (often called "waterfall") assume you can specify a solution in detail upfront and deliver it on a fixed timeline. This works when requirements are well-defined, technologies are familiar, and there are few surprises.

That describes very few real projects.

The pattern of failure is predictable and well-documented. Stakeholders see the complete solution only at the end and it doesn't meet their expectations. Re-work follows that wasn't in the plan. The sequential stages crash into each other. Testing gets compressed. Quality suffers. The Standish Group's research has consistently shown that agile approaches roughly double the success rate of legacy approaches, though the exact figures vary by year and methodology.[^1]

Agile frameworks emerged to provide a structure for a different way of working: short cycles, frequent feedback, incremental delivery, and continuous adaptation. They gave teams a starting point, a set of practices to adopt before they had enough experience to design their own approach.

That starting point still matters. But the landscape around it has shifted considerably.

The Frameworks: What They Are and When They Help

Scrum

Scrum remains the most widely adopted agile framework, used by roughly 70% of agile practitioners.[^2] It provides a clear structure for small cross-functional teams: three roles (Product Owner, Scrum Master, Developers), five events (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and the Sprint itself), and three artifacts (Product Backlog, Sprint Backlog, Increment).

When it helps: Scrum works best when a dedicated team is building a complex product and needs a structured cadence of planning, delivery, and reflection. It is framework-agnostic about the type of product, meaning it works equally well for software, hardware, services, or events.

When it struggles: Scrum can feel rigid for teams doing operational or maintenance work where the flow of tasks is unpredictable. The fixed Sprint cadence doesn't always suit environments where priorities change daily.

Kanban

Kanban is a flow-based approach that visualises work, limits work in progress, and focuses on continuous delivery rather than fixed-length iterations. It is the most flexible of the common approaches and has seen significant growth in recent years, with 87% of practitioners reporting it as more effective than their previous way of working.[^3]

When it helps: Kanban suits teams with a continuous flow of incoming work, such as support, operations, DevOps, marketing, or portfolio management. It is also effective as an overlay on existing processes, making it a low-risk starting point for teams new to agile.

When it struggles: Kanban's flexibility can be a weakness. Without discipline, teams can end up with a visualisation board and no real change in behaviour. It requires maturity to use well.

DSDM (Dynamic Systems Development Method)

DSDM provides a full project lifecycle framework with strong governance, making it widely used in UK government and regulated sectors. It is the basis for the AgilePM certification and can scale for large projects or programmes. Unlike Scrum, DSDM addresses the whole project from feasibility through to deployment and post-project review.

When it helps: DSDM is well-suited to environments that need agile delivery within a governance structure, particularly where funding approval, business cases, and stage gates are required. It is one of the few agile approaches that explicitly addresses project-level concerns like business justification and stakeholder engagement.

When it struggles: DSDM is less well-known outside the UK and can feel heavyweight for small, autonomous product teams that don't need formal governance.

Extreme Programming (XP)

XP focuses on engineering excellence for software teams: pair programming, test-driven development, continuous integration, collective code ownership, and frequent releases. It is often combined with Scrum to add technical discipline.

When it helps: XP is valuable for teams building software where quality and technical sustainability matter. Its practices reduce defects, improve code quality, and make teams more resilient to change.

When it struggles: XP is specifically a software engineering approach. It doesn't address project governance, portfolio management, or non-technical work.

Scaled Approaches (SAFe, LeSS, and Others)

For organisations with multiple teams working on related products, scaled approaches provide coordination mechanisms. SAFe (Scaled Agile Framework) is the most widely adopted, used by roughly 35% of organisations practising scaled agile.[^2] LeSS (Large Scale Scrum) takes a simpler approach, applying Scrum principles across multiple teams with minimal additional process.

The honest picture: Scaling frameworks are increasingly debated. The State of Agile data shows a notable shift, with 34% of organisations now reporting that they've created their own approach or don't follow a mandated framework at the enterprise level.[^4] Many practitioners see heavyweight scaling as the opposite of agility, adding coordination layers that slow teams down rather than speeding them up. Others argue that large enterprises need structure to avoid chaos.

The trend is towards simpler scaling: smaller teams, clearer product boundaries, and less process overhead. If your teams are struggling with a scaling framework, the problem may not be the teams. It may be the framework.

The Bigger Shifts: What Has Changed Since 2020

From Frameworks to Principles

The most significant shift in the agile world is the movement away from framework loyalty towards principles-based working. Many experienced teams in 2026 are what you might call "post-framework." They've learned from Scrum, Kanban, XP, and others, taken what works, discarded what doesn't, and arrived at an approach that fits their context without carrying a brand name.

This isn't the same as having no structure. Post-framework teams typically have clear working agreements, defined cadences, and explicit practices. They just don't call it Scrum or Kanban. They call it "how we work."

If your team is new to agile, a framework is a sensible starting point. It gives you a structure to learn from. But the goal is not to implement the framework perfectly. The goal is to learn enough to evolve beyond it.

From Projects to Products

When this post was first written, most agile adoption was framed through a project lens: temporary teams assembled to deliver a defined scope within a defined timeline. Since then, many organisations have shifted towards product thinking: persistent teams that own a product or service over its full lifecycle, with an evolving scope driven by customer feedback and business strategy.

This shift matters because it changes which frameworks are relevant. Project-oriented frameworks like DSDM and legacy project management make sense when work has a clear start and end. Product-oriented approaches like Scrum and Kanban suit persistent teams with ongoing work. The choice depends on your context, not on which framework is most popular.

AI Is Changing How Teams Work Within Frameworks

AI tools are now part of many teams' daily workflows. Code generation, AI-assisted testing, automated documentation, and AI-supported analysis are compressing parts of the delivery cycle that used to take days.

But the frameworks themselves remain relevant because the hard part was never the technology. It was organising people, managing uncertainty, and delivering the right thing. AI doesn't solve those problems. If anything, it amplifies them: teams can now build the wrong thing faster than ever, which makes short feedback loops and empirical learning more important, not less.

For more on this, see our posts on The Best AI Strategy Is 200 Years Old and MVP Thinking in the Age of AI.

Blending Approaches

No framework is complete on its own. Frameworks deliberately have gaps that teams fill based on their context. This is by design, not an oversight. In practice, most teams blend elements from multiple sources:

  • Scrum teams often adopt XP engineering practices for software delivery
  • DSDM can wrap around Scrum to provide project-level governance
  • Kanban can be layered on top of any existing process as a starting point
  • Teams may use Scrum for product development and Kanban for operational work

Common practices that cross framework boundaries include timeboxing, daily stand-ups, iterative development, user stories, MoSCoW prioritisation, Kanban boards, and retrospectives. These belong to no single framework. Use what works.

How to Choose

There is no out-of-the-box answer. But here are some honest guidelines:

If you're new to agile and building a product: Start with Scrum. It provides enough structure to learn from and enough cadence to build good habits. Add XP practices if you're writing software.

If your work is more operational or unpredictable: Start with Kanban. Visualise your workflow, limit work in progress, and improve flow. You don't need Sprints to be agile.

If you need project governance and stakeholder management: Look at DSDM or AgilePM. They address the business context around delivery that Scrum deliberately ignores.

If you're scaling across multiple teams: Start simple. Define clear product boundaries. Give each team autonomy. Add coordination mechanisms only when the teams themselves tell you they need them, not before. Resist the temptation to adopt a heavyweight scaling framework because it looks comprehensive on a slide deck.

If your team is experienced and already working well: You may not need a framework at all. Articulate how you work, make it explicit, review it regularly, and keep improving. The best approach is the one your team has evolved through experience.

Whatever you choose, remember that the framework is a starting point, not a destination. The goal is to deliver value, learn from feedback, and improve continuously. Any framework that helps you do that is the right one. Any framework that gets in the way is not.

Where to Go Next

Related reading:

References

[^1]: The Standish Group has published Chaos Reports since 1994. The consistently reported pattern is that agile approaches achieve roughly double the success rate of legacy predictive approaches, though exact figures vary by year, sample, and how "success" is defined. The 2020 report showed agile projects succeeded at 42% vs 13% for waterfall. Recent State of Agile reports (Digital.ai) report agile project success at approximately 75%.

[^2]: State of Agile Report, 17th Edition, Digital.ai, 2023. Scrum usage at approximately 70% of agile practitioners; SAFe at approximately 35% of scaled agile adopters.

[^3]: State of Kanban Report, Kanban University, 2022. 87% of respondents reported Kanban as more effective than their previous ways of managing work.

[^4]: Businessmap (formerly Kanbanize), "17 Agile Statistics You Need to Know in 2026", citing State of Agile Report data showing 34% of organisations creating their own approach or not following a mandated enterprise framework.

Alun Davies-Baker is an agile coach, trainer, and the founder of Altogether Agile. He helps organisations navigate complexity using empirical approaches grounded in Business Agility.