Is Scrum Trapping Developers? Or It’s Just a Blame Game?
Know why developers feel trapped by Scrum and how to adapt to the situation
Know why developers feel trapped by Scrum and how to adapt to the situation
“Shit! We have a refinement session today, and I am still behind my tasks.”
“Let’s skip the retrospective today, then we can deliver the features.”
“I have too many meetings, and no time to focus on coding!”
Are you familiar with any of these complaints? I’ve heard such objections often from developers, which happens when they think Scrum is getting in the way of getting things done. My question is, would Scrum be the real problem?
The wrong usage of Scrum can trap developers and make their lives miserable. Yet, you can find a way out of this tragic situation if you are willing to overcome some hurdles.
You can either bow to the status quo and complain every day or be the hero of your story and push for a change.
During this post, I will share why many developers feel trapped by Scrum and what you can do to change such a terrible situation. I hope you can benefit from it.
Where Does The Problem Begin?
The digital industry is still relatively young; it was only in 1948 when Tom Kilburn wrote the first line of code ever. And since then, we have been searching for ways to benefit from software development. I believe we made pretty significant progress on that as nowadays, we do almost everything digitally.
Despite our achievements with the digital world, we still suck on embracing the unknown.
Developing software is not like building a bridge. You cannot calculate everything beforehand, define the materials, the labor needed, create a project, and then implement it. Civil engineering is complicated but predictable, while software development is complex and unpredictable. Yet, companies still focus on creating software with a mindset borrowed from civil engineering.
Developers are creative people; they love receiving problems to solve instead of tasks to implement. However, top management tends to see them as builders who put bricks on the wall instead of defining what makes sense to build to overcome particular challenges.
When management has false expectations from developers, the results will be frustrating no matter the framework you use. Yet, you can turn the game around if you are brave enough.
What Makes Developers Feel Trapped With Scrum?
I know many developers who despise Scrum. They feel Scrum gets in the way instead of helping them get things done. This faulty perception often happens due to bad experiences with the framework. I don’t blame developers for such perceptions because I frequently contributed to them.
Most of the issues I know happen due to weak product management.
Often, someone becomes the Product Owner without being ready for it. That was my case ten years ago; I evolved into a Product Owner without any product management skills. I thought Scrum was a process focused on delivery, and I fully misused the framework.
Here are some signs you are locking developers into a trap instead of unleashing their potential:
During the refinement sessions, you talk about solutions to implement, requirements to fulfill, technical challenges, and estimates. Meanwhile, the underlying problem isn’t part of any discussion because someone previously defined the solution, and you expect developers to deliver solutions instead of solving problems.
Sprint Planning is the most mechanical meeting you have. During the event, you understand the team’s capacity, look at the velocity, agree on the tasks that fit the next interaction, and start the Sprint. Yet, you don’t talk about the Sprint Goal because the tasks you selected don’t relate to each other, so setting a goal is pointless.
Every day you attend the Daily Scrum, you look at the burndown chart and pressure the team when the line seems flat. What matters for you is having a beautiful burndown chart. Each developer talks about their “Sprint” as everyone has a different goal. They neither find opportunities to support each other nor have the time for that as the board is full of tasks to implement.
Close to the Sprint Review, developers are desperate and beg you to skip the refinement because they still have a lot on their plate, and you agree to that. Developers make compromises to deliver tasks, tech debt increases, and you as the Product Owner accept that and do not address the issue.
These are some examples of poor usage of the Scrum framework. Developers will have their hands tied and eventually disengage with the product and inevitably leave the company whenever you fall into any of these pitfalls. If you are the Product Owner in a situation like this, you have a choice to make:
You can either become a victim to the outside world and do nothing or become a hero to your story and challenge the status quo.
It’s easy to fall into the victim mode because the corporate world may get in the way. Top management throws roadmaps over the fence with unachievable deadlines; stakeholders push for more and more features, and you receive pressure from all layers of the organization. The scenario is unfavorable for you, but becoming a victim is no option to succeed.
Unleashing Developers’ Potential
I know it’s incredibly challenging being a Product Owner in a dysfunctional environment. But I know it’s even more disappointing working forty hours a week and seeing no meaningful result from your work. Once you accept the challenge of being a Product Owner, be ready to battle with the anti-patterns on your way. Here are some attitudes that can help you:
Focus on less: ensure developers can work as a team instead of creating micro-teams inside the Scrum Team. Focus on doing less; that will leave space for creativity and engagement. If you’re unable to set a Sprint Goal, you’re missing the point.
Read between the lines: even when you receive highly prescriptive roadmaps, understand the goal behind each item. Focus on reaching the goal instead of matching a set of requirements. Don’t try convincing stakeholders of other solutions; prove with results instead of arguments.
Address issues with developers: when you realize developers are creating tech debt because you are pressuring them, talk openly and find a way of solving it. If the refinement sessions drain your energy because developers want to know every minor detail, it’s a sign of lack of trust. Probably they are afraid of failing and being held accountable for that. Until you can address conflicts with developers, the team will be dysfunctional.
Set goals: you are the Product Owner, you’ve got to take a driving position, don’t be passive. Understand the most critical problem of the moment, set a Product Goal, and ensure stakeholders understand its importance. Whatever doesn’t help achieve the Product Goal is irrelevant for the moment, and you shouldn’t waste time with it.
Empower developers: don’t try micro-managing developers by showing up on all Daily Scrums and pressuring them for progress. Empower them to make decisions, and give them the room to be creative. Trust is the foundation of any high-performing team. In a solid Scrum Teams, developers are self-managing and bring all required skills to create value for the business and end-users.
These items help me ensure developers have room to do their best. I know you may face resistance in your organization to implement such points. No worries, that’s normal. Until now, I face the same issues. Yet, I know what happens if I don’t take a stand and do my job the way I should.
Don’t let the outside world defines how you do your work. You’re the Product Owner, and you should do what is right and not what you’re told to do.
Final Thoughts
Scrum often gets the blame when developers feel trapped because that’s the framework they work with. However, most of the time, Scrum isn’t the root cause of the problem but the company’s mindset. When the company focuses on output or pleasing stakeholders, developers will end up in a trap no matter the framework they implement.
From my perception, this situation might be attributable to the company, but it cannot be misattributed to Scrum. A simple question might reveal the truth: Would teams feeling trapped be any less trapped if they would opt out of whatever they call Scrum?
The real Scrum empowers developers instead of trapping them. It’s up to us to fight the anti-patterns and help Scrum Teams deliver real value instead of falling short into a vicious circle, where providing features to please stakeholders is the ultimate goal.
Did you like this post? What about becoming a Medium member to benefit from unlimed reading? By doing that, you can support writers like me and thousands of others 😊
Thanks, Sjoerd Nijland, and Willem-Jan Ageling for your review.