Agile in Practice: Nine Years of Field Notes

Names and details have been changed. The situations are real. The people are not the point.

The manifesto is not the problem

The Agile Manifesto is 68 words and still holds up in 2026. The multi-billion dollar industry built on top of it does not. After nine years leading agile teams, I’ve stopped using story points, switched to anonymous retro input, replaced sprint commitments with sprint goals. Here’s why.

It was a Thursday afternoon, about four years ago. We were in a retrospective. Eight engineers, one product manager, a room with whiteboards on three walls. The facilitator asked the usual question: “What could we improve?” Silence. Then safe answers. “Better documentation.” “Fewer meetings.” The things people say when they don’t feel safe saying what they actually think. Then a developer named Karim, quiet, maybe two years out of university, said something I’ll never forget. “We spend more time estimating the work than it would take to just do the work.” Dead silence. The product manager looked at the Scrum Master. The Scrum Master looked at me. Nobody argued. Because everyone in that room knew he was right. We’d spent two hours that Monday in planning poker for a sprint’s worth of work that took three and a half days to build. The ceremony had become more expensive than the thing it was supposed to estimate.

That was the week I started questioning everything about how we practiced agile. Not the manifesto. The practice.

Read it today. It still holds up. Prefer people over process. Ship working software. Collaborate with customers. Respond to change. None of this is controversial. None of it is wrong.

The problem is what happened after.

A multi-billion dollar industry grew on top of those 68 words. Certifications that cost thousands. Frameworks with their own vocabulary, their own hierarchies, their own consulting ecosystems. SAFe alone has 95 articles on its website explaining how to do something that was originally described on an index card. Ninety-five.

The manifesto was written by practitioners. The industry that followed was built by people who sell methodologies to companies that don’t understand why their software teams are slow. The manifesto diagnosed the disease. The industry decided to sell the cure. And the cure became the new disease. Like a tagine recipe that starts with four ingredients and ends up with forty because every food blogger needed to add their own twist.

I’ve spent nine years working with agile teams. I’ve seen the manifesto work. I’ve also seen it weaponised. This is what I’ve learned.

What goes wrong with agile in practice?

Every two weeks, a group of developers sit in a room and plan work they will almost certainly not finish as planned. This is called a sprint. The word implies speed and urgency. The reality is closer to a relay race where someone keeps moving the finish line.

Here’s what I’ve observed, across multiple teams and organisations, without naming anyone.

Sprints become mini-waterfalls. The team spends Monday planning. Tuesday through Thursday building. Friday testing and scrambling. The iteration is shorter but the pattern is identical to what agile was supposed to replace. Requirements flow down. Code flows up. Nobody questions the direction mid-sprint because the sprint commitment is sacred. Sound familiar?

Retrospectives become theatre. The team gathers. Someone asks what went well. People say safe things. Someone asks what could be improved. People say safer things. The action items go on a list. The list is never revisited. The real problems are about power, trust and incentives. Those don’t fit on a sticky note.

Story points become a performance metric. This is the one that gets me. Story points were invented as a relative estimation tool, a way for a team to have a conversation about complexity. I’ve seen teams use them well — small groups where the numbers stayed internal, where nobody above the team ever saw the velocity chart, where the conversation mattered more than the count. But that’s rare. Somewhere along the way, management started tracking velocity. Then comparing velocity across teams. Then using velocity in performance reviews. A tool for planning became a tool for surveillance. That Jira board had more columns than a Roman temple.

Product owners become project managers with a new title. The role was supposed to be the voice of the customer, someone with deep domain knowledge who makes prioritisation decisions. In practice, it’s often a project manager who relays requirements from stakeholders and tracks delivery dates. The team doesn’t interact with customers. They interact with a backlog.

Standups become status reports. Fifteen minutes of “yesterday I did X, today I will do Y, no blockers.” Nobody listens. Everybody waits for their turn. The purpose was to coordinate and unblock. The result is a daily ritual that could be replaced by a Slack message.

I’m not describing bad teams. I’m describing normal teams. Smart, well-intentioned people operating inside systems that have drifted far from the principles they claim to follow.

What I’ve observed across teams, summarised:

• Sprints become mini-waterfalls. Shorter cycles, same top-down flow.
• Retrospectives become theatre. Safe answers, no real problems discussed.
• Story points become surveillance. Estimation tool turned performance metric.
• Product owners become project managers. Relaying requirements instead of representing users.
• Standups become status reports. No coordination, just waiting for your turn.

The respect problem

I keep coming back to this. Most agile implementations fail because they don’t respect the people doing the work.

And there’s something even more basic that bothers me. Companies force teams into a system without ever asking whether the system fits. A team is losing velocity. The response? More process. More ceremonies. A new framework. SAFe on top of Scrum on top of Kanban. Nobody stops to ask: what’s actually blocking this team? Is it a process problem or a people problem? A tooling problem or a trust problem? Nine times out of ten, the answer has nothing to do with the methodology. It’s unclear priorities, too many meetings, technical debt nobody wants to address, or a manager who won’t make a decision. You don’t fix that with a framework. You fix it by listening.

Respect isn’t a poster on the wall. It’s a structural choice. And most organisations make structural choices that contradict the word while using it freely in their values deck.

Developers are asked for estimates. Then held accountable when estimates are wrong. An estimate is, by definition, a guess. When you treat a guess as a commitment, you’re not doing agile. You’re doing contracts with shorter deadlines.

Teams are told they’re self-organising. Then given a roadmap with no room to negotiate. Self-organising means the team decides how to achieve the goal. It doesn’t mean the team decides the goal. But when the “how” is also pre-determined by architecture decisions made three levels up, the self-organising part is fiction. Pure fiction.

