Diagnose & Cure Zombie Product Ownership in the organization
Scrum is a collaborative process focussed on frequently delivering working software and bringing value incrementally to the persons using it. With scrum, we can test important assumptions:
- about users (“do people want this?”),
- about our collaboration (“are we on the same page?”),
- about time and money (“how much time will this take?”)
- and about technology (“will this work if we build it like this?”).
Scrum is big and popular. There’s no doubt about that. But the increasing population of Scrum Teams (with a lot of them working in software development, but not only) is also giving rise to an equal increase in the incidence of Zombie Scrum.
What does Zombie Scrum mean? Zombie Scrum is a bit like Scrum, but without the “beating heart” of working software, to start with. It’s just a fun way to qualify a situation where scrum is not working.
Zombie Scrum is not marginal, it’s common…
There is a very clear description of the Product Owner role in the Scrum framework, but you would be hard-pressed to find a company that comes even close to living the role the way it was originally intended.
When it happens, it’s not because these companies found out that strong product ownership doesn’t help them solve their problems. Instead, for numerous reasons, they go a quarter or two of the way and settle on fitting the Product Owner role into their existing organizational structure.
The result is a powerless Product Owner that acts on other people’s decisions and represents one link in a long hierarchical chain. Her focus is most often technical and operational, and rarely strategic.
How, in these conditions, can the product owner deliver on his core responsibility: Maximizing the value of the product? No, it can’t.
The Product Owner is only half the story. Development teams that are owning a product, with all the freedoms and responsibilities that come along with it, make a tremendous difference. Scrum’s feedback loops come alive when teams are directly connected to a unifying purpose and can see how they contribute to it every day.
Sadly, most companies put a big buffer between development teams and the source of the need the product tries to address. Product Ownership usually gets diluted through various roles and the only thing the development team receives is overly detailed “user stories” that lack both user and context.
Click to Tweet
The spectrum of product ownership
At any given time, you’ll have all levels of work in this diagram (A-I) happening simultaneously. All connected. The connections may be implicit, obstructed, opaque or flimsy but they’re there.
Symptom recognition of the Zombie Scrum affliction
Lack of true product ownership
Lack of true product ownership is a primary cause of Zombie Scrum, and it generally leads to one or more of the following issues:
- Trouble prioritizing items
- Miscommunication, which in turn leads to things being developed that don’t address the original issue
- Long delivery times
- Lack of innovation
- Lack of ownership on behalf of the teams
An unambitious DoD (“Definition of Done”)
In Zombie Scrum teams, there is a very unambitious “definition of done”. And worse, it seems just normal to everyone, so there is no drive to extend it. The Zombie Scrum team performs all the Scrum events but a potentially releasable increment is rarely the result of “one” Sprint. Commonly, items from the Sprint Backlog get carried over to the next Sprint without question. There’s always a next Sprint and each iteration is artificial anyway because items on the Sprint Backlog are not tied to any specific Sprint goal. As a consequence, they can be completed whenever the team feels like it.
Boring sprint reviews
To continue with the analogy with Zombies, the lack of a beating heart is dysfunctioning scrum teams that are most prevalent during the Sprint Review ritual. No one takes is keen to demo what they’ve made. Instead, slides and screenshots were prepared, maybe some release notes, or there’s just a simple talk about what was the Sprint about. If anything is demo-ed, it is either very technical or unfinished and accompanied by comments like “We have to finish this in the next sprint” or “Sorry, it’s not working yet”.
The Sprint Review takes place without any discussion which is also a subtle indicator of Zombie Scrum. No opinions, suggestions or ideas are discussed. Are stakeholders even here or never at all? The stakeholders have forgotten the existence of this team a long time ago. So who cares about working software, gathering feedback and generating insights?
Besides, the PO seems to be OK with everything. In short, instead of inspecting working software, the Sprint Review is mostly “ticking off boxes”.
Little consideration for what’s upstream or downstream in the value chain
Lack of ownership translates in responsibility shielding. Zombie Scrum teams want to depend on others to avoid taking responsibility. They hide away from the outside world, keep to their familiar surroundings, as a cog in the wheel.
- The product failed to meet customer expectations? I’m only here to code!
- The app is causing memory leaks and makes the user’s computer unresponsive? QA should have caught that before deployment!
- A stakeholder wants a cool Flash intros in the onboarding and red marquee text on the landing page? I’m not a designer.
The idea of being directly involved in the design and validation of features seems un-natural! It’s old-fashioned silo-thinking and directly goes against the idea of cross-functional teams that have all the necessary competencies to get the work done without depending on others.
This is usually a reflection of the functional silos that are already in place in the organization. Testing is done by a QA team, deployment is done by Operations, and user feedback or support documentation is handled by Support.
Applying Scrum on top of the traditional functional silos, there are many steps and hand-offs between what the team delivers (The functionality that is defined as “Done”) and what eventually touches real users. Therefore, a team will learn very little and very late about the effect of what they have made in the real world.
Low team morale, emotional indifference to sprint outcome. Low drive for improvement
The lack of contact with the outside world, lack of consideration often leads to these symptoms. Where other teams curse or rejoice, Zombie Scrum teams show no response to a failed or successful Sprint. Team morale is very low. The lack of control a team experiences over their success easily translates into boring retrospectives, a lot of complaining (moaning). And certainly no desire to improve.
This is amplified when the Product Owner is seldom present during the Sprint Review or the Sprint Planning. Teams are highly unstable, members continuously get loaned out to other teams in need, and there’s no actual Scrum Master present to help the team improve.
More causes of Zombie Scrum can be read here.
Putting Zombie Scrum in Perspective: How does it differ from Healthy Scrum?
In a healthy Scrum, team members understand that the more “done” the functionality is, the more it touches real users, real data and real hardware and the more useful the feedback will be for learning what is needed. Healthy Scrum teams want to deliver a continuous & steady stream of valuable, completed and working software, ready for review with key stakeholders. They consider it as an essential goal of Scrum and believe that working software is the single best way to test assumptions on time, technology, user expectations, etc.
With real product ownership, sprint goals make sense and the sprint review is a necessity, not a waste of time. The people involved don’t just go through the motions but depend on the feedback gathered during Scrum events.
Zombie Scrum is essentially the result of a systemic mismatch with Agile values. Healthy Scrum easily decays into Zombie Scrum when people in the organization hold beliefs about software development that collide with what drives Agile software development.
Credit to Christiaan Verwijs for this great table.
Curing the Zombie Infection
From denial to acceptation
Zombie Scrum Teams are rarely happy with their predicament. So a good start is to talk about their situation and identify potential causes and solutions.
Zombie Scrum is not a team-problem, but a manifestation of the disconnect between organizational values and Scrum values. Teams probably won’t be able to climb out of Zombie Scrum on their own. Broader interventions will be necessary, like bringing frequently the representatives from the teams and management together in meet-ups to find solutions to problems that the teams can’t change on their own. Management has to support and communicate the key values of Healthy Scrum in everything they do.
Get support to understand how Scrum should be applied to your context
Zombie Scrum Teams are often trapped and they need a guide to help them out. Limiting yourself to only raising awareness of issues without making progress doesn’t necessarily help.
It’s best to get people into the team to show and explain how Scrum is supposed to works. Zombie Scrum teams often feel that things aren’t working as well as they should, but are unaware as to what’s causing this. It can also help to bring in Agile coaches to help teams and management understand Scrum better, as long as their focus remains on helping the organization take care of things themselves as soon as possible.
With the ever-increasing adoption of Scrum, there is also an increasingly large community. Benefit from the community by asking help from people with more experience. Visit local Agile or Scrum Meetups, use forums (like the one at Scrum.org) or Facebook to ask for help or invite fellow Scrum Masters or Agile Coaches to drop by.
Multiply small wins and try to break the monotony
Don’t focus on what’s not working, but look at what possibilities for improvement. The focus should lie on: “How can we deliver more working software every sprint”.
Consider adapting the way the team interacts within the Scrum framework, for example:
- Shortened Sprint length to two weeks or even just one.
- Focus the Sprint Planning on answering the question of what type of impact the team would like to achieve within the upcoming Sprint.
- Start the Daily Scrum by reviewing the Sprint Goal and asking what achievements the team has made towards reaching that goal.
- Use the roadmap to provide context for the insights from the Review meeting. Invite some real customers or stakeholders to get some outsiders’ feedback!
- Use the Retrospective to dream big, not to drag out the same old problems.
Try this tool to fix the product ownership issue
So, how do you tackle the lack of attention to Product Ownership in an organization?
There are many classes for Scrum Masters and Agile Coaches, but it won’t change the fact that as long as Product Owners are neglected, the whole development process will suffer.
The Product Ownership Evolution Model (POEM) can be used to help the organization to make sense of their current approach to product ownership and identify opportunities for improvement.
Below is what it looks like:
POEM is a canvas created by Oliver (@oliwin) and his friend Tim Klein (@produktwerkCGN). Great thanks to them.
Check with the people involved in making decisions on a specific product whether any of the issues mentioned above are giving them trouble. If they enthusiastically scream yes, get those people together in a room and use the POEM.
The heart of the POEM is the visual overview: product ownership is spread out on a scale from “strategic” over “tactical” to “operational”. Below the scale, we find specific tasks people might engage in that makeup product ownership as a whole, such as crafting a Sprint Goal and writing user stories. These can be adapted to your specific context.
How to Use the POEM?
A template of POEM can be found here, on the website of its creators.
Give everyone a copy of the template.
Participants individually place the PO horizontally on the scale, in the “actual state” section, according to how much authority he or she has. So if your PO can autonomously decide on roadmap scope without consulting anyone else, that’s where you put him or her on the scale.
Place everyone places the development teams and additional roles like Business Owner / Chief Product Owner / CEO / Management on the POEM.
After the participants have created their overview of the actual state of product ownership they can then start contrasting it with the target state. For this, the participants simply place the roles in question on the corresponding part of the POEM according to where they believe the role should move.
You are then ready to share the individual results with the group. This is best done by simply hanging all the sheets up on a wall and asking the attendees to look at them. What do you notice? Are there disagreements about the authority of a role? Do you all agree on the current way these roles are defined in your organization? Where does everyone think these roles should move? Is there agreement on the target state?
Finally, you can ask what is needed to make the target state real. For this, you can use the fields “coaching demand” and “coaching offer”. Compare how much coaching you are offering at the moment and what would be needed to help the roles in the POEM move further to the left. This can include coaching through Agile Coaches, Scrum Masters, other more experienced POs, or external trainers.
A catalytic tool in the ongoing fight against Zombie Scrum
One pattern that is a reliable indicator of Zombie Scrum is an abundance of roles coupled with a PO and the development team to the far right on the scale.
It means neither the PO nor the development team is empowered to make crucial decisions on their product. Other people in the organization often pull the strings.
That overview itself is often a really helpful first step. However, if you want to break out of Zombie Scrum structures, you will also need to make actual changes.
Collaborating around the POEM can trigger deep conversations and lead to big changes.
If there is no desire for change, you will need to spend a lot of time creating awareness first, raising attention on product development issues:
“We don’t do Scrum by the book!” is usually not a convincing argument.
“It takes us months to ship a regular feature? Doesn’t that give a huge advantage?” is often a much better way to start a conversation.
Be relentless when it comes to surfacing dysfunctions, and hopefully, you can find a cure for your Zombie Scrum infection.