Hi everyone! I’ve been dealing with a very difficult to work with scrum master and really need some advice.
The dev team is not experienced in Agile, and we got a new scrum master (contractor). I was really excited and had very high expectations because I felt I could finally get the team going on agile. I’ve been working in agile for 5+ years so I have hands on experience and expected the SM to bring real life experience as well as agile process improvements to the team.
The challenge is I don’t think the SM has any on ground experience with agile. His implementation seems very conceptual and bookish, and he lacks critical thinking and thought leadership that a SM brings to the team. He doesn’t support letting me - the PO - join the Daily Stand-ups even as a passive listener. He holds retrospectives just cause and talks about same general stuff that the team has talked about in multiple other meetings. There’s no takeaway or action items from any of his meetings. He makes up random rules about creating stories/tasks and keeps changing them.
He claims to know JIRA but has ended up deleting stories by mistake; doesn’t know how to set up a board; doesn’t know the difference between workflow and swimlanes, and to top it all refuses to update the workflow to align with the organization’s process (we do agile in dev but QA follows waterfall due to strict monthly deployment schedule. It’s a very large organization that hasn’t moved to Agile completely.) He told me if it works for the team that’s good enough and it doesn’t need to work for the PO. It’s a challenge for me because I have no way to know if a story in JIRA in Done status is already in Production or still pending with QA.
How has he implemented agile on the team? He’s taught the team to mark the stories as Done even though they’ve not been tested - and have the QA on the scrum team create a separate task that is tracked on its own. He’s suggested that the dev create a separate task where they can put story points for an existing defect. There are just so many things and every time I challenge him on something his answer always is that the team should be able to do it that way if they want. FOR EVERYTHING. Now the team has started parroting the same thing to me.
I dialed into the daily scrum meeting today, but I don’t think they realized I was in it. I heard the SM joking with our tech lead about something I proposed to the team earlier - Scrumban. I proposed Scrumban as I think it could work better for us. Ngl, it was hurtful when I heard them laughing at my expense.
He’s built a good rapport with the team and since his title comes with authority the team thinks what he’s saying must be right. Sorry for the long rant, but I would really like a fresh perspective and some advice on how to deal with it.
You need to treat this as the urgent and serious issue it is.
I would sit down and have a very blunt and firm conversation with him about roles and responsibilities. You are his equal on this team and that needs to be made clear. Try to be polite, of course, but you need to come ready to advocate yourself. Talk about the overall problem - that you are an equal member of the team - and identify the specific items that need to change. I would come with proposed solutions for each problem you identify, but treat them as strawman suggestions and make clear that you are happy to work with the team on other possibilities.
I would actually escalate this problem to your manager immediately, before you have this conversation - having a scrum master (a contractor, no less) trying to undermine the authority of the product owner is completely unacceptable.
I would make a specific point to talk to about him and your manager about him making fun of your Scrumban proposal in front of the team. The fucking point of agile is to take feedback not only from your customers about your product, but also from your team about your process. This guy just blew up your psychological safety with your team. I’m so sorry you feel like people are making fun of you behind your back; that’s not the type of environment a scrum master should create.
If he’s a contractor from a agency I would honestly be wanting someone else, at this point.
Yes, I do feel that he has been undermining the credibility I had built with the team. We’ve had very clear and direct but polite conversations about R&R but after he acts like those discussions never happened and I’m back to square one.
Also, as I mentioned in my earlier comment, he’s a very charming person and given that the rest of the team has no experience on agile, the team sees him as the go to for agile so anything I bring up gets disregarded.
I would welcome any other thoughts you may have on this.
Manager. Straight to manager. Especially since you can point to past conversations where you’ve already attempted to resolve this problem.
Also write things down, it’s even easier if you can point to meeting notes that list the agreement and then an email where he backtracks on it two days later.
I’m a believer in working with people whenever possible but man, this guy sounds like a nightmare
It’s interesting that an organization that isn’t fully bought in to agile has a full-time scrum master. In my opinion that is a sign of a deeper rooted issue and it’ll be an uphill battle for you. Sounds like you guys need an agile coach, not a shit scrum master.
The scrum master position is not a position of authority. It is a position that should enable the team, coach the team, and remove impediments for the team.
As the PO, YOU are responsible for the backlog, the delivery of projects, and communicating back out to stakeholders. I suggest you escalate this problem to you manager as soon as possible or it is your ass on the line.
Lastly, I believe most conflicts can be resolved through communication. As other suggested, it would be worth while to sit the scrum master down and try to understand as well as communicate what your goals are and what you need from him and the team.
@FelipeRibeiro, Yes, we definitely need an agile coach for sure. Agree with you on the other points as well. I really wish communicating with him worked, and at this point escalating is the only option I see.
I’m sorry to hear about your challenges with the SM and the team. It sounds really rough.
Lots of good suggestions already about 1:1s with the SM.
My suggestion: focus on outcomes.
Why were you eager to get the team going on agile? What problems were you trying to solve for you and the team?
What do you need to communicate? What do you need to know to do your job? What does success look like for the team? What does success look like for you?
What is your rapport like with the team members, other than the SM?
From your description, it sounds like an us vs them or you vs them relationship. To me, this doesn’t sound like something sustainable.
Personally, when I decided to let go of the method and focus on outcomes, the team brought solutions that I couldn’t imagine.
@NathanEndicott, Thanks for your response. To answer your questions, before the SM we had some people from the dev team try to play the role of an SM with not so great success but the team was already working in sprints but our hope was getting an SM would help the team understand agile. I’m really hoping we can streamline the process and operate as a high efficiency team. I had a great relationship with the team before the SM joined and I feel he’s been chipping away at it slowly. And you’re absolutely right that’s it’s not sustainable and has become more of a me vs them problem and it’s especially difficult when the rest of the team doesn’t think there’s anything wrong.
@KaranTrivedi, But why do they need to understand agile if the work they do is already good enough? what benefit would come from being agile by the book?
Good question. It’s not about implementing agile by the book but rather implementing something that works for the overall product team - whether it be our own custom version of scrum, kanban or something else. It would help us plan the work, understand the velocity, plan for releases (training, communication, all that stuff that depends on the release timelines). Most importantly it would provide consistency and help us streamline the work - today for some stories QA is included in it, whereas for other stories there’s a separate QA task. Same thing for estimations - some stories the SM has them add the story point against that story; for other stories he has then create a separate task where they add the story points. there’s a lot of things like that.
I think the obvious answer is to communicate. Setup a 1:1 with him, lay out all your issues, and discuss a solution that works for both of you. Either that works or you can escalate your issues to one of your managers.
He sounds like either
A charismatic person that has been able to get through his career simply by making the right people like him while being bad at his actual job, or
He’s new to scrum/project management but was able to convince a hiring manager that his PSM certification means he has real experience and knowledge.
Also, it seems very weird he’d insist on an ambiguous definition of ‘done’. The simple answer there is to add a QA status between ‘in development’ and ‘done’. I don’t see a positive impact in leaving it out, only negative.
I’ve tried that before and it hasn’t worked. We would come to an agreement on something in the meeting and when the subject would come up again, he would go back to his original stance.
I think I’ll follow your advice and give it one last shot before escalating to the managers. And, you’re right he’s quite charming and luckily for him, he was interviewed by someone else than the person who leads Agile at the company.
As the Product Owner, you need to step up and Own The Product. It sounds like you may be too timid for the role. YOU are ultimately responsible for getting the product out the door.
Why are you letting him strong-arm you out of daily stand-ups? You need to be there, even if only as an observer.
You need to be giving the scrum master guidance / instructions and if he does not follow them, you need to escalate immediate to your manager.
As for marking untested stores as done, YOU as the PO is solely responsible for deciding when a story is done. He does not get to make that decision. Get a spine, man.
@AmyWalker, Yes, it can be difficult to regularly attend daily stand-ups given how we handle a hundred things at the same time, and I think my not being able to join these meetings became a level set.
The SM is an interesting person where I would ask him to do something and he would agree and I would walk away with the understanding that it would be done. However, it doesn’t actually get done and I would need to have the same discussion all over again. I don’t like pushing people too much especially when they’re new to the company/team since it takes a while to learn about the process and other stuff. But, it’s at the point where I have to escalate.
The challenge with Done is that though a definition of done has been defined, the SM doesn’t hold the team accountable to it and it varies widely. Because of the way the company process is, we could have a story complete and be considered Done, and then later it would go thru the waterfall QA Cycle, integration, so on and so forth and finally be deployed. The have been stories in different stages of above that are in Done status - all because the SM doesn’t think the workflow needs to be updated to meet the needs of the PO and as long as it works for the team it’s fine. He stated this yesterday and my reaction was WTF and triggered this post.
This is definitely getting escalated and needs to be resolved or the team will fail.
@KaranTrivedi, This is what I hate about scrum and the whole agile movement!
You as the PO are responsible and the company counts on it but there is no empowerment of the PO as a leader, and everything is handed off to the team to be “self-organized”.
And with the lack of incentives of being effective you end up with a team that would rather chill than being proactive about finishing tasks faster and better.
A lot of good responses in here that I won’t take time to repeat.
I encourage you to also frame this not as a me/them or even my role/their role thing, but more of a “The Team Needs Us” kind of thing. Make it all about the team’s success and growth in building good product(s).
Also, think of ways to spend more time with your team, individually, be it pairing, mobbing, testing, debugging, or just talking about “how things could be” with them. Take the team to lunch periodically (once we go to lunch with other humans again… some day). Bring them treats or send them unexpected yet wholesome memes on chat. Ask for regular ‘PO ride alongs’ and get to know who you’re working with and what they’re living with in the code every day.
One final note about being a PO. In that role, I just show up to the team’s standup when I have something I need to share or learn. No one can stop me from doing that. They also don’t need me every day and I’m not their scrum master, nor do I wish to be.
And, one final-final note about being a PO. Think of yourself as the Darth Vader of the Agile team. You possess the unique power of Force-choke-hold (aka backlog prioritization) over anything in flight or to be worked on by anyone else on the team. That’s pretty cool.
All great points and we had a great rapport pre-covid and pre-SM. The collaboration was great. I miss those days.
Backlog Prioritization is great for us but execution is lacking process wise. Another example of this is the team (including dev) spending time on looking at how to automate regression testing in the sprint. When I inquired the team on why they would do that instead of working on the sprint backlog, the response from the SM and then again parroted by the team was - We should be able to do it if we want. Our SM doesn’t even see this as a problem. Facepalm!
That’s interesting, about the SM directing the team. That’s a “flag on the play” for sure and one you should call out. Now, it has been my experience that a certain % of every sprint should go towards tech debt, maintenance, bug fixes, software updates, etc. But the lion’s share should go to PO-directed “roadmap” work. If they are meeting their sprint commitment and still have time/capacity to automate regression tests or other housekeeping, then that should be fine.
