This is a very broad question, for which this long answer is just the iceberg tip.
Divide and conquer
one thing which always failed is that we didn't define who has the final say, who can actually decide what to do and how.
The agile answer to this is that everyone decides together. But this often fails miserably for the following reasons:
There is too much of everyone and everything. In other words, the decision process involves too many people, with highly diverse stakes and wishes, with too many things of a highly diverse nature to decide on.
To give one example, you sit in a team leader meeting and have to choose either of these two: A UX improvement that was requested by many users for 6 months now, vs. a new feature that the CEO wants to develop because it can add revenue. Which has the priority? Well, this is like comparing apples to bananas. The former is customer-centric, the latter is growth.
This is an issue sometimes termed cross-prioritisation - when you try to decide on the priority between two things that are clearly little related.
Now consider the following question: Is it better for a country to have extra 1500 beds in hospitals, or that the military has 2 more drones? Ask the prime minister and he'll say - I don't waste my time making such comparisons, we define the health and defence budget and each department does as it finds fit.
I guess the solution becomes clear in the last example - by employing divide-and-conquer approach, decisions are easier and upper management shall mainly be concerned with how to slice the cake.
Here's a practical real-world example:
- The bad - In a certain organisational structure, I was once sitting in product management meetings and having to fight for any UX issue to get dealt with, but hardly anything was done because of many other forces that thought there are better things to do.
- The good - Then, we changed the system so UX was an agile project on its own - myself as the designer and two other developers. This small team (together with the PO, when he could make it) was making together decisions as to what's most important. The result? UX has improved much faster, users were happy, even the CEO was happy as positive feedback did pour in.
Also, now the PO had to guide us on UX issues alone, so he wasn't torn between UX, new features, bug fixes, etc.
Agile as a loan shark
Often what these roles prfioritize is on-time, and on-budget delivery
Agile is a great method, but the reality is that many (if not most) organisations only follow the bits they like about it and brush off the bits they don't. Both personal experience and research demonstrates this. In fact, I have personally only encountered one team that follows agile by the word and maximises its potential and it's Google's Angular team.
The rest utilise it in what to me is too often 'buy now pay later' fashion - compromising research, design (UX and software), testing, QA, code quality only for the sake of time-to-market.
Luckily, I believe the awareness of this systematic failure is growing - too many startups find themselves 4 years down the line chasing bugs and with non-competitive development times. The word spreads, bottom-up.
Product owners are good for you
It's the product owners that work with the teams, and actually, to some extent design how the system should work. POs are the customer, or the proxy for the customer (i.e. purchaser). They are the ones that have decision power on how things should look...when UX practices affect the scope, then definitely it's the PO who should decide.
I totally agree when it comes to what to do next. My experience with POs was always a positive one - at the end of the day, they know and wish the best for real users. In fact, my life was much easier because there was this real user with vast knowledge of the domain and other users who could guide us where the value is instead of us making assuming.
Defeatist attitudes and Cost of Delay
we have a table component which have really bad behaviour, and we all agree on that, but we know that if we should change it, it's a huge amount of work... We have done some fixes, so you can live with it, it's still not nice but you can work with it. That's how it needs to be right now.
Well, this may well be a valid argument. If development cost is high compared to value added, it is perfectly fine for the PO to pick another task with a better ratio.
But I suspect this statement smells as if technical debt is behind it, in which case this is like you coming to the doctor complaining about various odd symptoms and the doctor says: "You eat unhealthy, you don't exercise, you drink alcohol every day, you smoke 40 cigarettes a day, your cholesterol is high, your sugar is high, you should really change your diet and lifestyle!" and you go "Nah... too much effort".
Another concept that may come to mind here is the cost of delay as thoroughly argued by Reinertsen (A book, you may wish to read, albeit not to be taken as biblical). In simple terms, many make decisions based on development cost vs. a rational customer value. But first, customers aren't rational (specifically with UX where emotions are hard to quantify); more importantly - it is about what you lose during the product lifetime that you should compare to development cost. So if you ain't going to fix it in the next 5 years would the cost of having a poor table component still be lower than the development cost for improving it?
Businesses find it really hard to change internal processes and old habits.
One solution is to introduce a role, or a team, whose sole responsibility is to ensure quality and improve things. By definition such entity is autonomous and completely oblivious to any time/budget constraints. This practice has proven extremely beneficial for some businesses.
The key concept here is autonomy. Now while such concept may seem a bit extreme (particularly in small businesses) a variation of it is instead of having an autonomous entity, either individuals or teams get a degree of autonomy. Word has it that Google allows employees to spend 10% of their time on whatever they wish to, so long the work is somehow related to its products. The concept of workcells that get a degree of autonomy is also fairly common.
So in relation to your question - sometimes individuals or small teams given the right to call the shots on an autonomous basis is highly beneficial.