Top 7 Signs Your Team Is Doing Fake Scrum

Table of Contents

1. What fake Scrum means
2. Sign 1: the daily has turned into a status meeting
3. Sign 2: the product owner does not have the final say
4. Sign 3: the sprint has no goal
5. Sign 4: the Scrum Master runs the team
6. Sign 5: “done” means nothing
7. Sign 6: the retrospective changes nothing
8. Sign 7: velocity is used to apply pressure
9. Diagnosing your team
10. Getting out of fake Scrum without breaking everything
11. Conclusion
12. FAQ

Your team has a Scrum Master, two-week sprints and a daily every morning. Yet deliveries slip, developers burn out and management wonders what “agile” is for. In many cases, however, the problem is not Scrum. It is a Scrum that exists only on the surface.

This fake Scrum affects many teams. Indeed, copying the meetings and the job titles is easy. Changing how decisions get made takes far more effort. The result looks like Scrum, but it works like the old organization, with more meetings.

This article therefore reviews seven concrete signs. For each one, you will see what the official framework says and why the gap matters. You will also find a simple first step to fix the situation, without starting over.

What fake Scrum means

The term first describes a team that applies the forms of Scrum without its principles. The Scrum Guide, the reference text written by the creators of the framework, settles this point clearly. It states that the framework is immutable. A team can certainly implement only parts of it, but the result is then no longer Scrum.

Ron Jeffries, one of the signatories of the Agile Manifesto, calls it “Dark Scrum“. In his view, fake Scrum begins when people who know their old job, but not their new Scrum role, start running the rituals. He also stresses that these leaders usually mean well. They simply keep doing what they have always done, in a new setting.

So fake Scrum is not a matter of bad intent. It mostly comes from a lack of training and the wrong mindset. As a result, it can be fixed, as long as you know how to spot it.

Sign 1: the daily has turned into a status meeting

Every morning, each person reports what they did yesterday and what they will do today. Then a manager listens, takes notes and hands out tasks. The meeting lasts thirty minutes and nobody leaves any better off.

This is the first example of Dark Scrum that Ron Jeffries describes. The manager sees the daily as a perfect chance to check progress. Instead of organizing themselves, developers end up reporting to someone.

The Scrum Guide, however, describes something quite different. The Daily Scrum is a 15-minute event for the developers. Its purpose is to inspect progress toward the sprint goal and adapt the plan. In other words, it is a moment of coordination between peers, not a report up the chain.

The first step: refocus the daily on a single question: “are we on track to reach the sprint goal?”. If a manager attends, they listen without assigning tasks.

Sign 2: the product owner does not have the final say

The product owner exists on paper. Yet every priority has to be approved by a committee, a sponsor or a business director. So the product owner spends the day relaying requests they did not choose.

The Scrum Guide puts it plainly: the product owner is one person, not a committee. They may represent the needs of many stakeholders, but decisions about the backlog are theirs. For this to work, the organization must respect their choices.

This sign has direct consequences. Priorities change mid-sprint and trade-offs take weeks. As for developers, they no longer know who to turn to. Our article on the product owner role details what this position really requires.

The first step: write down who decides the order of the backlog. Then have management formally approve that scope.

Sign 3: the sprint has no goal

Sprint planning comes down to filling the “to do” column with as many tickets as possible. At the end, the team has delivered a list of small, unrelated tasks. Nobody can say what the sprint actually achieved.

Yet the Scrum Guide includes a sprint goal, defined as the single objective for the sprint. It gives the work coherence while leaving flexibility on the detail of each task. The framework even adds that a sprint can be cancelled if this goal becomes obsolete.

Without a goal, there is therefore nothing left to inspect. The daily loses its purpose, the sprint review becomes a ticket demo and the team cannot make trade-offs on its own when something unexpected happens.

The first step: start the next planning session with one sentence. It describes the value the sprint should deliver. Next, choose the backlog items that contribute to it.

Sign 4: the Scrum Master runs the team

The Scrum Master assigns tasks, tracks deadlines and escalates delays to management. In practice, they are a project manager under another name.

According to the Scrum Guide, the Scrum Master is accountable for the Scrum Team’s effectiveness. They help everyone understand Scrum theory and practice. They also remove impediments and guide the organization in its adoption. By contrast, the developers decide who does what, when and how, because the team is self-managing.

This drift is often unintentional. A project manager becomes Scrum Master overnight, without training, and keeps the old reflexes. To tell the two roles apart, read our comparison of Scrum Master vs project manager.

