Scrum is all about creating a Done increment that generates value for its users. However, you might come across teams that do almost everything in the name of Scrum except creating a Done Increment. Spillovers almost every sprint. Sprint Goals not achieved, at times they are not even defined.
Now, some might claim that creating Done is not always possible, and I agree to some extent but then Scrum is also not required to run all kinds of software development. If you are using Scrum, then the intent should be fulfilling the purpose of the framework.
When we do not focus on the purpose and simply get stuck in the mechanics of practices then we end up in a Zombie or Mechanical Scrum environment.
Here are 5 ways to find if you are stuck in the Zombie scrum mode.
1 Sprint Planning is all about assigning tasks
In Scrum, this is an opportunity to build shared understanding of what needs to be achieved by the end of the Sprint. Establishing a clear goal and a plan to achieve it.
Zombie/Mechanical Scrum:
The Sprint Planning is no more an event of shared understanding but a place to assign tasks to individuals. There are predefined work items that are now simply allocated to respective individuals. Sprint Goal sounds like an aggregation of all the tasks to be completed or features to be delivered.The team efficiently breaks down work, but the creative problem-solving and collective ownership are absent. It’s a flowchart, not a conversation.
2. Daily Scrum is a Status Update rant
The purpose of Daily Scrum is to regroup and replan the team’s work for the next 24 hours so that they can achieve the Sprint Goal.
Zombie/Mechanical Scrum:
The purposeful Inspect and Adapt opportunity gets converted to a boring status update rant. The Developers report into a Scrum Master/Product Owner or at times to a Manager outside of the team. Answering three typical question:
- What I was working on yesterday?
- What will I work on today?
- Are there any blockers?
Often, the moment the developers are done with their own status updates they are disengaged from the updates of others. There’s little to no organic collaboration or re-planning. It's a perfunctory ritual, offering no real value.
3. Sprint Review as the demonstration of work done in the Sprint
From the Scrum Guide:
“During the event, the Scrum Team and stakeholders review what was accomplished in the Sprint and what has changed in their environment. Based on this information, attendees collaborate on what to do next. The Product Backlog may also be adjusted to meet new opportunities. The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation.”
Zombie/Mechanical Scrum:
The event is no more a place for collaboration but it gets converted to a mere presentation.
The team members run through the work items completed, often without inquiring or expecting any feedback from the stakeholders. In many teams, stakeholders are not even present. It is just the PO who often uses this event as a phase gate to ‘approve’ or ‘disapprove’ of the work done by the team. It is often without real interaction or valuable feedback loops. It's a one-way presentation, and feedback, if any, is either superficial or comes too late to be genuinely impactful.
4. Sprint Retrospective the pit stop for a blame game
Sprint Retrospective, is yet another Inspect/Adapt opportunity for the Scrum Team to figure out how to become an effective unit.What challenges they faced during the sprint and how to overcome them in future? If there were any conflicts during the sprint, how to address them in upcoming sprints?
And yet this is often reduced to finger pointing and blaming one another.
Zombie/Mechanical Scrum:
In Zombie Scrum, the Sprint Retrospective, a safe place for honest interactions is reduced to a blaming activity. Problems and problems galore while blaming one or the other person for those problems. It is no longer a solution focused event but It often devolves into a complaining session, or superficial "happy path" discussions where no real issues are brought to light. Improvements are vaguely articulated but rarely followed through. It is now just another mandatory meeting (often dreaded) that one needs to attend to get a checkbox ticked and nothing more.
Conclusion:
Just by observing how the events are performed within the team, we can easily establish if Scrum is being used to create value or is being used as a whitewash to check some tickboxes on an Agile Maturity Model so that the team remains compliant to ‘doing Agile’.
If real value is aspired then one needs to start focusing on the principles of Scrum and move away from mere practices.
P.S. If you want to uncover more such ways to determine whether you are using Scrum for right reasons and in the right way, then you are welcome to explore our courses at: https://agilemania.com/scrum-org