Engineering Resistance to Change
Hi there Everyone,
I recently started a new job as a PO (3 years prior PO experience), but given the current organization of our engineering teams it doesn't seem like a PO fits into the current model.
A few challenges that I'm seeing include:
- Engineering Team Leads essentially drive any roadmap, priority and capacity planning
- The current team structure has an ungodly amount of cross-team dependencies
- The PM that I am designated to work with consistently has our roadmap items pushed down the road due to competing priorities with another PMs (We share Engineering resources, not ideal)
- Other Product teams in my organization have a more traditional 1:1 model where each PM/PO has a dedicated scrum team(s) and have seen success with this structure
There seems to be a good amount of politics in play from Engineering's Leadership where they essentially don't want to be told how to structure their development teams despite their awareness and acknowledgement of our challenges and inefficiencies. I took an initial approach of suggesting different team structures with no luck and other folks in Product have fallen on that sword before me.
I've noticed in this organization that folks really value stories of how we got here and why we may need change, reinforced with supporting data.
So my questions are:
- Have any of you ever dealt with this kind of resistance from Engineering teams before and what tactics have you used to overcome this challenge?
- Are there any data models or visualizations that you could recommend which may help tell the story of why we should consider a team re-structure? (Our jira data is kind of messy given the cross-team dependencies and constant hand-off of work so its been a struggle to get reliable/consistent data regarding our performance)
Any insight is appreciated and I thank you in advance!
I recently started a new job as a PO (3 years prior PO experience), but given the current organization of our engineering teams it doesn't seem like a PO fits into the current model.
When you follow the money, where does it lead in terms of accountability for product value? If value isn't delivered, who carries the can?
If this accountability doesn't lie with you, maybe it lies with someone else right now, and perhaps that obfuscation is part of the problem.
1. Have any of you ever dealt with this kind of resistance from Engineering teams before and what tactics have you used to overcome this challenge?
Oh yes, though resistance is everywhere, it is not limited to Engineering teams. All organisations have politics, habits, etc. To overcome resistance is understanding what is causing the resistance. 99% of the time it is you (yourself). Getting approval to introduce SCRUM means you have to talk and analyse how things are done currently, and where and how SCRUM can help. Throwing away everything already in place (which lots of times the outcome of years of hands on experience) is most of times uneffective and unefficient, and if you do, you will reinvent the wheel. You should think about how to best suit this team and organisation. Holding up the holy handbook is never a good idea, but could if you have leadership backup. But actually with scrum the team is the boss, not higher leadership. So, tactics to use IMO: interview, analyse, keep low in the beginning and get a good grip on how things currently work, let that work on your brain for a month or 2, and then analyse and start a dialogue (which is a two-way symmetrical talk).
2. Are there any data models or visualizations that you could recommend which may help tell the story of why we should consider a team re-structure? (Our jira data is kind of messy given the cross-team dependencies and constant hand-off of work so its been a struggle to get reliable/consistent data regarding our performance)
Well, there is so much written in management literature. I don't know where to start. And they all have their flaws. Best approach IMO is to keep practical and very clear, and keep the dialogue open. Don't dare to think you have the answers, as always there are caveats.
Ehm, next to some other textual changes I d ene to make, I mean ineffective and inefficient ;)
The thing is, IMO, organizations try to map Scrum to the existing organization, rather than the other way around. Why do we think Scrum could prove a useful framework for us? What should we change in the existing organization to make it effective? What kind of data can we gather to see if we advance or not? Time to market, customer retention, new customers, employee happiness etc provide wonderful feedback to see the current state of things and whether that meets our expectations or not.