How to Tell if a Team is Running Fake Scrum?

Many of my students attending my Professional Scrum Master (PSM) training express concerns that their teams might be doing "Fake Scrum." Here are some common tells:

No Working Software 

True to the Scrum, the goal is to deliver at least one increment per sprint. This isn't about showcasing a demo or running code on a developer's machine; the aim is for the increment to be as close to a production environment as possible, ideally deployed in production. While achieving this may be challenging in the initial sprints or the first two years, progress towards this goal should be made in every sprint. A practical first step may be to discuss the gap during the Sprint Retrospective, start from the reality, measure the gap to the ideal situation, and update the Definition of Done to narrow the gap. If any skills are needed to improve, it's crucial to seek assistance.

Unchanged Product Backlog

I've heard horrible stories that a team in the bank had the Product Backlog "ready" ahead for a year and never changed it. This stagnation contradicts the very essence of Scrum. A static Product Backlog might suggest insufficient stakeholder engagement or their feedback was ignored. Think again about the last time you updated your product backlog, and whether any items stayed there for an extended period. I am also guilty as a Product Owner that I have some items left there for years.

Silent Developers

If developers are dead silent during Sprint Planning, Review, and Retrospectives, it is a significant concern. This silence often indicates a lack of collaboration and input from the development team. While facilitation techniques can aid in improving participation, the underlying issue often relates to psychological safety within the team. It's crucial for everyone to feel secure in voicing their thoughts, and for the team to take constructive action based on these discussions. Ultimately, the Scrum Master is accountable for helping the team build trust and have actionable insights during Retro.

If you find yourself part of a 'Zombie Scrum Team' that's merely going through the motions, don't feel bad. I have also been there. You're not alone, nor are you in the worst possible situation. A good starting point for improvement is to introduce or enhance the practice of discussing potential improvements during the Sprint Retrospective. If your team isn't currently conducting Sprint Retrospectives, maybe upholding Scrum to do it would be a good first step.