The first step: let the team split the work itself for a whole sprint. Meanwhile, the Scrum Master observes what gets in the way, instead of deciding for the team.

Sign 5: “done” means nothing

The team declares a feature “done” at the end of the sprint. However, nobody has tested or documented it, and it cannot go to production. It comes back two sprints later as a series of fixes.

The Scrum Guide answers this problem with the Definition of Done. It is a formal description of the state of the increment when it meets the required quality. The guide is strict: if an item does not meet it, the team can neither release it nor even present it at the sprint review.

Without this shared definition, the velocity on display misleads everyone. Indeed, the team seems to move fast, while technical debt quietly piles up.

The first step: write a short, verifiable Definition of Done with the team. For example, it can include passing tests, a completed code review and a working deployment to staging.

Sign 6: the retrospective changes nothing

Every two weeks, the team lists what is going well and what is not. The same problems come back sprint after sprint. With no concrete action, the retrospective ends up being cancelled “to save time”.

Yet it is one of the pillars of the framework. The principles behind the Agile Manifesto already say so: at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior. Moreover, the Scrum Guide goes further. The team addresses the most helpful improvements as soon as possible and may even add them to the next Sprint Backlog.

A retrospective with no follow-up sends a clear message to the team: nothing will change. In fact, this is often the moment when motivation drops.

The first step: limit each retrospective to one or two actions, each with an owner. Add them to the next sprint backlog, then open the following retrospective by reviewing them.

Sign 7: velocity is used to apply pressure

Management compares the velocity of several teams and asks each one to “deliver more points”. Soon, estimates inflate and the numbers go up. Yet the value delivered does not change.

In fact, the Scrum Guide does not even mention velocity. It is an internal tool that helps a team forecast its own capacity. Comparing two teams makes no sense, because each one estimates on its own scale. Moreover, the guide reminds us that there are no sub-teams or hierarchies within a Scrum Team.

Here are the most common effects of this numbers-driven pressure:

• inflated estimates to show better results;
• tickets split too finely just to “score points”;
• tests and documentation sacrificed at the end of the sprint;
• a loss of trust between the team and management.

The first step: replace velocity in management dashboards with outcomes. For instance, show the sprint goals reached or the features people actually use.

Diagnosing your team

Few teams show all seven signs. Most show two or three. The table below helps you take stock quickly, with one simple question for each sign.

If most of your answers point to the same role, you know where to start. In most cases, the main lever lies with the Scrum Master or the product owner.

Getting out of fake Scrum without breaking everything

Faced with these findings, it is tempting to stop everything or switch methods. That is rarely the right answer, though. Fake Scrum mostly stems from a lack of shared understanding, not from a flaw in the framework.

Here is a gradual approach that works in most organizations:

• pick a single sign to fix, the one most visible to the team;
• apply the first step for two or three sprints;
• measure the effect in a retrospective, then move to the next sign;
• train the key roles, starting with the Scrum Master and the product owner.

That last point often makes the difference. As Ron Jeffries notes, Scrum usually starts with very few people trained. Many others think they know what they are supposed to do. Shared training, on the other hand, gives everyone the same vocabulary and the same reference points.

Finally, involve management from the start. Genuine Scrum requires managers to delegate decisions, and that cannot happen by decree. You will find all our agile and Scrum courses to support each role.

Conclusion

Fake Scrum shows itself through a constant gap between the rituals and their intent. The daily serves control, the product owner does not decide, the sprint has no direction and “done” guarantees nothing. Each of these signs seems harmless on its own. Together, however, they drain Scrum of its value.

The good news is that each sign has a simple remedy. Start with one, measure the effect, then move on. Above all, train the key roles: a Scrum Master and a product owner who truly understand their mission make all the difference.

FAQ

What is fake Scrum?
It is a team that applies the rituals of Scrum without its principles. The meetings exist, but decisions are made the same way as before.

Can you adapt Scrum to your organization?
Yes, in the detail of practices. However, the Scrum Guide states that implementing only parts of the framework is no longer Scrum.

How long should a daily scrum last?
Fifteen minutes at most, according to the Scrum Guide. It brings the developers together to inspect progress toward the sprint goal.

Should the Scrum Master assign tasks?
No. The team is self-managing: developers decide who does what. The Scrum Master ensures the team’s effectiveness and removes impediments.

Should you compare the velocity of several teams?
No. Each team estimates on its own scale. Velocity only helps a team forecast its own capacity. Comparing teams with each other is, in fact, a classic symptom of fake Scrum.