Unhappy Agile Teams Are Unhappy in Familiar Ways

There’s a famous Leo Tolstoy line in “Anna Karenina“: “All happy families are alike; each unhappy family is unhappy in its own way.” (рус. “Все счастливые семьи похожи друг на друга, каждая несчастливая семья несчастлива по-своему.”) Unhappy Agile teams like to believe the same thing: that their dysfunction is unique or special. It rarely is.

In reality, most struggling teams fall into a small number of very predictable traps.

Before assuming your team is getting the promised benefits of Agile methodologies, i.e., better outcomes and happier teams, it’s worth checking for some extremely common anti-patterns. Many of them look productive on the surface. Most of them use Agile vocabulary. And most of them quietly undermine what Agile is meant to achieve.

To understand why these patterns show up so often, it helps to start with a quick look at where Agile came from.

Waterfall vs. Agile

Waterfall is an older product development method built around a linear, sequential process. Requirements are defined upfront, designs are finalised, engineering builds, QA tests, and only then does the product ship. Each phase hands work off to the next, and feedback from real users generally arrives very late… if it arrives at all.

This approach can feel reassuring to organisations because it promises predictability and control. Unfortunately, it also assumes that we can fully understand the problem before we start building a solution, which is rarely true.

Agile emerged as a response to these limitations. Instead of treating development as a series of hand-offs, Agile is meant to be adaptive and collaborative. Cross-functional teams work together to solve user problems, learning through small experiments, regular feedback, and continuous iteration.

The goal os Agile isn’t speed for its own sake. It’s about learning quickly and building the right thing.

Many teams claim to be Agile. Far fewer actually behave that way.

AgileFall: Waterfall in Agile clothing

AgileFall is an unholy hybrid of Agile and Waterfall. It usually happens when senior leadership still wants the comfort of a top-down approach, approving features and plans in advance, but also wants the benefits they believe Agile teams deliver, such as faster delivery.

On the surface, AgileFall looks busy and iterative. Product iterates on requirements documents. Design explores and experiments. Engineering tries different approaches before settling on an implementation.

The problem is that all of this iteration happens independently.

Each phase still occurs in sequence. Work is still thrown over the wall. Each group is forced to work with decisions made without their involvement, rather than collaborating as a single team to solve well-understood user problems.

AgileFall is still a Waterfall; it simply applies Agile principles within individual silos instead of across the whole team.

You’ll know you’re working in AgileFall if there’s plenty of experimentation, but little to no real collaboration between product, design, and engineering. That’s no Agile. It’s just a slower Waterfall.

Design as a service organisation

In Agile teams, design is not an add-on. It’s a core part of how work gets done.

When design is treated as an external service, something teams “call in” when they need screens or mock-ups, the quality of the work almost always suffers. Agile teams are cross-functional by nature. Product, engineering, design, research, and anyone else involved in making decisions should be working together as one team.

Teams with embedded designers and researchers tend to be more genuinely Agile. Designersdevelop a deeper understanding of the product and its users, and they’re able to influence problem-solving much earlier in the process.

This doesn’t mean designers can’t have a design manager, a career framework, or regular forums with other designers to discuss wider initiatives. Those things often work very well. The danger appears when design is treated like an external resource rather than a real team member, i.e., brought in late and excluded from shaping the work from the start.

Feature factories

Agile teams that focus exclusively on shipping features, without ever revisiting or improving them, are often referred to as feature factories.

These teams do all the “right” things on paper. They run stand-ups. They track velocity. They move work across the board. But once a task is marked as Done, it is rarely questioned again. Iteration stops at delivery.

Feedback, when it exists, rarely results in change. Features pile up without anyone stepping back to ask how they fit together, whether they’re solving the underlying problem, or whether the user experience is actually improving.

Caring about velocity doesn’t automatically make a team a feature factory. Measuring pace can be useful; it can highlight when something has gone wrong. The problem arises when velocity becomes the only thing that matters.

Agile teams should care about how quickly they can learn and respond to user needs. Sometimes building the right thing takes a little longer upfront than building the wrong thing. But it almost always saves time in the long run by avoiding endless rework.

Complete chaos

A lack of rigid roadmaps does not mean a lack of direction.

While many Agile teams avoid committing to detailed plans months in advance, they should still be able to explain what they’re working on now, what problem they’re trying to solve, and how they’ll know when they’ve solved it.

Teams in complete chaos jump from one request to another, often driven by whichever customer or stakeholder asked most recently. Work is frequently abandoned halfway through as priorities change without warning. People have no idea what’s coming next, or whether the work they’re doing will ever ship.

This is not flexibility. It’s exhausting.

There’s an important distinction between refusing to over-commit and having no shared understanding at all. Teams that rigidly follow roadmaps can easily become feature factories. Teams with no backlog or direction often fall into chaos. As long as a team understands the problem it’s tackling and what success looks like, it can experiment and pivot without being constantly derailed.

Feeding the beast

Feeding the beast happens when teams expect designers and researchers to operate at the same pace as engineering, i.e., constantly producing new designs so development never has to slow down. The result is predictable: burnout, shallow thinking, and very little meaningful iteration.

Designers and researchers rush from feature to feature, while engineers complain if designs aren’t “finished”. Often, engineering refuses to begin work without a complete set of final designs, turning the process into yet another variation of AgileFall. Older features are rarely revisited, and learning stalls.

Ironically, according to Laura Klein, this anti-pattern is often one of the easiest to fix.

When teams invest time in refactoring and improving their codebases, engineering gains breathing room. Designers and researchers gain time for discovery and experimentation. Cleaner systems are easier and safer to work with, which often allows teams to move faster overall when they do focus on shipping new user-facing features.

The common thread

All of these anti-patterns share something important: they mistake activity for agility.

Agile isn’t about rituals, speed, or iteration. It’s about collaboration and continuously aligning what you build with real user needs.

If your team feels unhappy, stuck, or busy without making progress, odds are you’re not alone, and you’re probably not broken in some unique way. You might just be stuck in a very familiar trap.