As I started my journey with the Scrum framework in the Product Owner role, I have come across this push-back many times. And to me, it was difficult to have this type of interaction all the time, with the developers I worked with.
At one point it got overwhelming, and I kept wondering what I do wrong. I even thought they are doing this on purpose. But then I understood there are some reasons behind this behavior, mostly generated by my way of doing things. In the end, we tried together to find out what can we do for better collaboration.
Keep in mind that push-back is not always bad. It gives you the opportunity to see other points of view. So below you’ll see what kind of push-back I encountered and how I handled it.
What does developers’ push-back look like?
Lack of commitment
I’ve heard many times excuses from developers to avoid building a feature. Sometimes because it was too difficult, and they didn’t want to commit. Once they heard what the feature was, they didn’t try to understand what I was asking for. So they had their own wrong image of what the feature was.
This is an example of pushback that is not productive at all, especially when there is no actual impediment that we cannot remove. The entire Scrum Team should work together to understand where this is coming from before taking any further actions.
Code refactoring before implementing additional features
I know many POs are hesitant when they hear developers saying they should take some time for refactoring parts of the code. We might think there’s no new value added if developers’ work doesn’t translate into additional features to release to the public. It’s not entirely true.
Too much technical debt makes applications perform poorly. And some re-factorization is beneficial sometimes. So start giving your developers some credit when they talk about it.
Gold plating
Gold plating means adding additional functionality that is outside the scope. Developers are doing this with good intentions, hoping that will make the client happy. But the downside is that the client might not accept it. This might also be a way of saying they don’t feel valued or that the Product Owner doesn’t consider their opinions.
Why does it happen?
It’s difficult to understand that with Scrum we build features incrementally
Developers don’t like to work on features that take too much to finish, especially when there are a lot of technical challenges. They think complexly about the solutions instead of solving the technical challenges in the simplest way possible. What’s difficult for some of them to understand is that with Scrum, we build features incrementally. And that we don’t need to deliver all the functionality at once.
Some of them might come from Waterfall environments where things are different and they release the entire functionality at the end. Others, even if Scrum is not new to them, they find it difficult to release functionality that is not complete. And they feel like they’ve done half of the job.
Developers don’t understand the scope
All user stories should come with context. No matter how well described are the requirements, the developers must understand the problem that the feature will solve. So Product Owners have to be well prepared to talk about the feature.
However, this doesn’t mean POs will have an answer on the spot for all their questions. Sometimes they need time to think about the best answer and go back with it at a later time. POs cannot possibly know everything, but that’s why you work together as a team.
The Product Owner is bringing to the table the “how” instead of the “why”
One mistake I did as a Product Owner was to split and order all the features into user stories involving none of the developers. Like that wasn’t enough, my expectation was for them to deliver everything in that exact order, as I planned. Of course, this is wrong for at least two reasons:
- Developers get frustrated because someone else, sometimes with no technical expertise, decides how they should do the work
- It demotivates them because they feel they have no contribution
In these cases, developers can consider their opinion to be not important and they have to execute whatever task they receive. They like being involved and seeing their opinions matter in decisions that we make.
They want to get rid of as much technical debt as possible
We shouldn’t be comfortable with technical debt and allow it to grow. I’ve always welcomed this type of push-back because it helped us have a qualitative product on the market.
But besides that, getting rid of technical debt will minimize the amount of work a developer will invest into implementing a feature. When the code is cleaner, and dependencies reduced to a minimum, they’ll automatically work easier in that part of the code. So features will get implemented and tested faster.
How to deal with developers’ pushback?
Simplify the user stories
To help the developers, a Product Owner should keep the stories as simple as possible. By doing so, you remove the custom of making assumptions. Emphasize the fact that what’s in that story is the only thing you need at that moment and nothing more. The developers should not start building functionality in advance or prepare new structures in the DB for what might come 2 months from now. Things might change and all the work will be worth nothing.
They should focus on delivering simple working functionality, that can be at some point enhanced. But what we want in the first place, is to send out to the market something simple, and see if it’s worth developing it further.
Involve developers as early as possible when you create the user stories
I encourage every Product Owner I work with to do one thing. Have a user story-writing session with your developers and make it a joint effort. By asking questions, they can help identify pieces that are missing from your initial description.
You can do this in one of the Backlog Refinement sessions or even have a separate discussion. I know it may sound like taking them away from the sprint work, but in the long term, it will bring more benefits. The developers will be more aware of what they have to do, they will feel accountable and they will also simplify your work.
Be open to code refactoring
Code refactoring can bring many benefits
- Easier code maintenance
- Simplified code updates
- Reduced complexity
- Scalability
However, it should be done carefully. By this, I mean the same as any other feature, we should do it incrementally. I don’t recommend spending a couple of sprints only on refactoring pieces of code. Instead, with each sprint, you can refactor small parts of the areas where the developers are working at that moment.
What happens if you don’t deal with the push-back?
If you don’t deal with developers’ push-back, two things will happen:
- They will continue doing it, and this will harm the relationship between you and them. It’s difficult for a Product Owner to see the people who are bringing their ideas to life, are doing it with no enthusiasm.
- If it happens constantly, it means that something needs to be improved. And avoiding dealing with it won’t allow you to improve your collaboration. Furthermore, it will damage productivity.
So as you can see, there’s no secret ingredient to make developers agree with everything you say. You have to understand where this is coming from and together work on finding a solution.
You can leave a comment below if you want to share some of the push-backs you’ve encountered.
