The Feature Team Fallacy: Why Your “Agile” Teams Are Just Waterfall in Disguise

There’s an uncomfortable conversation we need to have about your team structure. Not the one where we debate Scrum vs. Kanban, or whether stand-ups should be fifteen minutes or twenty. I’m talking about the one where we admit that despite all our agile ceremonies, retrospectives, and meticulously groomed backlogs, most of us have accidentally rebuilt the exact same dysfunctional organisation our predecessors escaped from twenty years ago.

As the economist Thomas Sowell observed, “It is hard to imagine a more stupid or more dangerous way of making decisions than by putting those decisions in the hands of people who pay no price for being wrong.” In software, we’ve done something equally absurd: we’ve created teams structured around our expertise rather than customer value, and then act surprised when delivering value takes six months and seventeen handoffs.

The Seductive Lie of Component Teams

You’ve seen this movie before. The database team. The API team. The frontend team. The mobile app team. Each team has their domain, their expertise, their carefully guarded territory.

On paper, it makes sense. Deep expertise! Clear ownership! Nobody stepping on anybody’s toes!

In practice, it’s a disaster wearing a process costume.

What we don’t talk about is that component team structures quietly reinforce sequential development. Craig Larman and Bas Vodde, in their work on Large-Scale Scrum, put it bluntly: component teams create “many queues with varying-sized work packages, high levels of WIP, many handoffs, and increased multitasking and partial allocation.” Sound familiar? That’s waterfall. We just gave it a sprint cadence and pretended we’d solved something.

Here’s what a “simple” feature looks like in a component team world: Product defines the requirement. Design creates mockups. The frontend team builds the UI. They wait for the API team to expose the endpoint. The API team waits for the database team to update the schema. The database team is blocked on the DevOps team approving their migration. Meanwhile, QA has been sitting idle for three weeks waiting for something to test.

Every handoff is a queue. Every queue introduces delay. Every delay multiplies uncertainty. And somewhere in the midst of all this coordination theatre, someone asks why we can’t ship faster.

The Feature Team Revolution (That Most Companies Botched)

The antidote, in theory, is the feature team: a long-lived, cross-functional team that takes a complete customer-centric feature and does all the work necessary to deliver it. Analysis, design, development, testing — the whole thing, from concept to production.

Matthew Skelton and Manuel Pais popularised this thinking in Team Topologies, describing what they call “stream-aligned teams” — teams organised around the flow of work rather than technical components. These teams own outcomes, not outputs. They can deliver value directly to customers without waiting for someone else to approve, implement, or integrate their work.

The LeSS framework takes it further, explicitly advocating for feature teams that work across the entire codebase, because — and this is the uncomfortable bit — if you can’t trust your engineers to work across components, you have a skills problem, not an organisational problem.

Martin Fowler, writing about Team Topologies, captures the essential insight: “The primary benefit of a platform is to reduce the cognitive load on stream-aligned teams.” Not to enforce consistency. Not to centralise expertise. Not to create fiefdoms. To reduce cognitive load so that the people closest to the customer can actually move.

But here’s what most organisations get wrong: they create “feature teams” that still can’t actually deliver a feature end-to-end. They can work on the frontend, sure, but they still need to raise a ticket with the platform team to get their API deployed. They can write the code, but they don’t own the database. They can build the feature, but they can’t run an experiment without three approval workflows.

That’s not a feature team. That’s a component team with better marketing.

Why This Matters for Experimentation

Let’s talk about A/B testing, because this is where the dysfunction becomes impossible to ignore.

Experimentation is the engine of data-driven product development. You have a hypothesis. You build a variant. You measure the difference. You learn. But experimentation only works when you can move fast enough that the learning actually matters — and when you have enough context to understand what the data is telling you.

Here’s the problem: when a feature is sliced across multiple teams, you cannot effectively experiment on it.

Imagine you’re running an A/B test on a new checkout flow. The test starts failing. Conversion drops. What’s going wrong?

