You have been in the room. Two days of PI planning that produced a roadmap everyone quietly knew would change in six weeks. A standup where eight people report to the Scrum Master instead of talking to each other. A velocity chart on a dashboard that leadership uses to ask why output dropped, even though the team delivered more value than the previous sprint.
If you are a product leader who has been in those rooms, this post is for you. Not a defense of Agile as a brand, and not a takedown either. Just an honest answer to the question that matters right now: which practices are genuinely carrying weight, and which ones have quietly become performative?
Here is what I have found after working with product and technology organizations across industries: the teams that are thriving in 2026 are not the ones who kept everything. They are the ones who kept the right things. I recall Mike Cohn telling me one time, "if you are still doing the same things you did a year ago, you aren't agile".
The Five Worth Keeping
I was talking at an organization's engineering offsite session this week. The teams had corporate trauma from the last leadership team abusing Scrum. My goal was to bring them back to the practices, not the names of the practices, so I thought I would recap them here. These are the load-bearing practices. The things that organizations who say "we don't do Agile anymore" are still doing, just under different names. If you strip them out, you do not get a leaner process. You get a slower one.
1. Short iterations with a real endpoint
Call them sprints, cycles, heartbeats, or whatever your organization has settled on. The name is irrelevant. The practice is essential. Working in bounded, time-limited increments forces a team to make a decision about what is actually ready versus what is perpetually almost ready.
Product companies that have "moved past Agile" into continuous delivery models did not eliminate the concept of iteration. They compressed it. The discipline of regularly asking "is this done enough to learn from?" is one of the most valuable things the Agile world contributed to how software gets built. Teams that abandon iteration in favor of open-ended development tend to ship later, not sooner.
The Scrum Guide says a Sprint creates consistency and reduces complexity. That is still true. Keep the rhythm. Adjust the length if two weeks is wrong for your work. But keep the discipline of a real endpoint.
2. Working software (or product) as the primary proof of progress
The second value in the Agile Manifesto is "working software over comprehensive documentation." Most teams understand this in principle. Fewer actually practice it. Progress meetings that consist entirely of slide decks, status updates, and Jira screenshots are the modern equivalent of comprehensive documentation. They describe work, they do not demonstrate it.
The teams that produce something tangible at the end of every cycle, something a real user or stakeholder can interact with and respond to, are the teams that get useful feedback. Everything else is speculation dressed up as progress. This practice is load-bearing. Without it, you lose the signal that tells you whether you are heading in the right direction.
This does not mean every sprint needs a full production release. It means every sprint should end with something concrete enough to generate a real reaction from someone who is not on the development team.
3. Deliberate retrospection
Not every retrospective is load-bearing. But the practice of deliberately setting aside time to inspect how the team is working and making a specific change as a result is one of the most durable performance improvements available to any team.
The key word is deliberate. A retro that produces the same list of action items every quarter is not retrospection. It is ritual. Real retrospection requires psychological safety, a genuine willingness to surface uncomfortable truths, and, most importantly, follow-through. One action item that actually changes something is worth more than a perfectly facilitated session that produces twelve items nobody implements.
Mike Cohn's research and the broader agile practitioner community have documented this clearly for years: teams that consistently inspect and adapt their own process outperform teams that do not, even controlling for talent and tooling. Keep the retro. Fix what makes it feel performative.
4. Explicit backlog prioritization
Someone has to decide what gets built and in what order. That decision needs to be visible, revisable, and grounded in evidence. The product backlog, whatever you call it in your organization, is the mechanism for making that decision transparent.
The alternative to explicit prioritization is implicit prioritization, which means whoever shouts loudest or has the most political capital gets their work done first. That dynamic is invisible, resistant to improvement, and actively harmful to value delivery. Explicit backlogs make the prioritization visible enough to challenge.
Roman Pichler makes this point clearly in his work on product ownership: the backlog is only as valuable as the thinking behind its order. A backlog that reflects real tradeoffs and evidence-based decisions is a strategic tool. A backlog that is a sorted wish list is just a long to-do list with column headers.
5. Incremental delivery over big-bang releases
The practice of releasing in smaller increments rather than large batches is one of the most consequential improvements that the Agile and DevOps movements produced. It is also one of the most validated by research. DORA's annual State of DevOps Report has documented for over a decade that high-performing organizations deploy more frequently, experience fewer failures, and recover from failures faster than low-performing organizations.
The organizations that have "moved past Agile" and into product operating models have not abandoned incremental delivery. They have accelerated it. Continuous deployment, feature flags, canary releases, and progressive rollouts are all expressions of the same principle: smaller batches create faster learning and safer delivery.
If your organization still plans for quarterly releases, this is probably your highest-leverage improvement target. Not because quarterly releases are inherently wrong, but because they delay the feedback that tells you whether you built the right thing.
DORA 2024 report: https://dora.dev/research/2024/dora-report/
Three to Retire (And What to Do Instead)
These are not bad ideas that were poorly conceived. They are good ideas that drifted. Each one started with a legitimate purpose and, in many organizations, quietly became something else. Naming what they became is not cynicism. It is the honest starting point for building something better.
Retire: The daily standup that became a status report
The daily standup was designed to help the team coordinate toward a shared goal. It was meant to surface blockers before they became fires and to create a brief moment of shared awareness about who needs what.
In many organizations, it became something different. Each person answers three questions in order, reporting what they did yesterday, what they plan to do today, and whether there are any blockers. The Scrum Master writes the blockers down. The meeting ends. Very little coordination happens. The person who actually could unblock someone did not realize they were needed, because the conversation was directed at the Scrum Master, not at the person who can actually help.
If this sounds like your standup, the meeting format is not the problem. The problem is who the team thinks the meeting is for.
Retire: Velocity as a performance metric
Velocity was introduced as a planning tool. It answers one question: based on our recent history, how much work can we expect to complete in the next sprint? That is a legitimate and useful question for forecasting purposes.
The problem begins when velocity moves from a planning input to a performance indicator. When leadership starts asking why velocity dropped this sprint, the team notices. When velocity becomes the number that gets reported in executive dashboards, rational teams respond by gaming the estimates to protect the number. Points inflate. Complexity assessments drift optimistic. The metric, which was supposed to help teams forecast, becomes the thing teams optimize for. And then it tells you nothing useful.
Goodhart's Law captures this precisely: when a measure becomes a target, it ceases to be a good measure. Velocity is a textbook example. The moment a team feels evaluated on it, the signal degrades.
Retire: Estimation ceremonies that cost more than they produce
Story point estimation and planning poker were introduced to help teams think through complexity together and surface assumptions before work began. In that narrow context, they have value. The conversation that happens during estimation, where someone realizes a story is actually three stories, or that two engineers have completely different mental models of how something should be built, is genuinely useful.
What is not useful is the two-hour refinement session where the team debates whether a story is a five or an eight, with the answer making no material difference to how the work gets done. Or the quarterly planning exercise where teams estimate six months of work in story points, producing a plan that looks precise and is actually fiction. Donald Reinertsen documented this problem clearly in his work on product development flow: late-stage, high-volume estimation has a poor return on investment because the uncertainty in complex work is not reducible by debating point values.
The real cost is not just the time in the room. It is the false confidence that large estimation exercises produce. A backlog with everything estimated feels like a plan. It is not. It is a list of guesses arranged in a specific order.
Reinertsen, The Principles of Product Development Flow: https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009
A note before you start cutting
There is a version of this post that gets misread as permission to cancel every ceremony and declare the team "post-Agile." That is not what I am saying.
The five practices worth keeping are worth keeping because they do real work. Pull them out and your feedback loops get longer, your priorities get murkier, and your team loses the structured opportunities to improve. The three to retire are not being retired because they are inherently bad. They are being retired because they have drifted in most organizations into something that costs time and produces little learning.
The question to ask about any practice is not "is this Agile?" It is "is this making us faster at learning what matters?" That question will always give you a cleaner answer than any framework checklist.
Do this Monday morning
Pick one practice from the "retire" list that you recognize in your team right now. Just one. Do not call a meeting about it. Do not announce a new process. Instead, ask the team one honest question at your next standup, retro, or refinement session:
"What was this practice originally supposed to help us do, and is it still doing that?"
Let the team answer. You will learn more in that five-minute conversation than you will from any assessment tool. And if the team agrees the practice has drifted, you have the opening to try something different, starting with the replacements above.
You do not need to overhaul your process this week. You need to have one honest conversation about whether your current practices are doing the work you hired them to do.
That conversation is where real improvement starts.