Christiaan Verwijs

How do you change a system that is as complex as an organization? This is the quintessential question facing Scrum Masters, Product Owners and other drivers of change. In this post, we explore how the Liberating Structure ‘Panarchy’ offers a powerful perspective and allows you to put systems thinking into practice. And even though it is perhaps the most complicated of them all, Panarchy brings together all the promises of Liberating Structures: engage everyone and unleash change on every level. Its a great way to drive organizational change together in an organic way.

This is a series on how to create more engaging and interactive Scrum Events with Liberating Structures and recover from Zombie Scrum.

This post is an excerpt from the book that we’re writing, the ‘Zombie Scrum Survival Guide’. It’s our way of delivering small increments and involving our stakeholders. So we’d love to hear your feedback, encouragements and wild ideas. You can also listen to us reading this post on our podcast. When is someone a stakeholder, really? It’s such a simple question that you can’t help but wonder why we’re even asking it. The Scrum Framework relies heavily on involving stakeholders. And for good reason. You need them to validate your assumptions and to determine what is valuable (and what isn’t). “There is a big difference between a stakeholder and someone with an opinion about the product” Its a simple question. Still, many Scrum Teams and organizations struggle with it. We’ve visited Sprint Reviews where all the ‘stakeholders’ present were internal to the organization; people from marketing and sales, an internal product manager and an opinionated colleague. None of them were either using or paying for the product and its development. We’ve found that not including the right stakeholders is one of the primary causes of Zombie Scrum. This post is all about what makes a real stakeholder. And more importantly, how to find them. Stakeholders, Users or Customers? When we talk about Stakeholders, are we talking about Users? Customers? Internal or external customers? Product Managers? While some organizations work exclusively for external customers, many organizations also have people inside the organization that should be included in deciding what is valuable. And in other organizations, the term ‘customer’ is not something that people are used to, like in NGOs and governmental agencies. “We see many examples where the vagueness of ‘stakeholders’ is leveraged into making teams believe that only talking to internal stakeholders is what Scrum is all about.” For this reason, the Scrum Guide purposefully talks about ‘stakeholders’ as a placeholder for anyone who has a stake in the product. Like in a betting game — where the word ‘stake’ comes from — they personally have something to gain when the team delivers and something to lose when it doesn’t. But particularly in Zombie Scrum, we see many examples where the vagueness of ‘stakeholders’ is leveraged into making teams believe that only talking to internal stakeholders, domain experts or intermediaries is exactly what Scrum is all about. For them, it’s not necessary to talk to the people using the product or paying for it. And that is a huge issue. Stakeholders help reduce risk In product development, we want to balance the user or customer perspective with a business perspective. Only focusing on one of them is going to lead to trouble. Yet in virtually all the Zombie Scrum Teams we’ve worked with, the side of the customers and the users were woefully underrepresented. This leads directly to many of the symptoms of Zombie Scrum. And it keeps risk very high. “Risk” is the keyword here. When you are developing a product with your team, you are investing time and money into building something that you hope will return on that investment. And stakeholders — in particular users and customers — are your natural allies. By going back to them very frequently, as Scrum encourages, you can verify if you’re still on track. Are you still spending their money right? Are you still working towards solving the problem they need your product for? So, including actual stakeholders is the best way to reduce the risk of building the wrong product and/or solving the wrong problems. But how do you find them? “In product development, we want to balance the user or customer perspective with a business perspective.” Three questions to find them So while it is easy to include many people in product development and simply call them ‘stakeholders’, it is far more difficult to find the people that have an actual stake in your product. We find the following questions helpful to discover if they have a meaningful stake (and either one or more should clearly apply): Are they going to use or are they using the product on a regular basis? Are they investing significantly in the development of the product? Are they personally invested in solving a challenge that your product addresses? You’ll notice that these questions are about value. A stakeholder is someone who helps you decide what is valuable to work on next because it’s important to them to get a return on their investment of time and/or money. Everyone else is your ‘audience’. This likely includes domain experts, intermediaries and other people that are interested in your product but have no personal stake in it. You can happily invite them for the ride, but you want to focus your energy and time on your stakeholders. Naturally, this perspective emphasizes the involvement of the people using your product (users) and the people paying for it (customers). Closing words In many cases, recovering from Zombie Scrum starts by finding the right stakeholders and continuously refining who is part of that group. In this post, we clarified what it is meant by ‘stakeholders’, and offered three questions to find them. So go out and include your customers and users into the development of your product. It will be much better because of it. Sign up for the book We — Johannes Schartau, Christiaan Verwijs, and Barry Overeem — are currently up to our necks in the process of writing a Survival Guide for Zombie Scrum. It’s a hands-on guide filled with results from our on-going research and dozens upon dozens of bold-yet-practical interventions to start your road towards recovery. The book will be published by Scrum.org and Addison-Wesley in Q4 of 2020. Sign up here to stay informed and provide feedback on our writing.

Sprint Goals are one of the more elusive parts of the Scrum Framework. Most teams know they are important, but few use them - for a variety of reasons. In this post, Barry Overeem and I bust the myth that Sprint Goals are optional in Scrum. And we make an effort to show what makes them so vital in the face of complex work. And more importantly, what you can do to start working with Sprint Goals from now on.

Want to know if your team or organisation is suffering from Zombie Scrum? Find out with our free symptom checker and get help. And join our worldwide research into how teams work with Scrum, and what works for them.

Conflicts are fascinating. Now, this may be the organisational psychologist in me talking, or the facilitator who senses them in the groups I work with.

Writing code is like finding your path through a dark forest. Behind each tree can lurk a monster, a treasure or a pit. Or there is no path at all.

During a recent meetup of The Liberators Network, we got together with 30 enthusiastic Scrum Masters.

A personal story of what encouraged a Developer Culture at NowOnline. And why Scrum really doesn't work without it.

Changing the way we work is extremely difficult — we all know this. It requires us to find novel solutions to wicked challenges, to deal with cultural baggage (‘the way we do things here’) and to bring along the people needed to make a change successful.