Maximize The Output, Or Optimize The Outcome?
A report of the flow, structure, and outcome of a community meetup we hosted for The Liberators Network
What creates Zombie Scrum? One clear theme we — and many others — have found is that people use the Scrum framework for the wrong reasons. When you ask people in a Zombie Scrum organization what they are hoping to get out of Scrum, you’ll hear things like “more speed”, “more output” and “more efficiency”. That’s very different from the actual meaning of the word “agile”. It’s also very different from what the Scrum framework is designed for.
In the meetup “Maximize the output, or optimize the outcome” we organized for The Liberators Network, we discussed what outcome our community members hope to achieve with Scrum. Although the Scrum Guide answer could be “I want to create more value for stakeholders”, many Scrum practitioners have more personal reasons to use Scrum as well. They use Scrum because of what it makes possible from a human point of view.
This blog post describes the flow, structure, and outcome of the meetup. I’ll also share my personal experiences and the key takeaways that emerged from the conversations the ±40 participants had. This meetup resulted in one of the most profound and important conversations on Scrum I’ve had in a long time. Why don’t you give this workshop a try with your team as well? Make it your next Sprint Retrospective format and jointly discover what your team hopes to see happen by using Scrum.
The Steps And Outcome Of The Meetup
In total, the meetup took 90 minutes in which the participants discussed three key questions. My recommendation would be to stick to this timebox. It might be tempting to shorten the rounds, especially if you have a small team, but a longer timebox allows your team members to dig deeper into personal experiences. With short timeboxes, you’ll probably only scratch the surface and the real reasons, hopes, or motivations to use Scrum might not be uncovered.
Step 1 — Describe Your Desired Outcome With Scrum
“What do you consider the desired outcome of Scrum? What do you hope it makes possible?”
This was the first question the participants discussed with each other. In all the answers, a couple of clear patterns emerged. For example, the desired outcome of Scrum is to shorten the feedback loop and to quickly validate assumptions on what & how to build the product. This reduces the risk of building the wrong product and allows teams to deliver value to stakeholders sooner.
Another desired outcome of Scrum is improved collaboration within the team itself and with stakeholders and management. The cross-functional character of Scrum teams encourages team members to jointly have all the skills to create a valuable increment every Sprint. This doesn’t mean everyone should be able to do all kinds of tasks. It does mean dependencies should be minimized, working in silos prevented, and expanding your skillset promoted. Ideally, stakeholders work closely with the Scrum teams to clarify what value they expect to receive. And management is considered the team's allies and supports them in removing impediments that block the team's progress.
A final pattern that emerged was the hope that Scrum helps to create a more sustainable work environment. Scrum teams, and the wider organization, have a shared understanding of the Product- and Sprint Goals. They try to achieve these goals at a sustainable pace. A pace that allows teams to experiment, learn, and have fun as well. Another key characteristic of an ideal environment is a high degree of psychological safety. Which is not about always agreeing with each other, or about giving compliments all the time. It is much more about encouraging people to speak up when they have worries, uncertainties, or doubts.
My personal experience
Before I started as a Scrum Master, about 12 years ago, I was a project manager at a web agency. The purpose of my role was to deliver software development projects on time, within budget, with high quality, and with all the necessary requirements. However, the only thing I managed to achieve was unhappiness. Unhappy developers, because of the growing crunch culture. Unhappy management because most projects weren’t profitable. Unhappy customers because they didn’t get their product on time and also not with the desired features. And unhappy account managers because what they promised to their customers proved not to be feasible.
So, my initial idea of using Scrum was to stop all this unhappiness. Which proved to be easier said than done. If you’re interested in the long story, check the article I wrote some time ago “My Journey as a Scrum Master”. In short, my desired outcome of Scrum evolved from stopping unhappiness by managing projects better, towards use Scrum as a framework to liberate teams from dehumanizing and ineffective ways of organizing work by putting them in control of shaping their future. To put it more simply: happy teams, happy stakeholders, happy organizations, yet without falling into the trap of “Happy-Clappy Scrum”. Although fun and happiness are certainly part of Scrum teams, they shouldn’t be more important than delivering value to stakeholders.
Step 2 — Share Personal Experiences Of Not Achieving It
“Share a story of a time when you were not able to achieve your desired outcome with Scrum. What happened? Why did it happen? How did it impact you, personally?”
In the second part of the meetup, the participants shared a story of a moment they didn’t achieve the desired outcome with Scrum. Coming up with an example proved to be easy, sticking to only one story was more difficult. Although each participant could easily define their ideal outcome of the Scrum framework, to make it happen within an organization was way more challenging!
The reasons for this gap between intention and reality varied widely. Some of the examples the participants shared were:
- Management was excited about Scrum, but the teams weren’t. It felt like yet another reorganization plan. After years of optimizing the organization with Lean, Scrum was seen as another fancy framework used by management to make the teams work harder, with fewer people.
- The teams were excited about Scrum, but management wasn’t. There were many rumors, whispers, and coffee machine talks about how Scrum proposes to get rid of managers. Teams should fully self-organize and self-manage in how they work, and with whom. As a result, managers resisted the organization-wide adoption of Scrum, and dependencies, bottlenecks, and impediments emerged.
- Scrum was implemented only partially. For some organizations, the Scrum framework proved to be too difficult to implement in its entirety. Despite its simplicity. The team's desire to release every Sprint to production wasn’t possible because of the organizations' compliance & governance. The teams struggled with using a Product- and Sprint Goal, because everyone was working on multiple products simultaneously, and the only recurring goal was to finish the Sprint Backlog.
My personal experience
I could easily have expanded the list with many other examples of why there’s often a gap between the intention people have with Scrum, and the reality they get stuck in. I can also share many personal experiences of why I’ve seen this happen. I’ll focus on one reason in specific, which ties into the essence of the Scrum framework: empiricism.
The Scrum framework is built on three pillars to support empiricism: transparency, inspection, and adaptation. The Product Backlog makes all the potential future work transparent, the Sprint Backlog makes the present work of the team transparent, and the Increment makes the past work transparent. The five Scrum events are the minimal opportunities for inspection & adaptation. During the Scrum events, the team & stakeholders agree upon three commitments and discuss the progress towards achieving them: Product Goal, Sprint Goal, and Definition of Done. It goes beyond the purpose of this blog post to discuss this in more detail, this is already done in our whitepaper on Scrum.
In my personal experience, I’ve seen organizations struggle the most with the “adaptation” part. Scrum makes the state of your team and organization transparent. By using Scrum, many impediments become visible. Impediments that manifest themselves on the team level, but are ingrained in the entire organization. If a team struggles with creating a unique Sprint Goal, it could be because of its composition, the type of work they do, or the number of projects they’re working on. To change this, it might mean a large part of the organization needs to be reorganized. This isn’t something every organization realized when they started with Scrum. As a result, instead of resolving impediments, they get neglected. And the cycle of “transparency, inspection, adaptation”, becomes “transparency, inspection, ignore”. This results in demotivation, meaningless Scrum events, and lots of frustration. Often Scrum gets blamed for not being a suitable framework for the organization, and the search for a different framework or methodology continuous…
Step 3 — Discuss Your Personal Lessons Learned
“Given the experience you’ve gained with Scrum, what is something you do differently nowadays? What helps you increase the likelihood of achieving your desired outcome?”
During this final step of the meetup, the participants shared what they’ve learned on how to achieve their personal purpose with Scrum. One clear pattern in all the answers matches my own experience as well: don’t try to convince people to change, don’t push Scrum into a team and organization, and don’t force adaptation. As I described earlier, Scrum helps you create transparency about the state of your organization. It holds up a mirror. You might not like what you see, and you can ignore it by not looking into the mirror, but it’s simply the reality.
Scrum also helps you to inspect where improvements can be made. The framework offers you guidance on how to adapt. The final step of truly adapting, of removing impediments, changing behaviors, redefining processes and procedures: that’s something you can’t enforce. I strongly believe that people should take the initiative to drive change themselves. If people don’t “own” the solution to the problems, implementation will be mediocre at best, probably misunderstood, and, more likely than not, will fail.
Some organizations embrace it and are willing to face the sometimes painful reality, and for some organizations, the momentum to change isn’t there. As we describe in our book the Zombie Scrum Survival Guide: not every organization is able or willing to recover from Zombie Scrum. Sometimes, persistent beliefs, existing structures, and power imbalances may make it too hard to change anything. Don’t waste too much energy on the stuff you can’t change. You have to be realistic about what’s possible.
I do want to emphasize that in every organization there are people willing to change. Focus on those people. Try to be successful with Scrum in only one team. Show the organization its potential, and slowly try to get more people on board. Ideally, the people that can help you remove the tough impediments. If you’re interested to learn more about change & resistance, check this article that Christiaan Verwijs wrote. Just remember that there’s a community available willing to support you in your journey. You’re not alone. Let’s learn and grow, together!
Closing
In this blog post, we’ve shared the outcome of the meetup we organized recently for our user group The Liberators Network: “Maximize the output, or optimize the outcome”. We described the flow, and structure of the meetup, and I’ve included my personal experiences. Why don’t you give this workshop a try in your own team and organization? Good luck, and let us know your experiences!
