Some time ago, we hosted an experience interview with Carsten Lützen. Carsten is an Agile Coach at the LEGO Group and the founder of Agile Ideas. He has a passion for improving teams, facilitating powerful learning moments, and is an experienced graphical facilitator and professional Solution-Focused Coach. You might also know Carsten from his YouTube channel, in which he shared hands-on tips & tricks about Agile, coaching, and facilitation. Most important: he’s an awesome guy and a good friend of The Liberators!
During the one hour meetup, we covered a wide variety of questions, for example:
- What is it like to work for one of the coolest companies in the world?
- Does the LEGO Group face Zombie Scrum issues as well?
- What does Agile at the LEGO Group look like?
- How is “value” defined at the LEGO Group?
- What are the most common impediments you face in terms of business and/or team agility?
- What are some of the painful impediments the LEGO Group had to overcome to increase its agility?
- When developing a new product at the LEGO Group, how do you get feedback?
Interested to learn how Carsten answered these questions? Check the video!
In this blog post, we focus on one specific topic that emerged:
“How a culture of learning and experimentation can prevent Zombie Scrum”
Zombie Scrum?
If you’re already familiar with our content for a while, you probably also know what Zombie Scrum is about. For everyone else, here’s a short summary of the concept. Zombie Scrum looks like Scrum from a distance. It might seem that a team has all the important elements of Scrum in place. They have a Product Owner, Scrum Master, and a bunch of Developers. They conduct all the Scrum events, use a Product Backlog, and even a Sprint Backlog. But closer inspection shows you there’s something wrong… the team seems to be missing the beating heart of Scrum: a working, valuable product!
The team doesn’t even know for whom they should actually build the product, they don’t have a clue who their stakeholders are. Due to dependencies and constraints, the team can’t ship their product increments and validate if what they’re building is really valuable. They lack the support from management to resolve persistent impediments. Everyone can identify the areas that need improvement, but the motivation to change the situation is nowhere to be found. The team focuses mostly on superficial improvements, this gives everyone the illusion of continuous improvement. These are some of the symptoms of Zombie Scrum, for a full description, check the Zombie Scrum Survival Guide.
Can you spot any other symptoms of Zombie Scrum?
Zombie Scrum at the LEGO Group?
If you would assess Scrum at the LEGO Group with a superficial Scrum checklist, you might draw the conclusion that the organization is infected with Zombie Scrum. For example, some teams only do the Daily Scrum once or twice per week! However, a more thorough inspection would show you the opposite. These teams felt the urge to synchronize their work continuously, doing the only once per day felt like a bottleneck. Of course, the Scrum Guide doesn’t tell the team can’t continuously communicate and collaborate with each other, the Daily Scrum is only intended as a minimal daily opportunity for inspection and adaptation. Yet these teams wanted to experiment with less fixed Daily Scrums, and more with a continuous flow of collaboration.
This is a key distinction between Zombie Scrum and professional Scrum. Scrum teams might start every day with a Daily Scrum. But if it’s only done mechanically, and doesn’t achieve its purpose (inspect the progress towards achieving the Sprint Goal and make adjustments accordingly) it’s still Zombie Scrum. If a team has found a different way to achieve this purpose, and it's fully supported by all the team members: awesome!
A great team has a laser-sharp focus on what they want to achieve. They have a shared purpose, clear goals, and a flexible strategy to achieve the purpose and its goals. Scrum might be part of the strategy. However, because of the existing culture of learning and experimentation, it could also result in Kanban, Scrum with Kanban, or SAFe. It might be they try different techniques for estimation & forecasting, or the responsibilities of a Scrum Master are distributed amongst all team members.
Within the LEGO Group, there’s no one-size-fits-all teams solution to make all the teams Agile. so, there’s also no big Agile transformation plan. Instead of suffocation teams with governance and compliance rules, they are offered enabling constraints. The teams are considered the experts, they know what is necessary in order to do their best work. The environment around the teams, including the Agile Coaches, is there to support them. To help the teams remove the impediments that block their progress. And, most importantly, to encourage teams to learn & experiment with practices, methods, and frameworks they consider most useful to help them achieve their purpose.
Within the LEGO Group, there’s no big Agile transformation plan that includes sending everyone to expensive (Scrum) training with the sole purpose to get everyone certified.
Experiment & Learn
There are no one-size-fits-all solutions to implement Scrum. Every organization has its unique characteristics that should be taken into account when working with Scrum. That doesn’t mean that nothing needs to be changed, and you need to accept the status quo. It does mean that using a standardized plan to roll out Scrum across multiple teams probably won’t work. Teams need time to make it their own. To figure out how they can use it to build what stakeholders need, to ship faster, to continuously improve, and to self-organize around the removal of impediments.
Figuring out how to make Scrum work for your team requires lots of experimentation. Ideally, these experiments are initiated by the teams themselves, and supported, not dictated by management. As Marvin Weisbord puts it: “People support what they help to create.” (M. Weisbord, Product Workplaces: Dignity, Meaning & Community in the 21st Century). Management support is essential for Scrum teams to be successful in conducting these experiments. It’s inevitable that teams stumble on tough impediments that block the progress and are beyond their self-organizing capabilities to resolve. In that case, support from management is vital to overcome those challenges.
“People support what they help to create.” — Marvin Weisbord
If you want to promote a culture of learning & experimentation in your organization, it’s important to create a safe environment. Some experiments will be successful. More often, they’ll probably fail. Although, what is failing? If the team has learned a ton of new things by running an experiment that “failed”, isn’t that a success anyhow? But still, if the mindset in your organization is focused on “failure is not an option”, teams probably won’t try any difficult, high-risk experiments. Experiments that if they would succeed, could result in a huge benefit. Some teams only stick to Scrum because that’s what they’re told to use, while they might be better of with Kanban, XP, or a mixture of everything.
So, how do learning and experimentation prevent Zombie Scrum?
Earlier in this post, we explained that the beating heart of Scrum is a working, valuable product. Learning and experimentation could be considered as a good alternative. The willingness, eagerness, and motivation to learn & experiment are what keep Scrum alive within a team. Scrum won’t be perfect from the start. Given the complexity of today’s work, it probably will never be perfect. And that’s ok. The ever-changing dynamics within and around the team require continuous inspection and adaptation. As long as the team has the drive to learn and to run experiments to figure out what works for them, Zombie Scrum won’t find futile ground and can’t take root.
“As long as the team has the drive to learn and to run experiments to figure out what works for them, Zombie Scrum won’t find futile ground and can’t take root.”
Closing
Some time ago, we hosted an experience interview with Carsten Lützen. We ended up talking about what Agile at the LEGO Group looked like, how they use Scrum, and if they recognize the symptoms of Zombie Scrum. In this blog post we’ve focused on a topic Carsten strongly emphasized: encourage the teams to learn & experiment, and let them figure out what works best. As long as the team has the drive to learn and to run experiments to figure out what works for them, Zombie Scrum (or fake Agile) won’t find futile ground and can’t take root!