What systemic impediments cause 'Zombie Scrum' in an organization?

WHAT THIS TESTS: Your ability to think systemically. The interviewer wants to see if you can look past team-level symptoms (like poor stand-ups or missed story points) and identify the root organizational structures that create 'Zombie Scrum.' It tests your senior-level perspective: can you connect engineering practices to business value and diagnose problems at the enterprise level, not just within your own team's bubble?

A GOOD ANSWER COVERS: A structured investigation into four key areas of organizational dysfunction. First, the relationship with value and stakeholders: are teams building for real users or just for a proxy product owner who isn't empowered? Second, team autonomy: do teams have control over their process, tools, and architecture, or is everything mandated from above? Third, the definition of 'done': is the goal to ship working software frequently (e.g., every 1-2 sprints) or just to close tickets? Fourth, continuous improvement: is there genuine time and psychological safety for retrospectives that lead to real change, or is it just a ceremony?

COMMON WRONG ANSWERS: A major red flag is focusing only on team-level solutions. For example, suggesting 'better backlog grooming,' 'stricter stand-ups,' or 'enforcing story points.' These are symptoms, not causes. Another wrong answer is blaming the engineers for being 'lazy' or 'not motivated.' This shows a lack of senior perspective and an inability to see how the system influences behavior. A junior answer diagnoses the team; a senior answer diagnoses the organization that created the team.

LIKELY FOLLOW-UPS: 'Okay, you've identified that teams have no autonomy. What's the first small, concrete experiment you would propose to start changing that?' or 'You mentioned a disconnect from stakeholders. As an engineer, how would you find the 'real' stakeholders and involve them?' or 'How would you measure if any of your proposed changes are actually working?'

ONE CONCRETE EXAMPLE: 'In a previous role, we saw sprint goals being missed by 50% sprint-over-sprint. It looked like an estimation problem. But digging in, we found the 'impediment' was the central architecture review board, which had a 3-week SLA. Teams couldn't get feedback in a 2-week sprint. The systemic issue wasn't the team; it was a governance model incompatible with agile timelines. We proposed embedding an architect with the teams for a quarter, which solved the bottleneck and proved the value of decentralized decision-making.'