Scrum for the Real World: Surviving the 'Scrum Zombie'

In 2018, I landed in a world that called itself “agile.” I had never worked with user stories or incremental deliveries, and everything was new to me. Today, after years immersed in a supposed “agile transformation,” I ask myself a question that many whisper in the hallways: are we truly more agile than before, or have we just perfected the art of filling out forms?

I remember those early days. Our Scrum was manual, almost artisanal. User stories were written jointly with the Product Owner, we broke them down into tasks, and we got to work. It had its flaws, of course. Our flow was an internal mini-waterfall: Development -> QA Testing -> PO Approval. It was imperfect, sometimes chaotic, but it was human. There was a direct connection and a clear goal: to deliver.

Fast forward to today. We have sophisticated tools, formalized processes, and an agile vocabulary that everyone recites from memory. But that genuine agility feels further away than ever. We’ve adopted the rituals of Scrum, but we’ve lost its spirit. We are living in the era of the “Scrum Zombie”: we go through the motions, but there’s no life.

These are the pain points I believe many will recognize.

Pain Point #1: The Pre-Sprint Gauntlet: Agility by Committee

Before we can write a single line of code, every sprint must survive a bureaucratic maze I call the “sprint before the sprint.”

• The Justification Kickoff: A meeting where the PO must “sell” the sprint’s value, justifying the investment, calculating ROI, and savings in manual hours. It feels less like the start of an iterative cycle and more like a defense for an annual budget.
• The Costing and Planning Review: A detailed analysis of costs and timelines that reeks of the waterfall project management we were supposed to leave behind.
• The PMO’s Blessing: Finally, a stamp of approval from the Project Management Office that adds another layer of waiting and bureaucracy.

The Diagnosis: This isn’t agility. It’s the traditional project management mindset using Scrum terminology. It prioritizes control and prediction over adaptation and rapid value delivery, which are the heart of agility.

Pain Point #2: The Daily That Became a Status Meeting (While Seated, of Course)

I remember when dailies were 15-minute meetings, standing up, with a single purpose: what blockers do we have, and how can we help each other overcome them?

Today’s Reality: Those meetings have morphed into 30-to-45-minute sessions. The team no longer collaborates to solve problems; each member reports their status to management. The focus is no longer “how do we move forward together?” but rather “did you justify the hours you were assigned yesterday?”.

The Diagnosis: This is a symptom of a lack of trust. When the daily becomes a status report, the team’s self-organization dies. The Scrum Master (or whoever leads the meeting) has shifted from a facilitator who removes impediments to a foreman who oversees progress.

Pain Point #3: The Sprint as a Two-Week Mini-Waterfall

This is a problem that has persisted over the years. Although the tools have changed, the underlying workflow remains the same.

The Reality: Work flows in one direction: all development is completed, then everything moves to QA, and finally, everything is delivered to the PO for approval. A story doesn’t move forward until all its tasks are done, and the sprint doesn’t end until all stories are approved.

The Diagnosis: This creates massive bottlenecks and delays crucial feedback. True agility aims for a cross-functional team (developers, QA, etc.) to work on a single story until it is completely done (meeting a robust “Definition of Done”) before starting the next one. Our model is simply a waterfall with a two-week time limit.

Conclusion: Small Acts of Rebellion to Revive the ‘Scrum Zombie’

We can’t change the entire organization overnight, but we can start reclaiming the agile spirit with small, pragmatic actions.

1. Reclaim the Daily Stand-up. The first step is the simplest: go back to 15 minutes. Standing up. With a single goal: identify impediments. Anything else is discussed after the meeting, and only with the necessary people.
2. Advocate for a Real “Definition of Done.” Let’s propose in the retrospective that a story is “done” when it is developed AND tested by QA, not just when the developer finishes their part. This forces collaboration, breaks down silos, and focuses us on delivering functional value increments.
3. Question Bureaucracy with Data. Instead of complaining, let’s use the retrospective to measure the time lost. “How many days did we wait for PMO approval this sprint?”. Presenting that data isn’t a complaint; it’s an opportunity for improvement for the entire organization.

A successful sprint isn’t one that checks all the ritual boxes, but one that delivers real value to the user and, in the process, teaches us how to be a slightly better team next time.

Do you experience a similar reality in your team? What other “Scrum Zombie” symptoms have you seen? I’d love to read your experiences in the comments.