How agile became a checkbox exercise, and how to get unstuck

Agile started with a promise. It would make teams faster, more adaptive, more aligned. Work would become leaner, cycles shorter, and delivery more meaningful. The Agile Manifesto was only 68 words, but those words introduced an entirely new way of thinking: prioritize individuals over tools, working software over documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

It felt radical because it was. But like many radical ideas, agile changed the world and then lost its edge.

Today, agile is everywhere. But so is the feeling that it isn’t working.

Sprint ceremonies are held. Velocity charts are up. The standups are short and punchy. The retrospectives are civil.

And yet the product is stuck. The roadmap doesn’t excite anyone. The backlog is overflowing. Stakeholders are nervous. And the team feels like it’s doing everything “right,” but not getting anywhere.

Sound familiar? This might be because you’re treating agile as a checkbox exercise.

The death spiral of ritual over reason

Ritual is a natural human impulse. We like to do what we did yesterday, especially when yesterday had a name and a cadence: Sprint 42, Retrospective 43, Planning 44.

But rituals only work when they’re driven by reflection. When ceremonies become habitual, when metrics are gamed, when tickets are moved for movement’s sake, agile loses its meaning.

Velocity becomes a vanity metric, increasing but not tied to impact. Retrospectives feel like a group therapy session with no actionable outcomes. Standups become status updates, not strategic conversations. And the backlog becomes less of a plan and more of a junk drawer.

Jason Kirby, a product and technology leader, frames the issue bluntly: many organizations try to shoehorn in process “because a book tells them to or because the order came down from above.” The result? “You end up with a bunch of people who are forced into an unnatural pattern.” His advice: strip back the dogma. “Make it as lean and lightweight as possible.”

Recognizing the symptoms of process fatigue

Diagnosing process fatigue is one of the most under-discussed skills in product management. Everyone wants to talk about strategy. Fewer people want to admit that their rituals feel hollow:

 

 

Here are a few tell-tale signs:

• Backlog bloat — Hundreds of items, few of which anyone can explain. Prioritization becomes impossible, and grooming sessions turn into debates about old ghosts
• Fake velocity — Teams move fast, but the definition of “done” has quietly lowered. Tickets close quickly, but features don’t ship. Or if they do, they don’t move the needle
• Low morale — Talented people feel like they’re just burning cycles. Engineers disengage. Designers recycle old patterns. PMs focus more on “managing the process” than leading the product
• Ceremony saturation — Too many meetings, too little meaning. The week becomes a series of rituals, leaving little time to think, create, or solve

Nicole Keith, CPO at Omnicom Health Group, saw this firsthand. “We had so many people involved [that] people weren’t sure who to talk to,” she recalls. Her solution? Reduce layers. “The best thing I can do is get out of their way.”

Diagnosing the root causes

Agile is supposed to be iterative. But in many cases, it’s become circular. The same meetings, same issues, same debates, just under a new sprint number.

Here’s what usually drives the dysfunction:

• Process inertia — Once a process is in place, it tends to calcify. Teams fear that changing rituals will signal chaos, so they preserve broken ones
• Misunderstood metrics — Velocity becomes a scoreboard, and like any scoreboard, it gets gamed. Teams inflate points, scope down work, and ship safe features to look fast
• Detached ceremonies — Planning sessions and retros lose their soul. People stop preparing, stop reflecting, stop engaging

The biggest red flag? No one can answer the question: “What is this process helping us learn?”

ING Netherlands shows what happens when you treat the process itself as a product. In 2015 the bank blew up its old reporting lines and reorganized 3,500 HQ staff into roughly 350 nine-person “squads” nested inside 13 tribes.

The payoff was immediate: releases that once landed five or six times a year now ship every two to three weeks, while both customer-satisfaction and employee-engagement scores climbed “multiple points” in the first fifteen months. CIO Peter Jacobs credits the jump to empowered, end-to-end squads that answer to outcomes, not paperwork, proof that speed follows structure when the structure is built for learning.

Rich Lau, engineering leader at Omnicell, pushes teams to prioritize learning over documentation. “You can’t see five miles ahead,” he says, “but you can see 100 feet. Drive that 100 feet, then adjust.”

Reimagining agile

Agile was never about frameworks. It was about outcomes. The best teams don’t just run agile. They treat the process itself as a product, something to be tested, refined, and iterate:

 

 

Here’s what that looks like:

• Outcomes over outputs — Every sprint ties to a clear, user-centered goal. Not just “what are we building,” but “what are we solving?”
• Learning over velocity — A fast team that learns nothing is a slow team. Create space to test, fail, and reflect. Make experiments part of the roadmap
• Clarity over cadence — Consistency is good. Clarity is better. If a ceremony isn’t working, change it. If a meeting isn’t needed, cancel it

Nick Fisk, Senior Director of Product at Altice USA, encourages teams to “correlate backlog items to actual customer needs,” and prioritize accordingly. He says, “We don’t just want to build what we planned. We want to build what matters.”

Getting the team onboard and co-creating the process

Process only works when the team owns it. Agile can’t be dictated from the top down, it has to be co-created.

Ask your team:

• What ceremonies feel useful? What don’t?
• Where do we feel most blocked?
• What does “impact” look like to us?

Jason Kirby emphasizes the power of joint ownership, pointing out that product typically owns the why while engineering owns the how — but the real magic happens in the conversation between those two.

Liz Li, CPO at Velocity Global, believes product teams must prove their value by results. “When the rubber hits the road, are you actually seeing an impact?”

Reset without rebellion

You don’t have to blow everything up to fix agile. In fact, dramatic change often creates fear. Instead, reset in phases:

• Audit — Take stock of every ceremony, tool, and metric. Ask: Is this helping us deliver better outcomes?
• Prioritize — Identify the top one to two pain points. Don’t try to fix everything. Start small
• Experiment — Choose one new way of working. Test it for two sprints. Reflect
• Scale — If it works, keep it. If it doesn’t, learn and adapt

Call it meta-Agile. Use agile to fix agile.

The path forward: Intention over imitation

Agile wasn’t designed to make you feel busy. It was designed to make you feel effective.

---

---

If your team is going through the motions but not seeing results, stop and ask:

• What problem are we solving with this process?
• Is our backlog a source of clarity or chaos?
• Are we optimizing for delivery, or for discovery?

Todd Buelow says it plainly: “You can’t fall in love with your own plans.”

Agile isn’t the goal — impact is. The best teams aren’t the ones with the cleanest Jira boards. They’re the ones building products that matter. Getting there requires honesty, reflection, and the willingness to change the answers.

Featured image source: IconScout