Engineers are asked to participate in planning poker. Then the highest estimate is questioned. “Why do you think this is an 8? Can we get it down to a 5?” That’s not estimation. That’s negotiation. And the person with less power always loses. Every time.

The manifesto says “build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Trust. The word appears once in the manifesto and it’s the one most organisations struggle with. You can’t have agile without trust. And trust is expensive. I’ve worked under one leader who genuinely got this right — she never asked for estimates, just asked what the team needed to ship confidently. That team was the fastest I’ve ever been part of. It means accepting that the team knows more about the work than you do. It means letting go of the illusion that more oversight produces better outcomes. Most managers aren’t willing to pay that price. I might be wrong, but I think that’s the root of most of what I’ve described above. I’m still working out how to build trust faster with new teams. I don’t have a formula for it yet.

What I do differently

I’ve been leading teams long enough to know what doesn’t work. Here’s what I do instead.

No story points. I’m proud of this one. The decision crystallised after Karim’s comment in that retro. We finished the sprint, and I ran an experiment the next one. No points. No planning poker. Just t-shirt sizes for rough scoping and conversations about complexity. If a piece of work needs more precision, we break it down until the pieces are small enough that estimation is unnecessary. I will never use a number that can be turned into a KPI. Ever. Two sprints in, nobody missed the points. The planning meetings got shorter. The work got done at the same pace. The only thing that disappeared was the anxiety around the numbers.

Anonymous retrospective input first. Before the meeting, everyone submits topics anonymously. This levels the field. The junior developer who would never speak up in front of the lead architect can say what they actually think. We discuss the themes, not the people.

Sprint goals instead of sprint commitments. A goal gives direction. A commitment creates pressure to cut corners. We agree on what we’re trying to achieve, and the team decides what work supports that goal. If something takes longer than expected, we adjust scope, not quality.

20% of capacity is protected for exploration. Every sprint, one-fifth of the team’s time is unplanned. Bug fixes, technical debt, learning, prototyping. This isn’t a luxury. It’s how you maintain a codebase and develop people. A team at 100% utilisation is a team that never improves. I use my Notion thinking system to track what that 20% produces. It’s where the best ideas surface.

Clear about WHAT and WHY. The team decides HOW. I bring the context. I explain the business problem, the user need, the constraints. The team proposes the solution. I don’t dictate architecture, tools or approaches. If I have to tell a senior engineer how to solve a problem, either I hired wrong or I’m managing wrong. Probably both.

Hire for respect first, skills second. I can teach someone a new framework in a month. I can’t teach them to treat a colleague as an equal. The person who dismisses the QA engineer’s opinion will poison a team faster than any technical debt. I screen for how candidates talk about the people they’ve worked with. That tells me everything. Last year I passed on a candidate with a strong technical profile. Clean code, solid system design, good communication in the interview. But when I asked about a project that went wrong, every sentence started with what someone else did wrong. The PM didn’t scope it properly. The designer changed the spec. The other engineer didn’t write tests. Not once did he mention what he could have done differently. I called the recruiter that afternoon and said no. My team doesn’t need more skill. It needs more accountability.

Why does agile fail in large organisations?

Agile works. But only under conditions that most organisations don’t have.

It works in small teams. Five to eight people who know each other, trust each other, share context. It works when the team has autonomy to make real decisions. It works when leadership provides clear goals and then gets out of the way. It works when feedback loops are short enough to matter.

It breaks in large organisations. Not because the principles are wrong, but because large organisations are optimised for control. Hierarchy exists to manage information flow and reduce risk. Agile exists to distribute decision-making and accept risk. These are fundamentally opposed. You can’t bolt agile onto a command-and-control culture and expect transformation.

I’ve watched companies try. They rename roles. They buy tools. They hire Scrum Masters and draw process diagrams. The ceremonies change but the power structures don’t. The team does standups but the VP still decides what ships. The retro happens but the org chart still determines who speaks.

The culture has to change first. And culture change doesn’t come from a framework. It comes from leaders who are willing to give up control. That’s rare, because control feels safe. Especially to the people who have it. The same dynamic plays out with enterprise AI adoption. The technology is ready, but the culture isn’t.

Does that scale? No. Does it matter at this stage? Also no. What matters is whether the people in the room feel heard. This is connected to something I believe deeply: those who build have as much value as those who decide. The salary system doesn’t reflect this. The org chart doesn’t reflect this. Agile was supposed to reflect this, but most implementations preserve the same hierarchy they claim to flatten.

What from agile is still worth keeping?

I don’t want to end cynical. The manifesto gave us ideas worth keeping, even if the industry built a circus around them.

The retrospective. If done honestly, it’s the most valuable meeting a team can have. The habit of regularly asking “what should we change?” is worth more than any framework. The key word is honestly.

Short feedback loops. Ship something. See if it works. Adjust. This isn’t an agile idea. It’s the scientific method applied to software. It existed before the manifesto and will exist after every framework is forgotten.

Working software as the measure of progress. Not slide decks. Not Gantt charts. Not story points completed. Working software that users can touch. This single principle would fix most of the dysfunction I’ve described if organisations actually followed it.

Self-organising teams. The best work I’ve ever seen came from teams that chose their own approach, debated their own trade-offs, owned their own outcomes. Not because a framework told them to. Because they were given the trust and the room to do it.

These aren’t agile ideas. They’re good engineering ideas. They existed before the manifesto and they’ll exist long after the certifications expire. The manifesto didn’t invent them. It gave them a name and a community. That was enough.

The rest we can let go.