Not Every Scrum Team Is Agile: Fake Agile

Fake Agile: Is every Scrum team agile?

No, unfortunately not every Scrum team is actually agile.

Let me explain: A Scrum team is defined by working according to the Scrum framework: So it has sprints, certain roles and rituals. And since the purpose of the Scrum framework is to help teams work in an agile way, Scrum should automatically make every team agile, right?

Unfortunately, in practice, organizations repeatedly manage to introduce Scrum and make the teams anything but agile. This is often referred to as “Zombie Scrum”.

What is “Fake Agile”?

“Fake Agile” refers to teams that officially work with agile frameworks and methods, but without actually having learning loops with customers. Fake Agile therefore means that you either a) don’t deliver iterative increments to customers at all or b) don’t use direct customer feedback on the increment for short-term prioritization.

What are the causes of Fake Agile?

There are many reasons for “Fake Agile”. In my experience, the most common causes of Fake Agile in practice are as follows:

Fake Agile Cause #1: No customer feedback

If an agile team does not receive direct feedback from users, it cannot work in an agile way. In practice, customer requests are often formulated by management and passed on to teams via product owners – Real feedback loops with customers are stunted or do not even exist.

An agile team needs direct customer contact!

Fake Agile Cause #2: Focus on Velocity & Story Points

Phew, do we need to say much more about story points in 2025? I think we’ve all had enough experience of how much a focus on velocity and story points stands in the way of customer benefit.

An example: What happens if a function is formally ready after the first iteration, but does not yet achieve the customer benefit? If the customer benefit is important to us, then we work on it until the customer benefit is actually achieved. In the end, it may take 3 iterations, but at least the customer is now happy.

But wait, now my manager suddenly comes around the corner and complains that my team implemented fewer story points in the last sprint. So it would have been better for my velocity if we had simply left the non-valuable function and worked directly on the next function so that we could create more story points.

What nonsense, right? If we repeat this process for a few more months, we will have a product with a lot of functions that create very little customer benefit.

So it should come as no surprise when both customers and development teams become unhappy and leave.

In more general terms, this is about a now well-known law: Goodhardt’s Law

“When a measure becomes a target, it ceases to be a good measure.”

Fake Agile Cause #3: The dogma dictatorship

Engineers love it when there are fixed rules for everything. That makes processes plannable.

So how about if we completely define our ways of working with rules - wouldn’t that be great? No, it wouldn’t.

With Scrum alone and its many rules and guidelines, agile working already feels like working according to rigid guidelines for many teams. It shouldn’t be like that. So don’t make it worse by adding more rules and guidelines to agile working.

In the best agile teams I know, work feels human, lively, spontaneous and collaborative. And admittedly, in most agile teams it doesn’t.

Agile teams must at least have enough freedom to be able to collaborate flexibly with customers. If rules and processes prevent this, the rules and processes should be questioned.

In this post, I have already written specifically about the steps necessary to protect Scrum teams from Zombie Scrum: Fix Zombie Scrum

Fake Agile is real: How to protect yourself?

Nothing fully protects you from false agility. But there is one thing that can protect you as well as possible: An effective process around continuous improvement.

Of course, this starts with good retrospectives in which team members can openly share their views and independently derive and implement measures for improvement.

As long as this process works, the potential for real agility in your team is not lost.

If you want to take your agile retrospectives to the next level, I recommend –naturally – Echometer, our tool for retrospectives. You can try it out for free here: Try Echometer