If your team owns the entire experience — frontend to backend to data layer — you can investigate. Is it the UI confusing users? Is the new API slower? Is there allocation bias in how users are being bucketed? Is there something in the data pipeline miscounting conversions?

But if the frontend is one team, the API is another, the allocation logic is owned by a “platform” team, and the data pipeline is somewhere in analytics land? Good luck. You’re now trying to debug a distributed system failure across four team boundaries, three Slack channels, and two time zones. By the time you’ve assembled the cross-functional task force to investigate, your test window has closed, your data is inconclusive, and leadership is asking why experimentation seems to take longer than just shipping features.

End-to-end ownership isn’t a nice-to-have for experimentation. It’s the prerequisite. If you can’t understand the entire stack your experiment touches — the code, the data, the UX, everything — you can’t diagnose what’s happening when results surprise you. You can’t move fast enough to iterate. You can’t build the institutional knowledge that makes each subsequent experiment more valuable than the last.

The Evolution Nobody Planned

The history of team structure in software development is basically a long argument between efficiency and effectiveness that nobody has conclusively won.

In the beginning, there were functional silos. Analysts analysed. Programmers programmed. Testers tested. Work flowed between departments like a relay race where the baton got dropped at every handoff. This was waterfall, and we all agreed it was bad.

Then came Agile and the cross-functional team. Put everyone in the room together! Let them self-organise! Work in iterations! This was better, but as organisations scaled, something strange happened: they kept creating more and more specialised teams to “support” the delivery teams. Platform teams. Infrastructure teams. Data teams. Architecture review boards.

Each new team was created to solve a genuine problem. But collectively, they recreated the exact coordination hell we were trying to escape. The handoffs just moved. Instead of “development complete, handing off to QA,” it became “code complete, waiting for platform to provision.” Same queue, different label.

The LeSS framework explicitly embraces queueing theory to explain why this happens: every time you create a specialised team, you create a queue. Every queue increases cycle time. Every increase in cycle time reduces feedback speed. Every reduction in feedback speed makes it harder to learn and adapt. This is why LeSS advocates for feature teams that can work across the entire product — not because specialisation is bad, but because the cost of coordination at scale is almost always worse than the cost of learning.

Team Topologies offers a more nuanced take: not every team should be stream-aligned. You genuinely need platform teams to reduce cognitive load. You need enabling teams to help others adopt new practices. You need complicated subsystem teams for domains that require deep specialist knowledge. But these teams exist to serve the stream-aligned teams, not to gatekeep them.

The shift is subtle but profound. The question isn’t “who owns this component?” It’s “who is responsible for this outcome?” And the answer should be: a team that has everything they need to deliver that outcome without waiting for anyone else.

What Actually Works

We’ve been experimenting with this at Agoda for years now, and I wish I could tell you there’s a simple formula. There isn’t. But there are patterns that consistently help:

Teams need all the expertise required to solve the problem at hand. This might include UX designers, security experts, data engineers, or legacy system specialists depending on what you’re building. The point isn’t that every team has identical composition — it’s that every team can actually finish what they start. If you regularly need to bring in external expertise to complete work, that’s a signal your team boundary is in the wrong place.

Cross-functional collaboration isn’t a nice-to-have — it’s the point. When UX, engineering, and data work together from the start, all aspects of the product get considered from the beginning. This sounds obvious until you watch a team design a feature in isolation, hand it to engineering, then discover six weeks later that the analytics requirements make the original design impossible. Cross-functional teams catch these issues in hours, not months.

Ownership must be end-to-end. This is the hardest part, because it often means challenging existing team structures that people have built careers around. But a team that can’t deploy their own code, run their own experiments, or observe their own systems in production isn’t actually owning anything. They’re just another queue in someone else’s pipeline.

Here at Agoda, that means teams own their features from conception through experimentation through production. When an experiment starts showing unexpected results, the team that built it has access to every layer of the implementation. They can trace the problem from the bucketing logic through the API through the data pipeline. They don’t need to file a ticket and wait three days for the data team to tell them what happened.

