Why Agile Teams Still End Up Doing Waterfall
Revised
Published
~ 8 min read
TL;DR
A team is not agile because it uses Jira, runs stand-ups, or organises work into sprints.
It is agile when it can ship a small change quickly, learn from reality, and change direction without drama.
Most organisations struggle with that. They adopt agile language and agile tooling, but keep the older operating model underneath: annual planning, fixed scope, specialist hand-offs, release gates, and success measured against the plan rather than the outcome.
That is why so many teams end up doing waterfall inside an agile-looking environment.
The Surface Looks Agile
From the outside, these teams often look modern.
They have boards, backlogs, rituals, retrospectives, roadmaps, and a work item hierarchy that looks very disciplined. There may be epics, stories, subtasks, estimation, sprint reviews, and dashboards showing delivery progress in great detail.
But none of that tells you whether the team is actually working in short feedback cycles.
The real test is simpler: when something important is learned, can the team change the plan quickly and cheaply?
If the honest answer is no, then the process is probably still waterfall in practice.
Waterfall Did Not Disappear, It Changed Clothes
Waterfall is not just a diagram with strict phases.
It is a management model built on the assumption that enough analysis up front can make the rest of delivery mostly an execution problem. Work gets decomposed, dependencies get mapped, dates get assigned, and the organisation tries to remove uncertainty by planning harder.
Agile starts from a different premise. The original Agile Manifesto and its principles assume that uncertainty is normal, requirements will change, and teams should learn by delivering working software early and often.
That is not a small philosophical difference.
In software, the hard part is often not writing the code. The hard part is discovering what actually solves the problem, what users really need, and which constraints were misunderstood at the start.
That is why large batches are dangerous. They delay learning.
Why Teams Drift Back To Waterfall
This drift happens for structural reasons, not because teams are stupid.
1. The business still wants certainty up front
Budgets are set annually. Leadership wants roadmap commitments. Sales wants dates. Stakeholders want to know what will ship and when.
That pressure pushes teams towards large up-front specification, because detailed plans create the appearance of control even when the work is still uncertain.
Once those commitments are socialised, changing direction becomes politically expensive. The team stops optimising for learning and starts optimising for plan conformance.
2. Specialist teams create hand-offs
A lot of organisations still separate discovery, design, engineering, QA, security, release management, and operations into distinct steps.
Even when everyone calls this a sprint process, the shape of the work is still sequential.
The ticket moves, but the feedback loop does not.
If one team writes requirements, another designs, another builds, another tests, and another approves release, then the organisation has recreated phased delivery inside an agile tool.
3. Delivery is measured more than learning
Many teams report whether planned work was completed, whether velocity stayed stable, and whether dates moved.
Much fewer teams report how quickly assumptions were tested, how much work was discarded before overbuilding, or how fast customer feedback changed the backlog.
That measurement bias matters.
What gets praised gets repeated. If teams are rewarded for predictability against a pre-agreed scope, they will behave like plan-driven delivery teams even if the framework says agile.
4. The engineering system makes small releases expensive
Some teams want to work iteratively, but their technical system fights them.
Slow CI, weak automated tests, fragile deployments, manual regression testing, and release approvals all increase the cost of shipping small changes. When each release feels risky, teams naturally batch more work together.
That creates a vicious circle:
- Releases are painful, so teams ship less often.
- Because they ship less often, each release gets bigger.
- Bigger releases create more risk and more coordination.
- That makes releases even more painful.
At that point, the sprint becomes an accounting period, not a feedback cycle.
Agile Tooling Can Support Either Model
Jira is not the problem.
Any tool can help a team coordinate work. The problem begins when the tool is treated as proof that the method is agile.
Atlassian’s own agile guidance describes agile as a set of principles, not a board configuration. That is the right framing.
A team can use Jira and be genuinely agile.
A team can also use Jira to enforce a highly bureaucratic, phase-gated, low-feedback process with modern labels.
The tool does not decide which of those is true. The operating model does.
What True Agile Actually Optimises For
Real agile teams are not anti-planning.
They just plan at the right level of detail for the level of uncertainty they are facing.
They are usually clear on:
- the problem they are trying to solve
- the outcome they want to improve
- the next small slice that can test an assumption
What they avoid is pretending they can accurately lock six weeks of detail before the first meaningful feedback arrives.
The real optimisation target is not “everyone stays busy” or “the sprint plan was completed”. It is this:
- Shorten the time between idea and feedback.
- Reduce the cost of changing direction.
- Keep batch sizes small enough that mistakes are cheap.
- Learn before the organisation becomes heavily invested in the wrong answer.
That is where the speed comes from.
Fast teams are rarely fast because they are rushing. They are fast because they stop carrying bad assumptions for too long.
A Concrete Example
Imagine a team asked to improve the internal purchasing flow.
In the pseudo-agile version, the work starts with workshops, then requirements, then design sign-off, then several sprints of implementation, then UAT, then release preparation. Everything lives in Jira. The board looks excellent.
But the real decision was made on day one. The organisation committed to a predefined solution before seeing any live behaviour.
Three months later, the feature ships and the team learns the real bottleneck was not missing workflow logic at all. It was one approval rule that should have been removed in week one.
Now compare a genuinely iterative team.
It starts with an outcome: cut average purchasing time by 40 percent.
In the first week it ships one narrow change to a small user group, measures completion time, and interviews the people using it. That test reveals the biggest delay is a single manager approval step, not the larger workflow redesign that was originally assumed.
So the team changes course immediately.
Several planned tickets disappear. A smaller change ships next. The backlog improves because reality improved it.
That is agile.
Not the absence of planning, but the willingness to let evidence rewrite the plan.
Why This Feels Hard In Large Organisations
True agile can look less comfortable to traditional management because it replaces certainty theatre with controlled uncertainty.
Instead of pretending the entire path is known, it says:
- we know the problem
- we know the next most useful step
- we will learn quickly what to do after that
That is intellectually honest, but it can feel less reassuring than a polished roadmap with dates against every box.
The irony is that the detailed roadmap often produces less certainty in the real world, because it delays the moment when wrong assumptions are exposed.
Large organisations often choose emotional comfort first and operational truth later.
That is one reason fake agile persists.
How To Move Back To Fast Feedback
The fix is usually not a new framework.
It is a change in what the team optimises for.
Start here:
- Define outcomes, not just feature scope.
- Break work into slices that can ship and teach you something quickly.
- Reduce hand-offs by giving teams more end-to-end ownership.
- Invest in CI, automated testing, deployment safety, and feature flags.
- Treat changed plans as evidence of learning, not evidence of failure.
Small technical improvements matter here more than many teams realise.
If deployments are safe, tests are fast, and incomplete work can be hidden behind flags, then iterative delivery stops being a slogan and becomes operationally practical.
This is one reason high-performing engineering organisations tend to care so much about small batch sizes, continuous integration, and fast release paths. Google Cloud’s DORA guidance on reducing batch size makes the logic clear: smaller changes are easier to review, test, diagnose, and recover.
That is not separate from agile. It is one of the engineering foundations that makes real agile possible.
A Better Test Of Agility
If you want to know whether a team is genuinely agile, do not start with the ceremonies.
Ask:
- How quickly can the team put a real change in front of users?
- How cheaply can it change course after learning something important?
- How much work in progress exists that nobody has validated yet?
- How many approvals or hand-offs sit between idea and production?
- Are tools helping the team learn faster, or helping the organisation defend the original plan?
Those questions reveal more than any framework label.
Final Take
Most teams do not fail at agile because they picked the wrong board or ran the wrong ceremony.
They fail because the organisation keeps the old incentives: fixed commitments, specialist silos, big batches, and a preference for reporting progress against the plan rather than discovering the truth quickly.
So the language changes, but the delivery model does not.
If you want real agility, the target is not better agile theatre. It is faster feedback, cheaper learning, and smaller bets.
That usually means less confidence up front, more evidence early, and more willingness to let reality win.