Skip to main content

Divergence of opinion on leadership between PO and SM

Last post 01:05 am May 23, 2023 by Pierre Pienaar
5 replies
02:41 pm May 22, 2023

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?


05:19 pm May 22, 2023

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.


05:50 pm May 22, 2023

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.


08:50 pm May 22, 2023

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


12:22 am May 23, 2023

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.


01:05 am May 23, 2023

...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. 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.