The Agile Manifesto turned twenty-five last year. In that quarter century, agile went from a radical idea championed by seventeen software developers in a ski lodge to the dominant approach to software delivery worldwide. But dominance has not meant consistency. The agile that organisations practise in 2026 often bears little resemblance to the principles that started the movement — and the results reflect that disconnect.
This is an honest look at where agile stands today: what is genuinely working, what has been co-opted beyond usefulness, and what the next evolution looks like.
SAFe Fatigue Is Real
The Scaled Agile Framework became the default choice for large organisations wanting to "do agile at scale." At its peak, SAFe certifications were among the most sought-after credentials in the industry. But by 2026, the backlash has reached critical mass.
The criticism is not that SAFe is inherently wrong — it is that in practice, SAFe implementations frequently produce exactly the bureaucracy that agile was supposed to eliminate. Programme Increment planning events that consume an entire week. Release trains with so many dependencies that flow is throttled to the slowest team. Layers of coordination roles that add overhead without adding value. And a certification ecosystem that prioritises compliance with the framework over achievement of outcomes.
SAFe fatigue is real -- adding process should be the last resort for scaling, not the first. Reduce dependencies by design instead.
Organisations that implemented SAFe well — treating it as a starting point rather than a rigid prescription — continue to get value from it. But the growing trend is toward lighter-weight scaling approaches: LeSS (Large-Scale Scrum), team topologies that reduce inter-team dependencies by design, or simply letting teams operate independently with shared architectural standards and aligned objectives. The lesson is not that scaling is bad, but that adding process should be the last resort, not the first.
The Return to Basics
The most effective agile teams in 2026 are, counterintuitively, the least framework-dependent ones. They have internalised the principles — short feedback loops, working software, collaboration, responding to change — and they apply them pragmatically rather than dogmatically.
These teams share common characteristics. They keep their processes simple. They hold ceremonies because they are useful, not because the framework says to. They measure outcomes rather than compliance. And they continuously adjust their practices based on what is working, which is arguably the purest expression of agile there is.
At Pepla, our teams have evolved away from rigid framework adherence toward principle-based agility. Each team runs the ceremonies and practices that serve their specific context. Some run two-week sprints with full Scrum. Others use Kanban with weekly cadences. What they share is a commitment to delivering working software frequently and learning from every iteration.
The best agile teams in 2026 hold principles tightly and practices loosely -- frameworks are tools, not religions.
Remote Agile Ceremonies
The pandemic forced every agile team to go remote, and while many organisations have returned to hybrid or in-person models, remote ceremonies have become a permanent part of the landscape. The question is no longer whether remote ceremonies can work, but how to make them work well.
What has emerged from six years of practice:
- Shorter is better. Remote attention spans are measurably shorter than in-person ones. Ceremonies that worked at 60 minutes in a conference room need to be 40 minutes on a video call, which means tighter facilitation and better preparation.
- Async pre-work is essential. Sprint reviews that begin with a 20-minute demo are wasting everyone's time. Share the demo recording in advance. Use the live session for questions, feedback, and decisions.
- Visual collaboration tools matter. Miro, FigJam, and similar tools have replaced physical sticky notes, and in many ways they are superior — they persist after the meeting, they are searchable, and they allow asynchronous participation.
- Camera fatigue is real. The most effective remote teams do not mandate cameras-on for every ceremony. Standups can be audio-only. Retros benefit from cameras. Sprint planning depends on the complexity of the discussion.
- Time zones remain the hardest problem. There is no perfect solution for a team spread across eight time zones. The least-bad approach is rotating meeting times so the burden is shared, combined with extensive use of asynchronous communication.
AI in Sprint Planning
AI tools are beginning to augment — not replace — agile ceremonies. The most practical application so far is in sprint planning and backlog management.
AI-assisted refinement tools can analyse a user story and flag potential gaps: missing acceptance criteria, unclear scope boundaries, dependencies on other stories, and similarity to stories that were previously underestimated. This does not replace the team's judgement, but it gives them a better starting point.
Velocity forecasting is another area where AI adds genuine value. Traditional velocity charts are noisy and often misleading. Machine learning models that account for team composition changes, story complexity patterns, and historical accuracy of estimates produce significantly more reliable forecasts. Several teams at Pepla now use AI-assisted forecasting to provide stakeholders with probabilistic delivery dates rather than single-point estimates.
The caution is against over-reliance. AI tools are excellent at pattern recognition but poor at understanding context, team dynamics, and the human factors that frequently determine sprint outcomes. They are a supplement to experienced agile practitioners, not a substitute.
Velocity as a performance metric is dead -- measure cycle time, throughput, and customer outcomes instead.
Continuous Discovery
One of the most significant shifts in agile practice is the integration of continuous discovery into the delivery cycle. Traditional agile assumed that the product backlog was populated with well-defined work ready for development. In practice, the hardest part of product development is figuring out what to build — not building it.
Continuous discovery, as popularised by Teresa Torres, embeds regular customer research into the sprint cycle. Product teams conduct weekly customer interviews, run small experiments to validate assumptions, and use opportunity solution trees to connect customer needs to product decisions.
The teams that have adopted continuous discovery report a dramatic reduction in wasted development effort. Instead of building features based on stakeholder opinions and discovering six months later that customers do not use them, they validate demand before committing development resources. This is not a departure from agile — it is an extension of the principle that working software in the hands of users is the primary measure of progress.
Outcome-Based Roadmaps
The traditional feature-based roadmap ("Q1: build feature X, Q2: build feature Y") is losing ground to outcome-based roadmaps ("Q1: reduce onboarding time by 40%, Q2: increase self-service resolution rate to 70%"). The difference is fundamental.
A feature-based roadmap commits to solutions before problems are fully understood. It measures success by output (did we ship the feature?) rather than outcome (did the feature achieve its purpose?). And it is fragile — if priorities change mid-quarter, the roadmap is invalidated.
An outcome-based roadmap commits to goals while leaving the solution open to discovery. It measures success by impact. And it is resilient to change because the goals remain valid even if the approach to achieving them evolves.
The practical challenge is that outcome-based roadmaps require more sophisticated stakeholder conversations. Executives who want to know "when will feature X ship?" need to be redirected toward "what business outcome are you trying to achieve, and how will we measure it?" This is a cultural shift as much as a planning shift.
The Death of Velocity as a Metric
Velocity — the number of story points completed per sprint — was never intended to be a performance metric. It was designed as a capacity planning tool: if the team averages 40 points per sprint, a 200-point backlog will take approximately five sprints. That is useful planning information.
But velocity became weaponised. Management started comparing velocities across teams. Teams started inflating their estimates to show higher velocity. "Increase velocity by 20%" became a performance goal, which is roughly as meaningful as "increase the number of lines of code by 20%." The metric became the target, and once a metric becomes a target, it ceases to be a good metric.
In 2026, the most mature agile teams have moved away from velocity toward metrics that measure what actually matters:
- Cycle time: How long does it take from starting a piece of work to delivering it? Shorter is better.
- Throughput: How many items does the team complete per unit of time? This is similar to velocity but counts items rather than estimated points, removing the gaming incentive.
- Lead time: How long from a customer request to delivery? This measures the entire value stream, not just the development team.
- Deployment frequency: How often does the team ship to production? More frequent deployments indicate confidence and flow.
- Customer satisfaction: Does the delivered work actually make customers happy? This is the ultimate outcome metric.
Where Agile Goes From Here
Agile in 2026 is mature enough to be honest about its limitations while retaining its core strengths. The principles remain sound: deliver value frequently, get feedback quickly, adapt continuously, and respect people. The specific practices and frameworks are tools to be selected based on context, not religions to be followed unconditionally.
Commit to outcomes, not features. Outcome-based roadmaps survive priority changes because the goals remain valid even when the approach evolves.
The next evolution is likely to be driven by AI augmentation, continuous discovery practices, and a growing recognition that agile is not just a development methodology — it is an organisational operating model that affects product management, design, business analysis, and leadership as much as it affects engineering.
Pepla runs agile across every project we deliver. Our Scrum Masters facilitate ceremonies, our PMs track velocity, and our weekly client check-ins keep stakeholders informed and aligned.
The teams that will thrive are those that hold the principles tightly and the practices loosely. They will use what works, discard what does not, and never stop experimenting with better ways to deliver value.
