Divergence of opinion on leadership between PO and SM

The following is my opinion and only that.  I do not intend to offend anyone but can't guarantee that I won't.

So I’ve tasked the SM to help us there too

For someone that says they do not like command-control, that sounds opposite to your statement. 

The situation you describes sounds very much like a company that uses Scrum terms but does not appreciate or utilize the Scrum framework.  Unfortunately, this is very common.  I believe you are on the right track about the team's previous experience.  But it could also be the current experience.  Since they are employed by a third party, it is very likely that they have a different corporate culture or structure that is opposed to your philosophy.  In fact, it could be contractual. This is one of the biggest difficulties of outsourcing that I have dealt with. 

The terms Product Owner, Scrum Master and Developers in the Scrum Guide are not job descriptions or job titles.  They each refer to a different set of responsibilities that are needed in order for the Scrum framework be successful.  As such, think of them more as roles than titles.  I would be surprised if your job description for Product Owner was only the responsibilities stated in the Scrum Guide. I'm sure that there are other "duties, responsibilities, and requirements" listed.  The same holds true for your Scrum Master.  Unfortunately, a large majority of the Scrum Master job descriptions I have seen do not even list the responsibilities stated in the Scrum Guide and read very much like the Project Manager job descriptions that are used. 

I applaud your desires and hope that you never change your perspective.  I consider myself a servant-leader and feel that the best results occur when the people closest to the work are allowed to make decisions about how to do that work. But trying to influence changes in that direction can be difficult and never seem to be quick.  Having more than one business entity involved makes it even more difficult. 

My advice is to keep doing what you are doing but not in a "I've tasked" manner.  Instead, lead by example.  Suggest or ask for help rather than task.  Mention to the people doing the work that you are worried about something and ask them if they share the concern.  It could be that you are not aware that they are trying to mitigate the same concerns. As a Member of the Scrum Team, you are allowed to bring up topics at the Sprint Review.  Instead of bringing up the topic of "our quality is going down" mention that you are feel there is an apparent decline in quality and ask if anyone else shares the concerns.  Ask them if they can change your perspective by sharing information on things that they do of which you might not be aware.  This is how thing such as organization directives can come to light.  You mentioned that you have reduced scope and increased refinement but has anything been evaluated on whether the way that refinement is done is working?  How was the reduction of scope done and how is scope defined?  If you are using Story Points as the measure, that can easily be "gamed" by reducing the estimates but not reducing the work required. 

Good luck.  This is not an easy situation to deal with.  I have been in similar situations and I have yet to find a quick way out of it.  But with some patience and attention, it can become less concerning. It can also lead to change.  But as with all things agile, that change will be incremental supported by empirical practice of discovery and adaption.

Thanks.

I somewhat knew that the wording of me tasking the SM do to something would raise some doubts, let me say that I rather mentioned this as an issue to tackle. He went on with retros and private interviews I did not meddle with in any case.

The issue is indeed with the third party aspect, first, because that likely plays on the mind of devs - I treat them as equal, congratulate a lot and so forth, give credit in the reviews, but at the end they are not “company staff”.

But, and second point here, there is a cultural aspect on top. I know having talked in detail that there’s local management in behind in India that asks for precise to the minute reports. So, all in all like you say, they do have command and control at home.

Final nail: I want obviously to help and develop every single person, but the team and budget right now is pushed on me. So it’s not like I could even in extreme cases do changes in personnel. Which is anyway my last resort option after all else has been tried.

To hear a SM conclude that command and control is okay makes me sad. Perhaps it is more an acceptance of the situation but it is honestly not in the spirit of common work.

So I’ve resorted to consider that the SM whom I like will stay within short and self set boundaries and that I will have to set old school reeking deliverables in a classical way, while I’m behind the scenes working individually with everybody to achieve a mid term improvement.

Frankly given the situation we are in an Engineering Manager + Team situation and I don’t need a SM for that given what has been said. Sadly, I’d say.

In my perspective, this is a typical instance of "Zombi scrum," which occurs when a team rigidly adheres to Scrum events and documents without having any concept of how Scrum should truly operate or be set up. beginning with mechanically transferring team leader authority to the scrum master.

The best course of action would be to ask an organization if they truly want to implement Scrum; if not, run a god-old waterfall project (prince2 is a great methodology to attempt); then, if yes, begin coaching the teams and organization about Scrum.

Which is Scrum masters job, not a Product owners one

I know having talked in detail that there’s local management in behind in India that asks for precise to the minute reports. 

Have you found out who will create a sense of urgency for this to stop?

It's these behaviours which must first change, otherwise people will surely reflect such dysfunction back upwards.

...this is a team traumatized by years of command and control...

This is likely or at least part of the problem. I would also commend you on taking this view. Normally it is the SM that tries to remove command and control management, and not trying to install it. 

Good points have already been made above. As mentioned there is no easy solution. It will take time. In my opinion this is the first thing to except, it is going to be a slow process. Establish what your current "baseline" delivery is and develop from there. Don't try to jump where you want to be, establish where you currently are and then build from there. 

Then truly empower the team. Does the team do their own planning? Is the team confident in saying we cannot take on more items this sprint? Does the team pull from the backlog themselves? Does the team have enough information to define a realistic sprint goal themselves? Realistic very important here. 

Not knowing what the quality issues are, a few general thoughts. Increase manual testing and install testing culture that everything should be tested. The team should take ownership of testing, not a separate QA team. Increase Nunits at about every code change. Longer term, increase automated testing and increase code coverage of automated tests. Avoid late changes before a release, rather reduce scope. Late changes are often badly tested and rushed, causing almost always problems.

Expect variance (maybe setbacks) on some sprints. Progress is not going to be upward all the time.