Implementing Scrum Without Talking About Scrum

During my journey, I’ve seen many Scrum implementations stall or die. I can’t name a specific reason for that, but I realized that an extensive focus on the framework tends to lead to pointless discussions and distractions from what matters most: creating value. 

When teams focus on doing Scrum better, they trap themselves in questions like:

• How could we plan our Sprints better?
• How could we refine our product backlog items more precisely?
• How could we optimize our velocity?

Although these questions have value in them, they won’t yield action for significant improvement in how you benefit from Scrum. My approach is a little counterintuitive; let me share it with you:

Focus on changing the attitude first without talking about frameworks. Changing the mental model is more important than deploying a framework.

Allow me to share a story where I observed a company thriving with Scrum without talking about it.

Recognizing the Problems

Before I joined the team, I had acquired valuable experience, mainly on how not to do Scrum. On my first day, my new manager told me how skeptical the company leadership was with Agile frameworks, but he wanted me to figure out the problems that were hindering teams from growing. That was my first assignment.

I spent the first two months observing how teams worked. One thing stood out: everything had an approval process. Stakeholders had to approve tickets before developers could implement them, and Product Managers had to get the work from developers. It was a lengthy and unempowering process. What got my attention was that nobody knew why everything had to be approved. They followed the process they were used to, but never challenged the reason behind it.

Another aspect I noticed was the slow feature releases. Teams had to follow a strict quarterly roadmap, and the release would happen only at the end of each quarter, unsurprisingly not meeting about half of the stakeholders’ expectations.

I laid down what I discovered with my manager and suggested we would slowly start changing how we work. He asked me whether I wanted to implement a framework or not. I did envision using Scrum, but understood that the company was skeptical, so I decided to focus on the necessary changes to gradually become more Agile and less Waterfall. I told him I wanted to change how we work and speed up our release time. He gave me the green light.

Focus on the Changes

I was surprised the team followed a process blindly without knowing why they were doing it. I decided to have a brainstorming session with them and figure out how we could shorten release time. That would help me gain buy-in from teams, meet them two steps ahead, and guide them on a journey. After the workshop, we came up with the following:

• Stop quarterly plans and start planning monthly
• Remove stakeholder approval by including them in the development journey
• Product Managers focus on bringing the context and providing feedback to developers as quickly as possible instead of approving finished features

I grew confident that the team could start benefiting from Scrum, but I was aware of skepticism across the company. I had to figure out how to do Scrum without talking about it. I asked the team how satisfied they were with their work model, and everyone admitted to being unhappy with how they worked. That was all I needed.

We agreed on doing the following:

• Goal and Action: Every two weeks we would get together with stakeholders, commit to a goal, and the team would figure out how to address it.
• Problem understanding: Once a week, Product Managers would discuss upcoming work to understand the problem and desired results.
• Sync and Adjust: Every day, the team would get together to review how confident they were with achieving their commitment. The goal is to address any issue and keep progressing.
• Resonance: At the end of each cycle, the team presents the result to stakeholders to get their resonance and agree on the next steps and when to ship.
• Reflection and improvement: Before starting a new cycle, the team would take the time to reflect on how satisfied they are with their current working mode, results, and collaboration. The goal is to define a maximum of three actions to improve during the next cycle.

I remember a team member standing up and saying, “Hey! This is Scrum, and management will never approve it.” I couldn’t deny that it was related to Scrum events, but Scrum is more than just events. Still, I didn’t want to make a big deal out of it and just asked him, “Do you want to focus on creating features, or do you want to try something less prescriptive and more empowering?” He longed for change but feared the leadership would impede us from working differently. I told him, let’s only worry about a problem once we have it.

Just Do It

Instead of convincing management to use Scrum or any other Agile framework, I told them we struggled to create value and that I would like to improve how we worked. Our current method was slowing us down, and I feared competition would be quicker to act and we could soon become irrelevant. With that, I got their attention. 

Management wanted to know what I had in mind. I presented our new way of working and said we would love to get closer to business stakeholders and develop a solid partnership instead of a service provider relationship. For that to happen, we’d have to forego quarterly plans and employ shorter ones; this would empower us to react faster. They seemed skeptical but shared that the current situation didn’t please them, so they decided to let us try a different approach. Before I concluded the exchange, a senior manager told me, “If you see something is getting stuck, just come to me and I will help you.”

When I talked to management, I didn’t feel they wanted any strict process or anything similar. On the contrary, they were open to listening. What I learned during my career is that people care about different things. Top management doesn’t care about the framework you work with; they fear being slower than the competition and becoming irrelevant. 

If you want to start a transformation, learn how to address points people care about.

Progress

As expected, we screwed up several times before we got it right. Many times we missed our goals and frustrated our stakeholders. But then we would have another cycle to rebuild our trust. Instead of having quarterly failures, we’d eventually face bi-weekly ones. The pain was tolerable, and the team had the “Reflection and Improvement” session to take action. Without talking about Scrum, we continue to become a stronger Scrum team, month after month.

Teams bonded with business stakeholders over respect and openness. We learned how to be transparent with each other, share our problems with business stakeholders, and continuously inspect and adapt. We focused on what mattered and learned to challenge what made little sense to us.

We moved from a Waterfall mindset to an Agile one without being dogmatic about Scrum or any other framework. Our discussion was directed to questions like:

• How could we reduce our release time?
• How could we identify meaningful problems to solve?
• How could we get closer with our stakeholders?
• How could we accelerate our learnings and adapt our actions?

Such questions broadened our perspectives and encouraged us to try different approaches. Eventually, we learned how to focus on outcomes instead of output. We escaped from the build trap and became an empowered team. It wasn’t easy, but it was possible.

“Scrum is more about behavior than it is about process.” - Gunther Verheyen

Final Thoughts

I used to be dogmatic about Scrum. I defended the framework with everything I had, and resistance was the main result I got. Focusing on behavioral changes and mental models is more important than discussing which framework is better or worse.

Teams excel when they learn how to create value faster.

Invest time in addressing what gets in the way of creating value instead of figuring out how to do better in Scrum or any other framework.