Why Are Too Many Scrum Teams Focusing on the Wrong Things?

The art of maximizing features no one cares about isn’t why Scrum exists.

Sprint in, Sprint out. Crap in, crap out.

Is Scrum the art of maximizing crap? 

Are Scrum teams supposed to please business people and do as they say?

I thought doing Scrum required meaningful collaboration, but I’m disappointed with what I see: A rigid service-provider relationship defines how teams work. I’m done with that.

Every Sprint is exhausting. Business always wants more than the team can ever produce. Product Owners focus on compromises, cutting corners, and squeezing the lemon. Meanwhile, nobody talks about value because everyone’s too busy doing capacity planning.

Is that how Scrum should be? I don’t think so.

Don’t worry, this story isn’t just about my complaints. I won’t write this piece to say everything is horrible, and we have no chances with Scrum. Instead, I want to give you hope and some insights on how you move from delivering crap to creating value.

The Birth of Crap

Many Sprints I’ve led resulted in crap. That’s bad, and the problem wasn’t only with business people. I was a big part of the problem because I didn’t know how to influence business.

When we bow to business pressure, blaming is never helpful. We better understand our contribution to failures. When I say crap, I mean something that doesn’t create relevant value for end-users and businesses. It ends up being something that nobody needs.

No one in a team wants to work on something useless. That’s not why you go to work and spend more than a third of your day there. So, how can you end up in a situation where your work doesn’t contribute to something valuable?

A lack of problem understanding will inevitably lead to crap.

Now, tell me one thing: What’s your discovery and delivery ratio? 

If you’re like most teams, probably around 90% goes to delivery and 10% to discovery. This means too much attention to delivery without understanding the problem. I wonder how you can solve problems while driving outcomes without properly investing time in understanding them.

Most teams struggle to find the right balance between discovery and delivery. Business wants more output, and teams find no time for discovery. Or worse, discovery happens outside the team, and Scrum teams are diminished to delivering output. The result is, unsurprisingly, poor.

A sustainable balance between discovery and delivery is 25% delivery and 75% discovery. I know, I sound crazy. But what’s even crazier is working at a frenetic output speed without knowing what the heck you are solving. Yet, you should be careful not to fall into analysis paralysis. Sometimes, building something fast is still a great way of product discovery. Customers using your real product is a great way of doing it. In short, if building it quickly is faster than discovery, just do it and learn from users’ feedback.

Moving from Shipping Crap to Creating Value

Accepting the status quo as unchangeable won’t take you anywhere. But trying a big-bang approach won’t be helpful either. Trust me, don’t try changing everything at once; you’ll just hit the wall as I did.

A better way to foster a transformation is by starting small. I don’t believe in convincing business stakeholders; I believe in taking them on a journey and discovering together how to create value faster.

Try to understand the critical elements behind feature requests. Questions will help you and your business stakeholders clarify the big picture before jumping to execution. Before any feature implementation, I encourage you to know the following:

• Desirability: How do you know end-users want the feature you’re considering?
• Feasibility: Can your team create a valuable solution?
• Viable: How is that viable from a business perspective?

Make it visual and position your ideas on a Venn Diagram with Stakeholders. This will give clarity.

When you reflect on these aspects, you may not have the answers to everything. That’s fine. The goal is to slow down implementation and drop ideas that may trap your team.

Be careful! Stakeholders may assume they know what end-users need, but that’s not enough. You need solid evidence before jumping into delivery.

I often notice many feasible and viable but not desirable ideas going to a Sprint. The result is something end-users will ignore. You can avoid that easily by checking critical assumptions before jumping into building a full-blown solution.

Dealing With Assumptions 

Hopefully, the previous Venn Diagram will help you drop bad ideas and focus on more promising ones. But it’s not time for you to jump to implementation. It’s time to name your assumptions and figure out how to check them.

Assumptions can be tricky. Many teams strive to validate them and fall into confirmation biases. Run away from it. I recommend asking one question: “What could potentially go wrong?” When you reflect on this question, you’ll uncover potential traps ahead of you. 

Strive to identify different types of assumptions. Sticking to desirability is common because we would take the user’s perspective. Nevertheless, it’s crucial to go beyond and consider feasibility and viability assumptions too.

Once you’ve named your assumptions, you’ve got to prioritize them and act on the critical ones. I love using the Assumption Matrix by David Bland. It’s a great tool to help teams focus on what matters most.

You need two attributes: Importance and Evidence. Once you categorize your assumptions, test the ones you lack evidence for and are business critical. There are many different ways of testing assumptions; be aware of the type of assumption and what you want to test. I recommend Testing Business Ideas by David Bland to know which technique to use.

Search for reasons not to build the idea. This will help you avoid falling into confirmation bias.

This Is Not Possible With Scrum!

I imagine you’re thinking, “This all sounds logical, but it will not fit with our Scrum Team.” I feel your pain. I used to think so too, and I wish I had seen that differently.

Scrum isn’t solely a delivery framework. It’s a framework to help teams foster collaboration and create value sooner. Discovery is part of that too. It’s not because most Scrum teams don’t do it that you should not start doing it.

Stakeholders will always push you to deliver more output. This is just business as usual. But you have a choice to make: You can help stakeholders step back and understand the journey to create value, or you can do as they say and risk having them get mad in the future because the team didn’t create the expected business outcome.

Jumping to a solution without knowing the problem is madness. I’m sorry, but that’s what it is. Assuming we know how end-users will behave is too naive. 

Doing what it takes to create value requires a lot of courage. It’s hard to deal with pressure and coaching stakeholders all the time. To help you create the required courage, just think about the potential outcome of not doing that. That’s the choice you have to make.

Final Thoughts

For many years, I let business stakeholders have a final say in what goes into a Sprint and what doesn’t. I ended up leading teams to create useless things. Looking back, I learned that my role was to help stakeholders step back and reflect. It wasn’t about fighting against them; It was about collaborating and figuring out what to do and what not to do.

It’s easy to fall into the victim role. It’s easy to accept the status quo as ultimate. And it’s bloody hard to lead teams to create value sooner. I’ve learned my lesson. Slow down. Strive for communication and clarity. Only then do you have a better chance of succeeding with Scrum. 

Never let a service-provider relationship between business and product dominate how you work. Strive for collaboration.