Divergence of opinion on leadership between PO and SM
I’m the PO on a SaaS product.
I’ve been handed over a team from a previous PO; it consists of some on-site devs here in Italy and some India based devs; a new SM has been added on.
The PO at that company is fairly autonomous and while not having disciplinary authority can easily go back to top brass for any issues.
Lately the team has not been delivering stories in quality levels expected; so, we reduced the scope, went with multiple refinements and still, quality issues persist.
I can pinpoint it to third party devs being very timid and late to signal any trouble, or just offering insights. I’ve coached members to work on that. So I’ve tasked the SM to help us there too.
Still no progress.
The SM told me that I should use more stick than carrot (do this or else). Which from an SM surprised me. I’m actually thinking that this is a team traumatized by years of command and control and that somehow we should give breathing space; that this is a team as well that only knows top down orders. I despise very much command and control myself and think there has to be a better way.
SM thinks that only results count. I strongly disagree.
Other conclusion too is potentially a cultural thing where proactiveness does not come easy to that one set of Indian developers, some exceptions aside.
Do you have any advice?
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.
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.