Implementing Scrum Without Talking About Scrum
Don’t focus on a framework but on what you need to change
Don’t focus on a framework but on what you need to change
Originally published in GoRetro
During my journey, I’ve seen many Scrum implementations stall or die. Yet, I wouldn’t be able to 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 into questions like the following:
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 hindering teams from growing. That was my first assignment.
During the first two months, I observed how teams worked. One thing stood out; everything had an approval process. Stakeholders had to approve tickets in before developers could implement them, and Product Managers had to accept 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 by the end of each quarter, and unsurprisingly missing half of the stakeholders’ expectations.
I laid down what I discovered with my manager and suggested we would start changing how we work slowly. He asked me whether I wanted to implement a framework or not. I did envision using Scrum but understood the company was skeptical, so I decided to focus on the necessary changes and step by step, become more agile and less waterfall. So I told him I wanted to change how we work and speed up our release time. He gave me the green lights.
Focus on the Changes
I was surprised the team followed a process blindly but didn’t know why. I decided to have a brainstorming session with them and figure out how we could reduce the 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 gained confidence the team could start benefiting from Scrum, but I was aware of skepticism around the company. So I had to figure out how to do Scrum without talking about it. I asked the team how satisfied they were with their work mode, and everyone was 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 & Adjust: every day, the team gets together to review how confident they are 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 & improvement: before starting a new cycle, the team takes time to reflect on how satisfied they are with their current working mode, results, and collaboration. The goal is to define a max 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 related to Scrum events, but Scrum is more than just events. Yet, 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 would like to improve how we worked. Our current situation slowed us down, and I feared competition would be faster and we could soon become irrelevant. Within that, I got their attention.
The leadership team 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 like to remove quarterly plans and have 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 differently. 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 the leadership, 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 managers don’t care about the framework you work with, but 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 could get 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 faced bi-weekly ones. The pain was tolerable, and the team had the “Reflection and Improvement” session to take action. Without talking about Scrum, we become a stronger Scrum team every month.
Teams bonded with business stakeholders due to 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 increased our courage 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 to our stakeholders?
How could we accelerate our learning 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 all of my strength, and resistance was the result I mainly 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.
Did you like this post? What about becoming a Medium member to benefit from unlimited reading? By doing that, you also support writers like me and thousands of others 😊