Zombie & Orc Scrum Teams

If you work in the software development industry, you most probably work within Agile teams, or have at least done so at some point.

But are you 100% certain that your team is doing Agile the right way? There may be a chance that you belong to a Zombie or Orc Scrum team, and that you’re not even aware of that fact!

Last October, our very own Darío Macchi gave a talk on this topic at the local JIS conference in Montevideo. Darío’s talk “Zombie & Orc Scrum Teams” focuses, through humor, on the difference between win-win and lose-lose Scrum teams for clients and developers.

In his presentation, Darío breaks down the definitions, symptoms and potential cures for each of these two epidemics affecting the software community.

Ready to discover whether you’re in the clear or if you should be worried? Read on to get your diagnosis :)

Introduction to Zombie & Orc Scrum teams

The concept of “Zombie Scrum” has been around for a while. From the outside, they seem to be normal Scrum teams, but they lack the beating heart of potentially releasable increments at the end of each sprint. Also, these teams have no intention to improve their situation and their stakeholders have forgotten about their existence a long time ago.

An Orc Scrum Team is a new kind of team that I have been trying to define for a while now.

Beings of greater (evilish) power (managers) build Orc Scrum Teams to be in fashion, but they lead them as cannon fodder in battles that, much like zombies, can only be won because of the elevated number of them. Old, rigid organizations are survivors, so Scrum didn’t change them as everyone supposed would happen; old, rigid organizations changed Scrum.

First part - Scrum

We will define some terms to better understand the background of this article and later discuss the relation between them.

Scrum definition

The Scrum framework is a series of team behaviors that are based on values to achieve an objective. The Scrum attitude is the internal and personal experience that each one makes of the values. You can implement the Scrum framework without having a Scrum attitude; you can have a Scrum attitude and not implement the Scrum framework and you can implement the framework with the attitude.

Without the Scrum attitude, Scrum practices are mere unfounded behaviors; it's like when children take a round plate and use it as a steering wheel: they execute the movements but don't achieve the goal.

If your objective is to implement the Scrum methodology, you are already getting off to a bad start.

Scrum provides a platform for people to work together effectively, while at the same time making it possible to relentlessly expose any problems that may arise and get in the way.

Second part - Zombies

I have a couple of questions for you.

How many have experience working with Scrum? Ok… We have many raised hands!!!

Now: How many of you have done retrospectives in your Scrum teams where the team is challenged with creative activities, that pursue specific goals, make the team think bigger and about their future, analyze risks or just think about how they feel working together?

Now, how many of you have done or currently do the Good / Bad / Change retrospective, sprint after sprint?

If you are in the first group of lucky people, you want to stay on the good track and avoid becoming a Zombie Scrum Team. As for the second group, well… YOU WON’T EAT MY BRAIN!

Zombie definition

A zombie, in its broadest sense, was once alive but has lost his sense of self-consciousness and identity, and only cares about the destruction of others around him, regardless of the circumstances, or the cost to himself. They compensate for this lack of intelligence in numbers, since the state of "zombieism" is almost always contagious, and spreads virulently, at a devastating cost to the society around them.

Zombie Scrum Team

The concept of “Zombie Scrum” has been around for a while. From the outside, they seem to be normal Scrum teams, but they lack the beating heart of potentially releasable increments at the end of each sprint. Also, these teams have no intention to improve their situation and their stakeholders have forgotten about their existence a long time ago.

For me, the definition is even worse because it is broader. For me, besides what has been said, a Zombie Scrum team has lost its soul. What do I mean by this? Well, I’ll show you with examples (RAAAAUUUUGHHHH in zombie language).

RAAAAUUUUGHHHH #1

“Complete functionality is a nice-to-have, but if it is not in this sprint, we can end it in the next one, because.. we’re not going live at the end of a sprint anyways.”

They have no sense of urgency, mostly because they don’t have clear goals or there’s no real understanding of value.

RAAAAUUUUGHHHH #2

“Hey, I don’t care if the product as a whole meets customer expectations… I’M HERE TO CODE!”

Again, they don’t understand what value means in Agile. Delivering value has always been the priority of Agile teams, and excellent code but a poor product has no value to end users.

RAAAAUUUUGHHHH #3

“Ok… last sprint we did all the sprint backlog, not a big deal… this sprint was ended with items being carried over to the next sprint… not a big deal either… there’s always a next Sprint and... iterations are artificial anyway!”

There is usually an underlying cause behind this RAAAAUUUUGHHHH and that is the “Scrum cherry picking”. It consists of deliberately partial adoption of Scrum. E.g. Extending sprint durations to ensure “done” sprints, cancelling sprint reviews because there is nothing to show, or cancelling the retrospective due to lack of time.

RAAAAUUUUGHHHH #4 (the worst)

"Seriously... Do we need that stupid retrospective meeting again? Whatever… I'm very bored here, so I will continue as is on another place.... Who cares? At least the SM came today… pfff… as if he made any difference”.

What is going on with this guy? Obviously he didn’t understand anything about Agilism and Scrum. Retrospectives are the most important ceremony of Scrum. Also, what is a bored dev doing in an Agile team? And why doesn't he say that in retrospectives?

Teams showing these RAAAAUUUUGHHHHs are not Agile. They don’t value working software, response to change, customer collaboration nor individuals and interactions (you remember the Agile manifesto, right?). Some of you may be asking yourselves “But wait, they are Scrum teams, why are they not Agile?”. Remember that Scrum is a framework with a weak opinion on how software should be developed, allowing anti-Agile methods to be incorporated and cloaked in Agile terminology.

Treatments

Zombieism in Scrum teams is curable following one or many of these pieces of advice:

• Speak with the team: many times just talking about some of these RAAAAUUUUGHHHHs with the team is enough to get them to react.
• Benefit from the community: there are many people fighting against zombie Scrum teams (e.g. the Zombie Scrum Resistance). They have several activities, retrospectives and tools proven to work with zombie teams.
• Stir the waters: this is my preferred method; I like to shake the team to make it react. I prefer the use of specific retrospectives to make them analyze their current situation (e.g. smell-o-meter) and dream about the future.
• You can also try changing the length of sprints and start daily meetings reviewing the sprint goal.

Third part - Orcs

As we did with zombies, I have a couple of questions for you.

How many of you go to retrospectives with your laptops? How many of you have done daily meetings using Slack or similar? How many of you have daily meetings where you report yourselves to a PM/SM who also happens to be your boss? How many of you do Scrum and have a PM that assigns tasks to each team member on planning meetings? Or worse, how many of you have a PM that does the planning based on his expert judgment and then assigns the tasks to each team member?

Ok, ok… One at a time please!

Orc definition

They are of human shape, of varying size, ugly and filthy… But once, some were beautiful creatures. Although they have their own culture of low cleverness and crudity, they are generally portrayed as a subject race used as soldiers (or cannon fodder) by beings of greater (evilish) power and intelligence. There are exceptions, as orcs sometimes have cunning leaders of their own kind. They will fight fiercely if forced or directed by a guided will, but tend to more chaotic behavior (including cowardice) if left to their own.

Orc Scrum Team

An Orc Scrum Team is a new kind of team that I’ve been trying to define for a while now.

Some authors say that “Scrum is the new waterfall”, but I prefer to say that “Scrum is the new black”! (More about orcs in a moment, be patient please). “X is the new black” is a phrase that has its origin in the fashion world, and that’s exactly why I use this phrase. There are managers who are merely trying to show how modern and trendy their software development teams are, pushed by a market that believes everything should be Agile. They are trying to be à la mode, being Agile but also keeping the power that they have inside those (commonly) pyramidal structures.

Zzzz… Hey! Wake up, this is the orcs part! The managers we talked about in the previous paragraph are those beings of greater (evilish) power from our orcs definition! They build Orc Scrum Teams to be in fashion, but they lead them as cannon fodder in battles that, much like zombies, can only be won because of the elevated number of them. Old, rigid organizations are survivors, so Scrum didn’t change them as everyone supposed would happen; old, rigid organizations changed Scrum.

What these managers (and many times, organizations) don’t understand is that Scrum is not a software development method at all. Think about the original Ken Schwaber’s book, named Agile Software Development with Scrum. Its title says that Scrum is an addition to Agile, not a substitute for it. And review the case studies on that book too. You will see that the authors, as experienced Agile professionals, were leading the effort, and the agility of the software development method was achieved through some variant of Agile, typically Extreme Programming.

Let’s now look at some Orc examples (HRROOGA in Orc language).

HRROOGA #1

[Manager] - “Ok, so I will be the Product Owner, you (mid-level manager) will be the Scrum Manager . We will work in two week iterations, having a planning meeting on the first Monday, dailies each morning, and every second friday the team will show me what they have done and then we will do a brief retrospective. Ahhhh, now we are Agile!”

This doesn't admit the slightest analysis.

HRROOGA #2

“We have been defining the new Agile process for the last two months… but now I think that we can finally apply it to all the teams in the company” (those teams range between 2 to 50 people).

How do you spend 2 months maturing An agile process in a theoretical way? Put all those people to work instead, and after 2 months you will have a process adjusted to each team that will be generating value on its own.

HRROOGA #3

“Ok guys, we need to do Agile. We need to find something to take away our pain. Any ideas?” and someone trembling in the background says “Scrum?”. A couple of weeks later they end with cosmetic “fixes” that let them continue doing things the same way they've always done them, but with cool Agile names!

HRROOGA #4

[Scrum Master/Product Owner in retrospective meeting] - “We hired you [team] to be smart and figure things out. You’re supposed to self-organize to solve problems. You’re already falling behind on features. We need features, not tests! Build what we want!”

This is all wrong. But the worst thing is that without tests you can't ensure that you deliver full functionality and it's impossible to add value every sprint (because eventually you'll break something that worked).

Treatments

We're so sorry. There is no known treatment. We can advise you on ways to incorporate changes in your work in order to improve conditions and maybe try to resemble the elf you once were. But surely, the scars will remain forever. You can:

• Connect your teams to customers and business-value generation directly.
• Focus on products, not projects.
• Improve technically and add Agile software development practices (maybe you can start from Extreme Programming).
• Follow Ron Jeffries advice:

• Work on one or two of the items, complete those entirely — fully packaged, tested, and working — and then do another, so that at the end of the boxcar you have something that you can absolutely call “completed”.
• Take the inevitable abuse for not completing everything,
• And try to drive planning and expectations from reality, not the fantasy of what was demanded, that you never had a chance to accomplish.

In Jeffries own words: “I’ve been in those situations, and other than leaving, the best I know is to do good work, keep it visible, running, tested, and integrated, and help people to see reality.”

Final thoughts

We (the Agile movement) are in decisive moments, where we recognize what has been done in the last 10 years but we also know that we are not what we were supposed to be. Zombies and Orcs are far away from the original Agile Manifesto spirit and need to return to the roots and start again. But not only them… the whole Agile movement needs it. I end this article with thoughts of some of the guys that signed the original Agile Manifesto.

• “Developers Should Abandon Agile” - May 2018, Ron Jeffries.
• “So that's our current battle. (...), it's realizing that a lot of what people are doing and calling Agile, just isn't.” - August 2018, Martin Fowler.
• “Our first problem is dealing with the Agile Industrial Complex” - August 2018, Martin Fowler.
• “The second problem is the lack of recognition of the importance of technical excellence” - August 2018, Martin Fowler.
• In “The Land that Scrum Forgot,” Robert Cecil Martin (Uncle Bob) talks about the important technical fundamentals (like test-driven development) that were being left out of Scrum certification programs.

References

• Zombie Scrum - Symptoms, Causes and Treatment. https://www.scrum.org/resources/blog/zombie-scrum-symptoms-causes-and-treatment
• RAAAAUUUUGHHHH: The Wonderful (And Painful) Art Of Voicing A Zombie. https://www.audible.com/blog/arts-culture/raaaauuuughhhh-the-wonderful-and-painful-art-of-voicing-a-zombie/
• The Rise Of Zombie Scrum: Symptoms, causes and what you can do about it. https://medium.com/the-liberators/the-rise-of-zombie-scrum-cd98741015d5
• Zombie Scrum Resistance.
• How to Succeed With Zombie-Scrum?. https://www.barryovereem.com/how-to-succeed-with-zombie-scrum/
• Why Scrum sucks. https://techbeacon.com/app-dev-testing/why-scrum-sucks
• “Scrum is just Waterfall in disguise”. https://medium.com/serious-scrum/scrum-is-just-waterfall-in-disguise-3476203d0f00
• Dark Scrum.https://ronjeffries.com/articles/016-09ff/defense/
• Developers Should Abandon Agile. https://ronjeffries.com/articles/018-01ff/abandon-1/
• The State of Agile Software in 2018. https://martinfowler.com/articles/agile-aus-2018.html

‍