Otherwise, here's a couple of notes freely given with no claim to excellence except that I've worked with successful scrum teams and unsuccessful ones:
* The 'business' is everything. All code is liability. Code that can't do things the business wants to do and hinders those things is a particular cost to the business. Product Owners who don't understand that "refactoring code to make it extensible before extending it" is the cost of doing business just have to learn that lesson. If they won't, let them go. Bad ones are a dime a dozen so you can always hire another clueless one if you want. It's like having a loan that you're paying lots of interest on. Saying "We can't spend time refinancing that. We have to go earn money." doesn't make sense as some absolute truth.
* Engineering is not in contrast to the business side. There is no need to represent engineering because the product owner is supposed to be able to understand all inputs into the program. If engineering is slowed down by the lack of dealing with some technical debt that's not some engineering problem divorced from the business. It's the business. This requires reaching across from the engineering side, being clear when things aren't going well, not starting on ridiculously long "refactoring" projects that are just lateral changes, and being clear what the expected outcome of any tech debt relief is. Avoid "feels cleaner", "is more elegant", "is more extensible". Talk in terms of outcomes: faster response to outages, the ability to add things like X (requires you to understand the product some, which is something an engineer should do), less time spent debugging issues. If trivially measurable, measure and demonstrate improvement. Builds trust.
* I'm not too convinced "Scrum Master" needs to be a solo job for anyone. The incentives are skewed. If you have a team of ideal people and they all pick up on the principles and you correct the bad patterns they have, they won't need you. The job inherently obsoletes itself which means the median person taking the role will entrench themselves in process to keep themselves relevant.
* 20 people at daily standup makes no sense. It's 10 minutes or 15 or whatever so you have 30 s to describe something. It isn't so much the time, though, but the fact that there are too many people here together in the room. It makes no sense. Find smaller units of organization. Conway's law presents but the alternative is much worse.