10 Reasons Why PMs ConflictWith Developers!
Grooming Sessions Are The WAR Grounds
A grooming session should be easy ideally. But what makes it tricky?
A Product manager or a Product owner or a Tech Product manager leads the grooming sessions. And while leading, there could be a lot of issues that a PM may run into…
1. Developers are passionate & emotional. They will RESPOND !
Developers are passionate and emotional too. After all, everyone is a human. They own the product as much as everyone else in the organization does. So whenever a PM puts forth a proposal during a grooming session or any other sessions, developers may or may not like it, and there could be an impromptu response back to you — which you may not immediately like. And that’s when a PM cannot take things too seriously. Absorb what they say, and move on as long as the proposed scope is not disturbed. As a PM you don't pick on everything to debate or argue or battle with, pick your battles.
Pick your battles, Save your goodwill for worse situations.
2. Tech lead and the other devs are not on the same page
As a PM you would most probably be talking to the tech lead only, and not with anyone else on the tech team. Sometimes the tech lead may not communicate your views to the tech team and in grooming sessions, you will be caught off-guard. You will enter the grooming sessions thinking the tech team would already know about this, but that’s not the case.
be ready to face that !
3. UI and API divide in tech stories
Sometimes PMs may think all UI and API can be divided into 2 different stories. And the devs may think that there are multiple APIs that bring data from the backend, and the stories breakup is not good.
Talk to the tech leads and get more details of the tech design before creating stories !
4. Don't understand the story well enough
Sometimes developers don’t tend to ask questions and assign story points with peer pressure or other reasons. And once the sprint begins, developers start asking very basic questions about the story. Answering the questions is fine, however, if some very basic questions are asked after the beginning of the sprint, it puts the whole task timeline at risk.
5. PM follows INVEST, devs may not understand it
Developers think that a particular feature is easy to implement, why are there so many stories for this. Why are there so many smaller stories, i will just take the whole task and knock it off. Or other thoughts similar to this.
On the other hand, PMs would think about following some story breakup principles such as INVEST and write stories accordingly. This could be a point of conflict and this can be resolved by good communication.
6. Less scope, Less cycle time (yayyy)
Developers can be OCD sometimes, we are all human. Developers want to finish everything at once, so they need not come back again for the feature. And the estimates the devs give can be super optimistic/aggressive. But if removing a few features can significantly reduce the release time, go ahead and reduce the scope. Get something out to the customers asap, and validate your product.
7. Less scope, Less cycle time (noooo)
Sometimes PMs want to cut down the scope by removing a few features, but those features might not really cut down the implementation time as much. on the contrary, if those were to be implemented at a later point in time, it will take a higher time to implement than if they were to be implemented right away.
8. Nitty gritty IS a waste of time
Sometimes developers might not like it if more nitty-gritty questions are asked and time is wasted on it. for example, some scenarios might be faced very rarely, but in grooming, we end up spending a lot of time, which is not great.
Personally, I would ignore it, and wouldn’t bother.
8. Nitty gritty IS NOT a waste of time
But some scenarios might be essential, but that can’t be left away for the developers to decide during the sprint.
I would INSIST the team, respectfully, to come up with an approach to solve the problem, but not to leave it ambiguous. If they still don't budge I would take the help of a QA or a 3rd person to help me out with this issue.
Use your good will in these situations
9. New designs or improvements on the spot will be proposed
Devs may propose new designs or solutions that were not planned before. Because — they might be easier to implement , or they would be better than the planned ones or may be 10 other reasons.
So how would you tackle these on the spot? you’re leading the discussion as well as taking on the spot decisions ! You can always defer the decision to later, no worries, just that the story would be pending for Definition of ready !
10. Provide a level playing field for all the teammates
Some team mates are good communicators, and some teammates are not. As a leader of the grooming session, you have to provide a level-playing field for all the devs.
You have to be unbiased towards everyone irrespective of the level of seniority and account for everyone’s opinions in writing the stories.
and there could be more reasons ….
There could be many reasons why conflicts or points of discussion arise between PMs and the tech team. But we should talk it out so:
- devs know what they have to develop
- and PMs get what they want for the customers