What is Zombie Scrum?
We first heard of Zombie Scrum through ‘The Liberators. It refers to teams following the events and practices described in the Scrum Guide without understanding the values and the intent behind these practices. The Liberators define this as – “Mindless, drooling herds of developers, testers, designers and others moaning ‘chaaaange’ and shambling around the building to all sorts of brainless Scrum-activities.”
Why does Zombie Scrum Take Hold?
Zombie Scrum can take hold for various reasons. In some cases, Scrum is imposed from above without being questioned. Many organizations have strong hierarchies, and we often see ‘Top-Down’ implementations in these environments. In other instances, tooling like Jira is imposed with many rules, but these tools become too heavy and disconnected from the actual needs of the teams. The larger issue with both of these situations is that teams did not buy into the change: rather, the change was imposed upon them. Teams can end up feeling like if they ‘just do the Scrum, higher-ups will be happy.’ (Enter Zombie moan: “Chaaaaaange”)
The absence of true product ownership is another key cause, leading to issues such as trouble prioritizing items, long delivery times, lack of innovation, and lack of ownership on behalf of the teams. In this context, “absence of true product ownership” means that Product Owners are unable to live up to the intended role function as described in the Scrum Guide. Instead, Product Ownership becomes a powerless position that acts on others’ decisions and represents a link in a long hierarchical decision-making chain. In this way, the presence of extra roles from legacy organizational structures can also contribute to the development of Zombie Scrum.
Furthermore, the lack of ownership can translate into responsibility shielding. Teams become dependent on others to avoid taking responsibility, sticking to their familiar surroundings and roles. They may defer responsibility for failures or problems to other teams or individuals, going against the idea of cross-functional teams that have all the necessary competencies to complete the work without depending on others. This reflects the existing functional silos in the organization, leading to many steps and hand-offs between what the team delivers and what eventually reaches real users. As a result, teams learn very little and very late about the real-world effects of their work.
In essence, Zombie Scrum results from a systemic mismatch with Agile values, where beliefs about solution development within the organization collide with what drives Agile software development.
What are Our Options?
Retrain the team in Scrum
What we are lacking in the ‘Zombie Scrum’ situations is an understanding of Scrum. A focus on the mechanics of Scrum is often what leads to the Zombie infestation. Retraining with a focus on Scrum Values and Growth Mindset is necessary to be successful with Scrum. Laying a greater emphasis on ongoing learning and the professional approach to trying to get better every day. Revisiting Scrum with elements of the Agile Manifesto in mind and aligning the implementation better with Agile values as opposed to the mechanical ticking of boxes in Zombie Scrum.
This can, though, be seen as trying the same thing again and expecting different results. For folks already in this environment, Zombie Scrum and “renewed” Scrum might look exactly the same. These teams have already been encouraged to focus on the rules and as the rules are not changing, they might not change their mindset or act any differently.
Switch to Kanban
Often a path suggested for teams struggling with Scrum or falling into the Zombie Scrum track is a complete switch over to Kanban. This could be an effective option, but could also become a case of simply replacing Zombie Scrum with Zombie Kanban. Worse, it could be replacing bad Scrum with something that just pretends to be Kanban.
When working with teams that organize themselves around a single product and claim to be applying Kanban, when we probe into the ‘Why’, we get responses along the lines of
- Scrum is too radical
- Timeboxed Sprint of one month or less is too short
- Scrum has too many time-consuming events
Give or take a few Sprints of producing little to no valuable work and sitting through soulless Scrum events, these teams naturally made the decision to convert from Zombie Scrum to Zombie Kanban. For a start, they stopped looking incompetent for being unable to deliver a Done Increment in 30 days or less and have broken out of the vicious cycle of ineffective Scrum events, or have they?
Add Kanban and Flow to Scrum
Flow and Kanban are concepts that are completely complementary to Scrum. Kanban has some very simple practices that renew the focus on getting value to customers. Each item that the team is working on, becomes a focal point for the team to manage. Using Flow Metrics like Cycle Time and Work Item Age, the team can not just measure, but adjust the effectiveness of their approach. Flow Metrics and Kanban can help the teams understand and evaluate their systems. They can help improve how value gets delivered to customers without having to stop reaping the benefits of Scrum.
The best part of this approach is that it does not require the team to step away from Scrum. Adding Kanban practices gives the team a renewed focus on the flow of value. At the same time, it does not upend their world by asking them to abandon Scrum. It is a smaller change, hence it is more palatable. At the same time, the change is substantial enough to make the team look at their process with fresh eyes and push towards a better flow of customer value.
Why Kanban as a Cure?
The most important part of Kanban is to optimize the flow of value through a process that uses a pull-based system. Kanban can force teams to acknowledge the problems that have been plaguing their Scrum practice. For example –
- Operating without a definition of workflow
- Absence of controlling work-in-progress
- Work items not being actively managed and aging unnecessarily
- Unpredictable workflows with long cycle times
Assume that we are able to help these teams to instill a pull system. We don’t have to replace Scrum, simply add Kanban practices. Use Flow Metrics and visualizations to get the team engaged in actively managing their work on a daily basis. Would that help to reinforce the pull nature of the Sprint Backlog artifact in Scrum?
Flow metrics can help cut through the noise without overtly competing with or de-throning whatever is in place today. They can be used in parallel with whatever metrics we are using today and help start the conversation of – ‘Are we spending too much time collecting information that is much more easily available?”.
In Kanban (according to the Kanban guide) the four mandatory flow measures to track are:
- WIP: The number of work items started but not finished.
- Throughput: The number of work items finished per unit of time. Note the measurement of throughput is the exact count of work items.
- Work Item Age: The amount of elapsed time between when a work item started and the current time.
- Cycle Time: The amount of elapsed time between when a work item started and when a work item finished.
These simple measures can be used by any Scrum team. Paying attention to these and looking to improve them requires the team members to be actively involved in the process. They can no longer act like Zombies. They have to figure out creative ways to help bring Cycle Times down or Throughput up if that is the need of the hour.
Is the ‘Cure’ guaranteed to work?
No, because humans
No, the ‘cure’ is not guaranteed to work because it requires human change and adaptation. Kanban is going to bring a new lens to look through. The focus on ‘the flow of value’ to customers is very likely to help see problems in a new light. The new perspective and focus help the team step out of the malaise that Zombie Scrum has created. All of this is nullified if the humans involved are not able to change their viewpoint. If the Agile practice is treated as a ceremony and rote repetition of things written in guides, there is no cure for Zombie Scrum (or Zombie Kanban). Kanban as a cure is very very likely, but not guaranteed to work, because humans.
What increases the likelihood that the Cure will work?
Not making it a “versus” conversation
Do not make it a “Scrum vs. Kanban” conversation. Instead, open new conversations by showing new data. Our focus should be on establishing a better understanding of Scrum and complementary Kanban Practices with Flow metrics to create a balance of effectiveness, efficiency, and predictability.
Not repeating the mistakes
Don’t repeat the same mistakes you made when “introducing“ Zombie Scrum. No training, not having experts at hand, imposing it from above, and leaving people alone without any support can foster a cargo cult. Don’t go from Zombie Scrum to Zombie Kanban.
Using the Kanban board effectively is crucial. If the board is only updated once a day during the Daily Scrum and only used to give a status report, you’re in the realm of Zombie Kanban. The board should be a living tool that helps to visualize and continuously improve the workflow.
Focusing on finishing
Kanban puts a premium on flow. It encourages teams to look at every work item with the objective of getting that item to done as efficiently as possible. Kanban recommends the use of Work item Age as a key metric for this. Comparing the age of your current work to how long it has taken you to get work done in the past is an easy way to ensure this flow.
Using Work Item Age
- Will make your Daily Scrums more effective
- Will make it possible to forecast
- Will allow you to take action (raise impediments, deliver news) early
Summary
Kanban can be a great addition to Scrum. It can help the teams focus on efficiency, effectiveness, and predictability of the work they are doing. These are not competing frameworks, but compatible ways of working. If your team is stuck in a rut with Zombie Scrum, try adding Kanban. Learn more here.