The Liberators
Published in

The Liberators

Introducing the Zombie Scrum Symptom Checker

And join our worldwide research into how teams work with Scrum, and what works for them

Is your team suffering from Zombie Scrum? And if so, what can you do to improve? Do you wonder how other teams work with Scrum? How many members they have? What the usual length of a Sprint is? Is Scrum really helping teams deliver value to stakeholders faster and making them happier as a result? Find out with the first version of the free Zombie Scrum Symptoms Checker

Example of a team profile generated by the checker (extensive feedback is below the fold)

With the first version of our free Zombie Scrum Symptoms Checker, you can now diagnose your Scrum Team. After completing a survey, you receive a profile for your team that helps you identify where you can improve. Or what you can do to recover from Zombie Scrum. When you use our site, you also help us better answer the earlier questions based on actual data. This site is an initiative by myself, Johannes Schartau and Barry Overeem and ties in with the book we’re publishing through Addison-Wesley in Q2, 2020.

In this post, I tell you more about the ‘Why’ of this checker.

The mission of our app

“Our mission with this app is to use an empirical approach to better understand how teams and organizations work with Scrum, what it makes possible for them, what enables or impedes their success and how to better support them.“

Based on a scientific approach

Scrum is grounded in empiricism. But ironically, there is little empirical research into what works and what doesn’t. The research that exists is often executed by people without extensive knowledge of Scrum. Or research remains descriptive — like VersionOne’s State of Agile Survey. Although there is nothing wrong with such research, we feel responsible for making a bigger effort to understand how teams work with Scrum and what makes them successful (or blocks them).

We are eager to use an approach that is grounded in behavioral science, with an instrument that has proven validity and reliability, and can be replicated by other researchers. Instead of purely describing what happens in the field, we want to start testing hypotheses like:

  1. Scrum Teams that use Sprint Goals experience higher levels of self-organization than teams that don’t;
  2. Scrum Teams that use Sprint Goals are better able to deliver working software every Sprint than teams that don’t;
  3. Scrum Teams that deliver working software every Sprint are experiencing less stress, higher morale and have happier stakeholders than teams that don’t;

In other words, we want to put the common wisdom of Scrum Masters, Product Owners, developers and people working with Scrum to the test. This helps us move from opinions to facts, and paves the way for a bright future for teams and organizations who want to work empirically with Scrum.

Real science, with Johannes Schartau and myself

Developing a survey that asks the right questions and measures the right things is challenging. Wherever possible, we’ve relied on existing measures that have been validated in scientific studies. Examples of this are metrics related to team morale, team composition, team learning, and psychological safety. For other topics — like ‘inclusion of customer’s voice’ or ‘celebrating success’ — no useful measures exist. So we relied on input from experts in the field to develop initial versions. We will use the data gathered by our checker to determine their psychometric reliability and validity, and adjust accordingly. We will publish these results publicly.

Example of the survey (release 1.0.43).

Receive your team’s profile

Because entering a long survey isn’t a very appealing prospect on its own, we wanted to make it worth your while by providing you with comprehensive feedback based on your results.

So, after completing the survey for a team you receive a profile that plots your team across four dimensions: ‘Ship It Fast’, ‘Building What The Customer Needs’, ‘Self-Organization’ and ‘Continuous Improvement’. You can compare the scores of your team against the average of all teams. In the near future, you can compare against teams in your region, sector or organisational size.

In addition to dimensional scores, your team also earns badges for exceptional scores (e.g. your team is in the highest 10% of teams in terms of automation). As we learn more by gathering data from teams all over the world, we will continuously refine and improve these scores.

Examples of detailed feedback provided to a team based on their responses.

Optional: How our survey is constructed

Reader Tip: feel free to skip this bit if you don’t care about survey construction. It's here mostly to be transparent about our approach.

Our survey consists of a number of constructs, like ‘Involving The Customer’ and ‘Psychological Safety’. Each construct is measured with a scale of multiple questions that tap into objective aspects of each construct. For example, for ‘Involving The Customer’ one question is ‘The Product Owner actively involves stakeholders in ordering or updating the Product Backlog’.

Each construct ‘loads’ on higher-order constructs called ‘factors’, like ‘Shipping Fast’ or ‘Building What The Customer Needs’. Approaching a survey like this allows us to calculate scores for individual constructs and aggregate them into their respective factors. For example, ‘Product Vision’, ‘Including The Customer’ and ‘Managing The Product Backlog’ are currently the three factors we assume load strongest on ‘Building What The Customer Needs’. Once we have sufficient data, we can start verifying these assumptions using statistical techniques. This allows us not only to verify if our model holds up, but it also allows us to determine the validity of the scales. We will report these findings when we have them.

An example of a model based on questions that feed into constructs that feed into higher-order factors

With statistical analyses like structural equation modeling (SEM), we can explore how constructs are related. For example, we may discover that as the size of a team grows, their cycle time drops. Or we may discover that having a strong product vision goes hand-in-hand with higher stakeholder happiness.

“For example, we may discover that as the size of a team grows, their cycle time drops. Or we may discover that having a strong product vision goes hand-in-hand with higher stakeholder happiness.”

It should be noted that we can never conclusively prove the direction of effects without experiments. We won’t be able to conclude that smaller teams result in lower cycle times. To prove that, we would need to run an experiment where we compare teams of different sizes — but similar in all other respects— against each other and measure their cycle times. But even though we can never conclusively prove causality without experiments, we do hope that showing strong correlations gives direction for further research and interventions.

“ But even though we can never conclusively prove causality without experiments, we do hope that showing strong correlations gives direction for further research and interventions.”

Open-source data and replication

Proper science is based on replication. One study can never prove anything conclusively until independent studies confirm the result. In order to encourage replication, we will do the following:

  • We will share the survey, its questions, and factors as well as the psychometric properties of the scales we develop (and improve);
  • We will share our anonymized dataset (with email addresses, names, and locations removed) with academic researchers who are serious about replication or further exploration and support them where needed;
  • Periodically, we will publish results from our dataset up to that point or aspects we pick out;
  • When time permits, we aim to publish our findings in peer-reviewed scientific journals. Or support other researchers in doing this with our data;
Field studies will certainly follow

Next steps for our research

For us, gathering data with the survey is just the first stage. Working together with researchers, we are hoping to explore:

  • The current survey is entered by one person for a team. We want to add the option to ask members of the team to fill in the survey, and then use the average scores;
  • We would love to interview teams that score very high on working effectively with Scrum, to see what we can learn from them (and share with you). The same goes for teams that struggle massively with Scrum;
  • We want to perform follow-up research by offering suggestions for techniques that might benefit teams with certain scoring profiles. We then want to measure how effective those techniques turned out to be according to the team, so we can build empirical grounding for what works (and what doesn’t);
  • We want to identify the biggest risk factors that impede (or promote) effective Scrum or cause Zombie Scrum;
  • We want to augment the measures of value from our survey with more objective, factual measures (like money saved or generated) — perhaps through interviews;

The Product Backlog for our app is publicly accessible here.

Give it a try!

We can only encourage you to give the app a try. It may only be a minimum viable product, but we are eager to add more features as data starts coming in. Go to to try it for your team(s). And we’d love to hear your feedback, suggestions, bugs, and questions in the comments (or in our mailbox at

Order your book directly from us for some nice extras.



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store