Agile-scrum is a fairly rigid set or practices and patterns that work well together. I hear red flags when you say you are "managing the project in an Agile-Scrum way."
You should avoid cherry picking Scrum practices, especially on newly forming scrum teams or with organizations that have little Agile experience. Scrum works best as a complete system.
Sounds kind of tangential, but the root cause of your problems (if my assumptions are correct) could stem from the issue that you do not have formal product owner, scrum master, and team R&R defined on your Scrum team.
Scrum teams serve many stakeholders, but they are represented by 1 product owner. This product owner sets the priority of WHEN/WHAT to do and is responsible for answering the WHY question. The PO may also makes some decisions on WHAT UI implementations look like because the PO is often closest to the user. (UX and Agile is a whole different topic with its nuances, however).
The PO works with stakeholders to negotiate priorities and manage expectations. Stakeholders don't provide designs or implementation details and the PO and Scrum master work to coach technically capable stakeholders out of these behaviors.
The team determines the HOW and WHO does it of everything else. Stakeholder or PO doesn't like HOW a feature was implemented in the code; too bad. The team owns the quality and implementation of the features, and is accountable for delivering to standards they explicitly share with PO and any interested stakeholders.
That's how Agile teams stay empowered and bought into the work they do.
The scrum master is the servant leader on the team. They don't ever define the HOW, WHAT, WHY, WHEN, or WHO of the actual work items, but they coach the team on improving their delivery processes, product quality, and eventually help the team understand how all the scrum practices work together. The SM also facilities ceremonies like the stand-up, planning, review and retrospective. SM's have no authority to tell anyone on the team to do anything, but generally have worked in a developer, QA, or PO/PM capacity previously. They are sounding blocks and facilitators for the team to continuously improve.