Agile is 25: Which Practices Still Work in 2026 and Which Don't?
A practical framework for separating useful Agile practices from rituals that no longer serve the team.
Q: “Hi Vibhor, Agile is now 25 years old, and in my organization, we still follow old practices because ‘this is how Agile is done.’ Some of these practices still help teams learn and make better decisions, but others feel more like inherited rituals. How can I help a team audit its Agile practices in 2026 and decide what to keep?
Thank you for the question.
That observation you shared tells me that you are already doing the harder part of the job.
Most Scrum Masters I speak with are focused on getting their teams to follow the practices. You are asking whether the practices deserve to be followed at all. That is a more honest question, and it is the right one to be asking in 2026.
The problem you are standing in right now looks like this:
Daily Scrum at 9:15 a.m.,
Sprint Planning every other Monday,
a velocity chart on the wall,
a retrospective every two weeks,
a Sprint Review on the last Friday.
Attendance is good.
The events run on time.
And yet the team’s decisions take longer than they should.
Nobody questions the events, because the EVENTS are Agile, and Agile is how the team does things.
Scrum Masters are no longer introducing Agile to teams for the first time.
They are inheriting Agile.
A team that inherited its practices is a different problem than a team that failed to apply them. The inherited team looks fine from the outside. The events are followed and accounted for. What is missing is the reason the events were designed in the first place.
And because these practices have been around for years, people stopped asking the necessary question:
Is this still helping us learn, or are we just preserving the shape of Agile?
SO let’s ask this question and see what happens.
Got an urgent question?
Get a quick answer by joining the subscriber chat below.
Agile is old enough to need inspection
In the early days, many teams were trying to move away from heavy upfront planning and rigid delivery models like “waterfall”. Agile practices felt fresh at that time because they challenged the old system.
Now, in many organizations, Agile itself has become the system.
That means some teams are no longer rebelling against bureaucracy. They are navigating Agile bureaucracy.
The Sprint is a reporting cycle. The Daily Scrum is a status meeting.
Has Agile failed?
No!
Agile practices have been institutionalized.
And anything that becomes institutionalized needs inspection… periodically!
Separate the principle from the habit
The Agile Manifesto comprises four values and twelve principles.
Velocity appears nowhere in it, nor do story points.
The Manifesto does not define the structure of a Sprint Review or specify how long a Daily Scrum should last.
Those practices came later, mostly through Scrum and XP, and then through the organizations that implemented them, modified them, scaled them, and handed them down as received wisdom.
The distinction between Principles and Practices matters enormously, and getting it clear is the first step for an audit.
#1: Principle
A Principle is a durable belief about how good software work gets done.
For example:
Working closely with customers produces better outcomes than working from documents.
Short feedback loops catch mistakes before they compound.
People given autonomy and clear goals tend to outperform people given detailed instructions.
Teams that reflect and adapt tend to improve.
These beliefs have held up across a wide range of contexts over 25 years.
#2: Practice
A Practice is a specific “action” designed to express a principle in a real working environment.
For example:
Sprint Planning, velocity tracking, story points, and retrospective formats are all practices.
They were designed to solve specific problems in specific contexts.
Some of those problems still exist. Others have changed. And some practices were never solving the problems they claimed to solve, even in the environments where they became popular.
An institutionalized habit occurs when a Practice disconnects from its “original” purpose and continues to run on social inertia.
The team does it because the team has always done it, because the tooling was built around it, because the certification said so, because the manager can see it on a report, because removing it would require a conversation nobody wanted to have.
phew…
I know.
Why teams protect Practices that no longer work
The error that keeps Agile organizations stuck is treating Practices and Principles as equivalent, then using the authority of the Principles to shield the Practices from scrutiny.
Read that again…
Here’s an example:
When someone questions whether “velocity” tracking is actually helping the team make better decisions, they are examining a specific “action” used to express a Principle. That examination is completely legitimate. The Principle survives the question. The Practice has to answer it.
A 2025 systematic mapping study that analyzed 97 studies published throughout the Agile era found that
are the qualities that recur most consistently across healthy Agile teams, regardless of which framework they use.
These are human capabilities with a 25-year evidence base behind them.
The practices that still support these capabilities deserve to stay. The practices that have gradually displaced them deserve inspection.
4 tests every Practice needs to pass
Before deciding what to keep, retire, or rebuild, you need a consistent basis for evaluation.
Without a shared test, audits collapse into opinion contests:
The person who likes retrospectives argues for them; the person who finds Sprint Reviews pointless argues against them; nobody changes their mind; and the practices stay exactly where they were.
A practice must earn its place.
The audit I recommend applies 4 tests to every Practice.
Test 1: Feedback:
Does this practice shorten the time between action and learning?
Apply this test by asking whether the gap between doing and understanding actually shrinks because of the practice, or whether it would shrink just as fast without it.
Example:
A burn-down chart that shows the team falling behind mid-Sprint.
Most teams look at it, note the trend, and keep working as planned. The chart recorded something, but nothing changed because of it.
A daily standup that actually identifies a blocker and removes it the same morning is better because it reduces the gap between the problem appearing and the team learning about it.
Test 2: Customer Contact:
Does this practice move the team closer to real user evidence?
Product specifications written on behalf of end-users are a different category of evidence than observations of actual end-users interacting with working software.
Apply this test by asking whether the practice narrows that distance, or whether it substitutes one layer of interpretation for another.
Example:
A product manager who writes “as a user, I want to filter results by date” has interpreted something.
A developer who spends thirty minutes watching a customer attempt to find last month’s invoices has observed something.
Both inform the work, but they are not equivalent inputs.
Test 3: Team Learning
Does this practice produce adaptation, or only attendance?
Showing up to a Scrum event is compliance.
Changing behaviour as a result of that Scrum event is learning.
Apply this test by asking what the team does differently after the practice runs. If the honest answer is nothing in particular, the practice is generating compliance.
Example:
A retrospective that fills a Confluence page with observations and produces three action items nobody tracks by the following Thursday has generated compliance.
A retrospective where the team decides to stop estimating in story points for the next Sprint, runs the experiment, and then reviews what changed has generated learning.
Test 4: Decision Quality
Does this practice help the right people make better decisions sooner?
Visibility that informs senior leadership without changing what the delivery team does next is a different outcome than a practice that puts decision-making authority with the people who have the best information.
Apply this test by asking who makes a better decision because of this practice, and whether that person is actually the one closest to the work.
Example:
A Sprint Review where stakeholders watch a demo, say the work looks good, and then a manager adjusts the following Sprint’s priorities in a separate meeting has created visibility for one group and left the delivery team waiting for a decision they are better positioned to make.
These four tests are not a published academic framework. Apply them as you see fit.
What matters is applying the same questions to every practice, including the ones you personally favour.
Practices that still hold up
Some “inherited” Agile practices hold up well.
They earned their place because they still do real work, and that work is clear when you apply the four tests.
#1: Small Increments of Deliverable Work
Short cycles create feedback. Long cycles create assumptions.
This passes all four tests with little difficulty.
Delivering something small and real on a short cycle creates natural feedback.
Stakeholders can respond to something tangible.
Users can interact with a working feature in a way that a requirements document cannot replicate.
Breaking large uncertain problems into small deliverables, then getting real feedback on each slice, is as sound in 2026 as it was in 2001.
#2: Honest retrospection
This passes the feedback, learning, and decision-quality tests, but only when done well.
The word “honest” is carrying weight in that sentence.
A retrospective that produces a list of observations and no behavioural change is no good.
When a team uses a regular cadence to examine what is slowing them down, what is creating confusion, and which experiments they are willing to run, they are applying the twelfth principle of the Manifesto directly. That principle has not lost anything over 25 years.
Example:
A team notices in retrospective that their definition of “done” is being interpreted differently by different members, causing rework at review.
They agree on a shared checklist, apply it for one Sprint, and rework reduces.
The retrospective did not just surface the problem; it produced a behavioural change that the next Sprint confirmed.
#3: Direct Customer Contact
This practice holds up for the same reasons it always did.
Teams with regular, structured access to real users improve their understanding of what to build.
The teams that build things people actually use tend to be the teams that spend time watching people use things.
Example:
A product manager reports that users want a dashboard summary at the top of the screen.
A developer joins a user research session and watches three users scroll straight past the summary to find the data table underneath it.
The interpretation and the observation point in different directions. Only one of them is grounded in what users actually do.
#4: Visible Work
This practice passes the decision-quality test when visibility genuinely serves the team.
Example:
A board that shows the team what is in progress and what is blocked helps the team coordinate.
A board that exists so that a manager can screenshot it for a status report serves a different audience. The two boards look identical and produce very different results.
What these practices share is that they quickly connect the team’s work to real consequences.
They create conditions under which learning happens continuously, without waiting for a scheduled reporting cycle.
Be careful with metrics that become targets
Metrics deserve special attention.
Historical delivery data can be useful. It can help teams forecast, understand flow, and have more honest conversations about capacity and trade-offs.
But when a metric becomes a target, behavior changes.
Velocity is the obvious example.
When velocity is treated as a forecasting signal, it may help. When it becomes a performance target, it can damage the system. Teams may inflate estimates, avoid risky work, split items artificially, or focus on points instead of outcomes.
That is why Scrum Masters need to inspect not only the metric, but the behaviour the metric creates.
A metric is not neutral once people are judged by it.
Rebuild before you retire the practice
Some practices should not be kept as they are. But they should not be thrown away either.
They need to be rebuilt.
This is an important category because it avoids the false choice between defending the old process and rejecting everything.
Sprint Planning is a good example.
The need behind Sprint Planning is still real. Teams need to decide what matters next, understand the goal, see the risks, and align around a short-term plan.
But in many teams, Sprint Planning becomes a capacity-filling exercise. The discussion focuses less on the outcomes and more on the capacity planning to fit.
That does not mean planning is useless. The practice needs to be rebuilt around purpose.
What is the most important thing to achieve or learn this Sprint?
What trade-off are we making?
What might change our plan?
What will we do if the work turns out to be more uncertain than expected?
That is a very different conversation from simply filling the Sprint.
Rebuild refinement around evidence
Backlog refinement needs the same treatment.
The original purpose is valuable: create enough shared understanding before work begins.
But refinement can easily become backlog farming.
Items are added, described, estimated, tagged, split, and stored. The backlog grows. The team feels productive. But the organization is simply creating a larger inventory of untested ideas.
A healthier refinement conversation will challenge the backlog, not just maintain it.
Sometimes the best refinement outcome is not a better ticket. It is deleting the ticket.
Rebuild Sprint Reviews around decisions
Sprint Reviews are another common place where Agile becomes a routine.
Here’s what happens:
The team demonstrates work. Stakeholders nod. Someone says, “Looks good.” A few comments are made. Then everyone leaves, and the backlog continues mostly unchanged.
That is a demo. It may be useful, but it is not enough.
A strong Sprint Review should create decisions.
What did we learn?
What should we change?
What should we stop?
What should we do next?
When the Sprint Review becomes a decision-making and learning event, it regains its power.
The goal is to inspect the product and adapt the future.
Look for customer contact
One of the strongest tests of an Agile practice is whether it brings the team closer to users.
Many teams are internally Agile but externally disconnected.
They collaborate well with each other. But real user evidence remains distant.
That is dangerous because the team can become very efficient at delivering assumptions.
So ask:
Does refinement include user problems or only ticket details?
Does the Sprint Review include people who can respond to the product?
Does the retrospective ever inspect how well the team is learning from customers?
Does the backlog show what we know, what we believe, and what we still need to learn?
Agile without customer contact easily becomes internal bureaucracy.
Compliance is not the same as adaptation
A compliant team holds the retrospective. An adaptive team changes how it works as a result of the retrospective
A compliant team updates the board. An adaptive team uses the board to notice bottlenecks and rebalance work
A compliant team attends the Sprint Review. An adaptive team changes product direction based on what the review reveals
From a distance, compliance and adaptation can look similar.
Inside the team, they feel very different.
Compliance feels like going through the motions. Adaptation feels like a process that helps the team think, decide, and improve.
Scrum Masters should care less about whether the activity happened and more about whether it changed anything important.
Use decision quality as the main lens
If there is one lens that ties the whole audit together, it is decision quality.
A practice is valuable when it helps the right people make better decisions sooner.
For Example:
Daily Scrum should help the team decide how to coordinate today.
Sprint Planning should help the team decide what matters most in the next short cycle.
Sprint Review should help the team and stakeholders decide what to continue, change, stop, or investigate.
Retrospective should help the team decide what to improve next.
Refinement should help the team and Product Owner decide what is clear enough, valuable enough, small enough, and evidence-backed enough to move forward.
This lens is powerful because it connects Agile practices to the actual outcomes.
The last thing teams need is more events. What they need is better moments of alignment, learning, and adjustment.
How to run the Audit
The 4-test audit works best when teams run it on themselves.
Start here:
Have the team list every recurring Agile practice it currently follows: events, artifacts, reporting habits, and meetings that exist because the framework says so. Get the list visible before evaluating anything.
Then:
take each practice and run it through the 4 tests.
For each one, the team should be able to say:
whether it is actually shortening feedback loops,
whether it is bringing the team closer to real user evidence,
whether it produced any change in how the team works, and
whether it is helping the people with the best information make decisions when they matter most.
Aim for an honest conversation.
Then:
Mark each practice as Keep, Retire, or Rebuild.
A practice that passes all 4 tests earns Keep.
One that the team cannot honestly defend against even a single test earns Retire.
One that still addresses a real problem but whose current form is no longer serving that purpose earns Rebuild.
Then:
Pick one practice from the Retire list and stop doing it for the next four weeks.
Pick one from the Rebuild list and commit to redesigning it around the original problem it was meant to solve.
Run both experiments simultaneously.
Then:
After a month, review:
whether the team has better evidence about what their users actually need.
Use that review to decide whether to continue, extend, or revise.
The most Agile thing you can do
The most Agile thing a team can do in 2026 may be to stop protecting its practices from inspection.
Agile is twenty-five years old.
That is long enough for an idea to move from radical proposal to industry standard to inherited assumption.
The Manifesto’s authors were trying to articulate principles that would help teams navigate uncertainty and learn from their work. The practices that grew up around those principles deserve the same scrutiny that Agile teams are supposed to apply to everything else.
The question to bring back to your team is this:
If we were designing how we work today, with everything we now know, would we choose this practice?
If the answer is yes, keep it. If the answer is no, or if nobody can remember why the answer should be yes, that is the conversation the team has been waiting 25 years to have.
Show your support
Every post on Winning Strategy takes 1 full day of writing. You can show your support with small gestures.
Liked this post? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone who would find this helpful? Make sure to recommend it.
I strongly advise that you download and use the Substack app. This will allow you to access our community chat, where you can get your questions answered and your doubts cleared promptly.
Further Reading
Connect With Me
Winning Strategy provides insights from my experiences at Twitter, Amazon, and my current role as an Executive Product Coach at one of North America’s largest banks.