The Transition Nobody Wants to Make

Moving from component teams to feature teams is organisationally painful. It threatens existing power structures. It requires people to learn skills outside their comfort zone. It feels risky because now you don’t have “the database expert” you can escalate to when something goes wrong.

I learned this firsthand about ten years ago at Agoda. Back then, we were organised the traditional way — backend teams, frontend teams, mobile teams, all neatly siloed. I had two “backend engineers” assigned to my team to handle the backend work. Problem was, for the first two sprints, we had no backend work. None.

So I sat down with them, and I started the conversation the only way that actually works: “Would you like to learn something new?”

The answer, obviously, was yes. It’s almost always yes. People want to grow — you just have to frame it as opportunity rather than obligation.

“Great,” I said. “I’m going to teach you React. You’re going to go slower at first, and that’s fine. But you’ll be learning, and you’ll be working on the most valuable thing instead of sitting idle waiting for backend tickets that don’t exist.”

There’s genuine business value in upskilling your people, but you have to be willing to accept the short-term productivity hit. Most organisations aren’t. They’d rather have someone sit idle in their specialisation than go slower while learning to contribute more broadly.

Which reminds me of a story Bas Vodde tells. He was in the car with his five-year-old son, stuck in peak-hour traffic. His son looked at the cars flying past on the other side of the road and said, “Daddy, I want to go fast like those cars!”

Bas replied, “But they’re going in the wrong direction. What do you want — to go really fast in the wrong direction, or slow in the right direction?”

His son, being five years old, said: “Daddy, I want to go really fast in the wrong direction!”

Bas remarked afterwards how many people in engineering leadership make exactly the same call. They’d rather optimise for speed within their broken structure than accept the temporary slowdown required to fix the structure itself. We celebrate teams that ship fast without asking whether they’re shipping the right things, or whether the organisational friction they’re navigating could be eliminated entirely.

But consider the alternative: perpetually slow delivery, experiments that can’t be diagnosed, and an organisation that moves at the speed of its slowest queue — which, by the way, is always the team you didn’t realise was a bottleneck until you needed something from them urgently.

The LeSS approach suggests starting slow: establish one feature team within the existing component team organisation. Let them prove the model works. Then expand. This takes years, not months, and it requires sustained commitment from leadership that most organisations simply don’t have.

Team Topologies offers a softer path: keep your platform teams, but turn them into true self-service platforms. The measure of success isn’t how much they control — it’s how much they enable. If stream-aligned teams can consume the platform’s services without human coordination, you’re doing it right. If every interaction requires a meeting and a ticket, you’ve just created another queue with better branding.

The Bottom Line

As the basketball coach John Wooden once said, “Never mistake activity for achievement.” We’ve built organisations that are extraordinarily active — meetings, ceremonies, coordination, planning — and remarkably poor at achieving outcomes. We’ve optimised for the appearance of productivity while systematically undermining actual delivery.

The feature team model isn’t about destroying specialisation or pretending everyone can be an expert in everything. It’s about recognising that in knowledge work, the cost of handoffs and coordination dwarfs the benefits of hyper-specialisation. It’s about understanding that experimentation — the core engine of learning — requires ownership broad enough to actually understand what’s happening. It’s about admitting that most of our organisational structures were designed for a world of predictable manufacturing, not adaptive product development.

Your teams are probably some flavour of component teams right now, even if you call them something else. You probably have “cross-functional” teams that still can’t deliver a feature without coordinating with three other groups. You probably have experimentation ambitions that keep getting stalled because nobody can diagnose why tests are behaving unexpectedly.

The fix isn’t another process. It’s not another coordination meeting. It’s not a better ticketing system for managing cross-team dependencies. The fix is removing the dependencies in the first place — building teams that can actually own outcomes, not just execute tasks in someone else’s workflow.

Now, if you’ll excuse me, I need to go untangle another cross-team dependency that’s blocking our latest experiment. But hey, at least our Jira board looks beautiful.