Once again, I have the pleasure of welcoming October. Soon it will be cooler and more colorful here in North Carolina. The holidays are coming, and many of my neighbors have already decorated for Halloween. I have been pondering what sort of ghoulish surprise I could cook up this year, and decided to go with one of my favorite creatures… ZOMBIES! Nothing says horror like a good old zombie movie (or TV show), and nothing brings misery to the otherwise happy-go-lucky people that I work with than Zombie Scrum.
“In short, it is about mindset vs mechanics. Zombie Scrum focuses on the process, often without even understanding why, whereas healthy Scrum focuses on an agile mindset while using a process to help deliver high value software to delighted customers.” – John Cavalieri
What is Zombie Scrum? It is going through the motions of doing agile, without being agile. It strips out the Heart of Agile as described by Manifesto signer Alistair Cockburn, which simplifies the focus of agile to “Collaborate, Deliver, Reflect, and Improve.” As a framework, Scrum can lead teams to robustly practicing agility, but when misused (or misunderstood?) Scrum can lead to braindead practices where there is no teamwork, little value is delivered, retrospectives are ineffective, and little to no improvement. Do you need examples?
One classic symptom of Zombie Scrum can be gleaned during Daily Scrum (or Standup, if you prefer). Scrum beginners are taught (from the Scrum Guide) to conduct the meeting by answering three questions:
If you actually read the Guide, it proposes that the team conduct the meeting in such a way as to emphasize daily movement toward the Sprint Goal, and that the questions are just an example. Living, vibrant teams use the time to build a daily plan toward finishing the most valuable part of the Sprint Goal. That plan is not a time that work is divided and everyone goes back into hiding until the next Daily Scrum, but a chance for the team to swarm around the work and figure out how to most effectively accomplish it. The details aren’t discussed until after the session (by the appropriate team members that will be working together), but an overall plan is hatched out. Leaving planning to a bi-weekly meeting (Sprint Planning) is not only a recipe for disaster (we need to embrace change), but it gives everyone a dead to-do list that each person provides status on every day, rather than a living attack strategy we are working on together toward a viable Goal.
The lack of a Sprint Goal is another sign of Zombie Scrum. Teams often lack understanding and/or passion around what is the next valuable Increment that needs to be accomplished, which shows a dysfunction in Sprint Planning. By the time Sprint Planning occurs, the Team should have been exposed to the items at the top of the Product Backlog via refinement discussions. Though the Sprint Guide doesn’t call out Backlog Refinement as one of the five Events that make up Scrum, it does state that the Product Owner and Development Team “usually” spends up to 10% of the Teams capacity collaborating on the details that make up Product Backlog Items. Based on the knowledge the Scrum Team has about the Product Backlog, the objective the Product Owner would like to achieve, and the discussion the Team has around which valuable Increment can be delivered in the next Sprint, a Sprint Goal should be identified.
Have you ever noticed (in movies) how zombies tend to aimlessly wander around, perhaps even coming to a standstill, until there is some sort of noise that startles them awake and hungrily into action? Sprints without Sprint Goals are like that. Teams need to be chasing after a clear objective or they will grind to a halt, distracted to rush after the squeakiest wheel rather than consistently delivering value and delighting customers.
Zombie Scrum also makes itself known in the Sprint Review and the Sprint Retrospective. The three pillars of Scrum are Transparency, Inspection, and Adaptation. While these pillars should be apparent throughout the Sprint (as part of a healthy Daily Scrum), there are no events that are more geared toward them than the Review and the Retrospective. The Sprint Review is an opportunity for stakeholders to inspect the Increment and, based on their feedback, adapt the Product Backlog to optimize value. It is an external review of how the Team is doing, including discussions about the Increment (with a demonstration), what went well and what didn’t go so well (and what the Team did about it), and a conversation about what is the most valuable thing the Team should work on next. If there are no stakeholders present, they have probably been eaten by zombies (just kidding, but sometimes the infection comes from the organization, sometimes from the Team). If the Increment doesn’t work on a regular basis, or is not often demonstrable, you need to do some internal review.
The Sprint Retrospective is a time for the Scrum Team to conduct an internal review and create an improvement plan. If your team is too busy to meet, the meeting regularly devolves into a complaint session, or the issues that are identified are beyond the reach of the Team to address, there may be a rampant zombie infection. The Team needs to focus on improvements that are within their circle of influence (and especially directed toward delivering working software every Sprint). The wicked problems can be identified and passed on to leadership to address.
So, what do you do if you suspect you have a problem? Don’t settle for mediocrity. Most ScrumMasters took a two-day certification course, which in effect gives them a learner’s permit to practice. They need to engage with other agilists via meetups or conferences. Now is a great time to hear some amazing speakers for little to no money because COVID-19 has created a thriving virtual world of opportunities.
Another option is to invest in external coaching. It is very common for internal coaches and ScrumMasters to conspire with the teams they work with as time goes on. Rather than “fighting the good fight” alone, they start to settle for the status quo. External coaches can help disrupt that behavior and show teams where they are falling into routines.
In short, it is about mindset vs mechanics. Zombie Scrum focuses on the process, often without even understanding why, whereas healthy Scrum focuses on an agile mindset while using a process to help deliver high value software to delighted customers.
Giving credit where it is due, The Rise of Zombie Scrum: Symptoms, causes and what you can do about it was written in early 2017 by Christiaan Verwijs, with input from Johannes Schartau and Barry Overeem. They were first to write significant content on Zombie Scrum, (including currently writing a book about it, hopefully to be released early 2021). I am afraid that Zombie Scrum did not stay in Germany and the Netherlands (where these gentlemen reside), but it is running rampant here in North America as well.
Stay healthy!
Esse quam videri,
John
Up next: