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 :)
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.
We will define some terms to better understand the background of this article and later discuss the relation between them.
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.
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!
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.
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).
“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.
“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.
“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.
"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.
Zombieism in Scrum teams is curable following one or many of these pieces of advice:
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!
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.
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).
[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.
“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.
“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!
[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).
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:
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.”
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.
Ready to get started? Use the form or give us a call to meet our team and discuss your project and business goals.
We can’t wait to meet you!
Call us!
+1 (347) 871 09 22
Write to us!
info@vairix.com
.svg)
.svg)
.svg){kind=icon}
.svg){kind=small}