Self-organising teams
We are using Agile/Scrum, but best description is likely a more hybrid model. That said, one area of difficulty is in self-organising of teams. Product Owners and Technical Leads are prescribing to the teams. The teams are not pushing back and are resigned to the fact that the plan on day one of the sprint can be replaced by urgent issues from the PO on day two.
The above is a problem but consider a specific scenario with the above in mind. The team is doing a feature and with the PO has elaborated the Epic into various stories. However mid-sprint the Tech Leads wants one of the stories to be altered. The new approach is more in line with later coding standards in the company, but the way the team wanted to do it, is still used in many instances. (Having a setting in a .config file, rather than the better way of having the setting user configurable on a user page.)
One possibility is with incremental delivery in mind, the quicker solution first and replaced later. There is resistance from the Tech Leads to redo work in a better way in a subsequent sprint. The interactions with Tech Leads and PO's are good and amiable; that is not a problem. The question is more around the underlying initiative to get the teams self-organising to increase motivation
I am interested how others would approach this situation
You haven't mentioned the Sprint Goal. Who is making that commitment, and do these changes help or hinder it?
We are using Agile/Scrum, but best description is likely a more hybrid model.
Based upon your description I would argue that you have a hybrid model of waterfall where requirements are pushed down to the individual contributors that are doing the work. Your Tech Leads are not allowing the Developers to create their own plans and solutions.
Having agility to adapt to changes does not mean that there will be less work. It means that you can deliver a workable solution in order to get feedback quickly that can be fed into the process for future updates. In the case you described, the Developers have a way to provide a workable solution. Then gain feedback from the stakeholders on the solution. What if the stakeholders prefer the .config file option more than the user page? What if the options chosen for the configuration are not in line with what the stakeholders actually want? Deliver something that works, inspect it with the stakeholders, then adapt if necessary.
On the Sprint Goal, we find it difficult to define, but comes from the PO. We do a mixture of Support and Feature work, and the goal can vary between getting Support fixes out or delivering a new Feature.
Thanks for sharing great information.