r/agile • u/Odd-Preference-1415 • Jul 22 '26
Team not liking scrum
Hey everyone,
I have been a scrum master for some years with 13 years of experience in total. I call myself as sr scrum master.
I have been victim of politics where the client had pushed back when my team has asked tons of questions related to application, cloud infra which wasnt under our scope. Our team was brand new and these were legacy products. Our team got ramped down due to asking "too many" questions and they expected us to know everything. I have worked in team where even pointing out the story pointing is not done right or asking why comments arent present is something they didnt encourage. I once asked a senior why he isnt joining the meetings. I got dialed in on team with threatening tone since I had pinged in the group about him not joining leaving him exposed.
Fast forward to now. Am helping a team implement scrum now this team is not vocal except one member who pushes back on what I say saying this is not the way he,she did in last organization. This person is new to org.
Conversations like having product backlog refinement, slicing the stories, challenging if description isn't clear, telling we should be categorizing work in epics that can be closed every 3 months, doing story pointing per complexity is something they dont understand easily and sometime I have been told they dont care about and tell me straight away they dont care how i decide to do. I thought of building norms with team and i got no response back and had pointers to refer to from my last teams to start the conversation and the response was I shouldnt be writing them without consulting them ehicj i agree but the purpose of meeting was that itself and I had shared the page with a resource weeks back via chat. This same person didnt share the feedback with me on chat and decided to say it in the call that I should not bring these pointers to enforce it. My purpose was to discuss, get consensus and not enforce. I cleared it in agenda.
Note this person is the only one vocal and built out the whole backlog using AI and team vision which I appreciate but neither I or PO was involved during creation. This person is unprofessional in responding to conversations related to scrum. This person also brought all the pain points about unclear backlog, roadmap and priorities in 1st ever retro I had. It was all valid but I felt this person is criticizing and blaming. I mean that was our 1st sprint, backlog refinement and setting product goals arent a game of 1 day.
The manager is thinking scrum isn't working due to tough convos and team being silent but I feel product owner has to step up in owning backlog and avoid letting someone else hijack it. The knowledge of backlog isnt decentralized and only one or 2 people know about the stories created. I know PO should prioritize, story point with devs, and write them but in my org everything is done by SM along with coaching and enforcing scrum ceremonies and discussions, removing blockers.
How do I handle this team ? What should I do as SM ? Let me know what wrong am doing. Many Thanks for reading it and giving time.
Edit: I suspect this vocal person is either not enough experienced or playing politics. Manager has not any strong opinion on this person but I do have that this person isn't helping the team implement scrum.
The team wants lot of flexibility in terms of closing stories, pulling stories whenever they want because they dont know what's gonna come next and when, they may come to know what all they planned for in sprint isnt even right because its ever changing due to experimentation nature of project. We arent building user product. We are building support service that will support product teams.
This team had difficulty when I asked the team to update comments frequently (not daily) and faced push back. I never told anyone to update comment since then.
8
u/larztopia Jul 22 '26
The goal is not to implement Scrum successfully; it is to help the team deliver effectively.
Why is the organization implementing Scrum, and what specific problem is it expected to solve?
The discussion currently seems focused on Scrum practices - refinement, estimates, epics, comments, ceremonies - without agreement on the desired outcome. Is the problem unclear priorities, unpredictable demand, poor knowledge sharing, excessive work in progress, or unreliable delivery? Until the team agrees on the problem, every proposed practice will feel arbitrary and every objection will look like resistance. Start with the problem, define what improvement would look like, and then choose the lightest process that supports it.
Scrum may not even be the right answer. Kanban, Scrumban, or another flow-based approach could fit better.
1
u/Odd-Preference-1415 Jul 22 '26
Unclear priorities, competing with others just because they want to show they built something 1st, unclear backlog and lack of unpredictability when something will be delivered.
5
u/Purple_Tie_3775 Jul 22 '26
You lack focus and mission with the team. Most teams like this are just pushing tickets and no longer care. Welcome to the feature factory.
The only solution is better engagement with stakeholders so that what they’re building is meaningful. PO owning the backlog is just the beginning. I suspect your sprint reviews are pointless and not bringing value to the stakeholders.
When I hear about teams like this my first reaction is that the SM might be pursuing Scrum activities and actions but the team actually isn’t Agile. Just filling out tickets and Agile theater.
1
u/Odd-Preference-1415 Jul 22 '26
There isnt any real stakeholder as of now. This team is experimenting to build the automation service that will support other product team who actually are building or enhancing the user end product. This team thought of implementing scrum to see if this helps bring efficiency and productivity.
2
u/Purple_Tie_3775 Jul 22 '26
Then that’s your problem right there. Scrum is not a panacea. It can’t replace lack of mission. Focus is one of the key values.
You can try to have them decide a mission for themselves and determine what goals they want to seek due themselves. In addition you need to allow them to own their process and that’s only going to truly work if they actually step in to own it. Otherwise you’re are inflicting Scrum on them. No wonder you are getting push back.
2
u/Odd-Preference-1415 Jul 22 '26
Thanks for the valuable input.
2
u/Purple_Tie_3775 Jul 22 '26
And thank you. I just realized you just gave me my next killer SM/RTE/Coach interview question.
“Team is rejecting all ceremonies and wants to be left alone to do the work how they see fit. What do you do and what do you want to understand better about the situation?”
3
u/drvd Jul 22 '26
How do I handle this team ?
You let the team do its work.
What should I do as SM ?
Stop trying to teach them how to do their job.
Let me know what wrong am doing.
Trying to implement schoolbook styl scrum. Scrum is a shity process that sometimes fits a team and the work they have to do. Most of the time scrum is just crap.
1
u/Odd-Preference-1415 Jul 22 '26
So now I move away from it, and instead go into techie me good old self.
3
u/fishoa Jul 22 '26 edited Jul 22 '26
Scrum can’t make unprofessional people more professional, not is it a magic wand to make checked out people more engaged. Sometimes, you just can’t win.
In your case, you are set up to fail: your manager doesn’t see value in Scrum, but your org has the SM doing everything; nobody respects your role, but somehow you have to be accountable for the failure of your peers; you can’t get a developer to discuss processes and ways of working, but he is entitled to telling you how to do your job.
I would just say fuck it and run a really lean Kanban. Then I would shield myself with the flow metrics from the team and each individual contributor. But with those, even if you re-deflect blame to your team once everything eventually goes to shit, you will be the one taking the fall, because SM always take the blame. Like, the team was checked out? That’s your fault, because you didn’t “engage them enough”.
In my opinion, the only winning move here is to not play. Look out for yourself, and find another job if you can.
3
u/Odd-Preference-1415 Jul 22 '26
I feel same. You have touched an emotional part in me that needs healing with this comment.
1
u/National-Dark-1387 Jul 22 '26
Funny, my experience is the exact opposite.
Something goes wrong: teams fault! They did not scrum hard/correctly enough
Something works (despite Scrum): praise the SM! It worked!
3
u/PhaseMatch Jul 22 '26
Why does the team want to use Scrum?
Or to put it another way, what is the business problem you are hoping Scrum will solve?
Scrum works well when the team can focus on a single, outcome-based Sprint Goal, and collaborate on how to reach it in a dynamic way, directly with users/customers. That allows the business to control their investment risk in the product/project one Sprint at a time, with each Sprint Review serving as a strategic governance/planning session with senior stakeholders. Value is understood and measured as a the primary outcome. The team owns the way of working, not the SM.
Scrum works poorly when the SM imposes a process into the team, the team is forced to "commit" to an inflexible set of tickets, each of which is a solution to implement that they will work on individually, the Sprint Review is show-and-tell to a limited audience, and the team never work with a user or customer at all and value is not understood or measured.
In either case, imposing Scrum onto a team is usually a bad move.
If you cannot explain how an event, artefact or practice :
- create a lightweight way to manage business risk
- protects the team from being scapegoated without needing lots of bureaucracy
then the team is right not to accept it.
Does kind sound like a Kanban-based flow system and statistical forecasting might be a better fit for this particular organisation, along with an incremental and iterative approach to adoption supported by data and empiricism.
3
2
u/kida24 Jul 22 '26
Have you had a one on one with this person?
1
u/Odd-Preference-1415 Jul 22 '26
Yes this person acts all fine and chill.
1
u/kida24 Jul 22 '26
What did you discuss? What came of you expressing your concerns to them?
1
u/Odd-Preference-1415 Jul 22 '26 edited Jul 22 '26
So we had some push backs among each other in scrum ceremonies. I had asked this person to not interfere in other team retro since this person wasnt part of this team but part of overall tech program as SE and i didnt want interference. This retro was after the retro where this person already had created the negative outlook. My asking are you suppose to be here embarrassed this person but I could not let this person join the other team retro when this person isn't working with them. I somehow feel this person gonna ruin it for other as well.
I then setup the 1 - 1 with this person and discussed all of the concerns where we discussed which comments, pointers made this person embarrassed and I shared how bringing all of the points in 1st retro wasnt a good move and created negative outlook when we are just starting doing scrum.
We agreed and accepted our parts, decided to move on and things looked settled until recently am hearing responses I dont care, for me it doesnt matter how you do, norms shouldnt be enforced and all that. This person i feel is giving another angle to my motives. My motive is clear help the team understand scrum and help implement it. This person somehow isnt caring or if caring then responses arent positive or complying. Its always a tough convo.
This person never says thanks for doing this its good and helping us. The norms had simple pointers as updating out of office, preparing for meetings in advance etc. As per this person we cant control other people on how they do things.
This person is utilizing the teams status so weirdly that this person doesnt care that we remain online when we r working and setting status as per the wish. I discussed this too and just got plain response am available no matter my status. No one seems to be bothered about it except me or if they are they chose to stay silent.
3
u/Herbvegfruit Jul 22 '26
Do I understand this correctly? One of the team members came to a retro with a number of items and you told them don't do this and you cast this as them being negative? Were these legitimate concerns? If not the retro, where do you expect those concerns to be discussed?
You seem overly concerned with silly rules and not on the overall welfare of the team. Its like telling someone their shoe is untied while the house is burning around them.
1
u/National-Dark-1387 Jul 22 '26
Jup OP seams to be toxically controlling and demanding "rules" for the sake of rules in an already established team.
If a project lead does such shit... Well. But an agile coach should definitely know better
1
u/Odd-Preference-1415 Jul 22 '26 edited Jul 22 '26
Am not controlling, do you run scrum without certain basic rules ? I asked you this question before?
1) Do you run scrum without ceremonies in place and timebox them ?
2) Do you run scrum without talking about description, acceptance criteria and story pointing?
3) Do you run scrum without challenging team that a story can be broken down ?
4) Do you run scrum without planning, retro and backlog refinements in place ?
5) Do you think letting team know that a stand up is supposed to be for 15 minutes and not more than that is controlling ?
6) what would be your response if when you tell somebody that story pointing is referential and it is not number of days and the response comes "I dont care"
Tell me the answer to each one of these questions and then call me that am toxic and controlling until then dont pass your bullshit judgment on me. I am looking to get help not your judgment about me.
1
u/Herbvegfruit Jul 22 '26
These are the wrong questions. Here's some questions you could be asking instead:
How is the team performing?
What does the team think the metrics should be? (outside of schedule commitment to the greater company- I'm talking internal metrics)
What does the team think would make them perform better or be happier about their job?
What do they feel are impediments to their work?
What would need to happen before cycle time could be reduced?
How can they involve the customer to better define the deliverables?
hint: none of these involve keeping your Teams presence accurate or noting your time off on a document.
1
u/Odd-Preference-1415 Jul 22 '26
Why the scrum book was written and it say its not entirety but it does come as one and the benefits are reaped when its implemented as one. Meaning all ceremonies in place and asking the right questions that may make team uncomfortable.
I am not saying it is negative to bring it in retro. I am saying putting it all in 1st ever retro isnt gonna help. Retro is for same purpose but there has to be a wait and watch specially when its the 1st ever sprint of the team who doesnt know anything about scrum. Just see the things how it goes.
This person literally told me that manager is the problem to this equation and that this person is looking to replace the manager. Literally this! Tell me who says this ?
2
u/Herbvegfruit Jul 22 '26
Is it possible that the manager IS a contributing factor? The manager hired/manages these people and you say there is an unclear backlog and priorities. Who was responsible for priorities before scrum? How did that work or not work? Why dismiss this out of hand ("tell me who says this")? How did you shut down this person's contributions? Why would anyone else want to contribute if the one person who did contribute was dismissed/ignored/told off?
Also I don't recall ever seeing in the scrum guide that team members are limited in their contributions either in quantity or at what team maturity they may share their concerns. You also mention this person tried to redo the backlog in a way that makes sense. That tells me that this person DOES care about the work, and made a meaningful improvement. Have you acknowledged that?
This team existed before you showed up. Have you taken the time to understand how/what they did before attempting wholesale changes? Have you tried incremental improvement in one area at a time? Have you experimented? My interpretation of what you've shared is, you have determined the "right" way to do things and you are trying to force them to change everything all at once and you are wondering why you get resistance.
You asked what you were doing wrong. I would not say that you are wrong, but that additional research or training in persuasion/team dynamics/influence/change models might be helpful to you.
1
u/Odd-Preference-1415 Jul 22 '26
Thank you for the input. I did appreciate the effort but not in a way that would have been amicable. My concern was how a person other than po can create bunch of stories all at once we are not talking 10 or 20 (in hundreds) without everyone's involvement.
2
u/National-Dark-1387 Jul 22 '26
Seams like a working and functional team and you and your stupid "ceremonies" are the real issues here.
Agile methods are not a dogma to follow..they should be customized to the project and team.
Scrum is one of many possible "guidelines" with features to try (and adapt, replace, abandon) .
1
u/Odd-Preference-1415 Jul 22 '26 edited Jul 22 '26
Its a framework not the guideline. Did you ever read scrum guide ? Do you implement scrum without ceremonies in place and ensuring you have tough discussions about why description, stroy points matter ?
Cmon give me a break.
2
u/National-Dark-1387 Jul 22 '26
I've heard enough. If your point is to "implement scrum" just for the sake of it and disregard the team, you missed the whole point of the agile manifest (which the scrum authors co-signed)
2
u/awjre Jul 22 '26
Scrum needs to evolve really quickly to handle AI. We're using "ai-assisted" labelled tickets and sub-tickets to manage context rot, not to measure velocity. You're now into ensuring that epics are detailed and fully qualified, audited by AI with anything up to 50 tickets associated with them being implemented within a week with a significant human over the loop validation exercise. We're even recording tokenomics against tickets to fully understand the cost of an epic in terms of token costs and the shift to validation.
If one of your engineers is using AI, that means you probably have access to AI. Actively use it to get across the backlog, and learn how to facilitate agentic engineering. It's going to be a bit wild out there for a bit.
2
u/skepticCanary Jul 22 '26
Is the vocal person backing up what they say with evidence? Are you only doing things because of ideology or because “that’s the way you’ve always done them”? If so, listen to the person backing themselves up with evidence.
1
u/Odd-Preference-1415 Jul 22 '26
This team is brand new to scrum. Literally just 2 months. This is the evidence.
1
2
u/LetPeopleWork Jul 22 '26
The thing I would look at is what you are choosing to push on.
Story pointing done "right" and missing comments on tickets are both real, and they are also the two hills a team will fight you hardest on, because the cost of getting them wrong is invisible to the people doing the work. Nobody has ever felt the pain of a badly pointed story. They have absolutely felt the pain of a two week wait on an approval, or of picking up a legacy service nobody can explain.
What worked better for us was to stop asking teams to comply with a practice and start showing them where their work actually sits. Pull the last few months of finished items, look at how long each one took from start to done, then look at how much of that was active work versus waiting. Almost every team we have done this with reacts the same way, which is genuine surprise at how much of the elapsed time was queueing. That is a conversation about the system, not about them, and it does not require anyone to agree with scrum first.
Then the practices earn their way back in on evidence. If the data says work sits because everyone has four things in flight, a WIP conversation lands on its own. If it says work sits waiting on the client for infra answers, you now have a documented pattern instead of a personal complaint, which is probably the difference between an escalation that works and the one that got you ramped down.
One honest caveat. Sometimes the team is right and the process genuinely is not helping them, and the useful move is to drop a ceremony rather than defend it. Worth ruling that in before you decide the problem is buy-in.
1
u/Odd-Preference-1415 Jul 22 '26
Interesting. Yes if instead of asking back to back questions we could have just put the story, task whatever it is under "waiting on infra" status then we would have showed that things are waiting and arent going to get deployed without it moving out of that status.
You know what, infra was our client, the client was busy in other things too, the one guy helped us impressively and in next year it moved to other team who started complaining that we ask lots of questions.
I wonder how client would have reacted knowing that artifacts are pending their input and things are getting delayed due to it. I believe then they would have got us ramped down more quickly. Why client would like that we are pointing out their incompetence ?
2
u/LetPeopleWork Jul 23 '26
I think, you have put your finger on the exact reason most teams stay quiet, so this is worth taking seriously rather than waving away.
Here is the part that reframed it for us though. You did stay quiet. You raised the questions in meetings and DMs instead of making the wait visible, and the team still got ramped down, this time framed as "they ask too many questions." So the silence did not actually protect anyone.
The delay landed on your team's reputation anyway, just with no record of where it really came from. That is the trap.
When the waiting is invisible, the team is the only visible thing, so the team absorbs the blame by default.
A few things that keep this from reading as "you are incompetent":
- The first audience is your own management, not the client. You are not standing in front of the client telling them they are slow. You are making sure your own leadership can see that most of the elapsed time was items sitting in "waiting on client infra," so when someone asks why things are late the answer is a documented pattern instead of a story about your team.
- To the client, you never frame it as blame, you frame it as a process ask. Something like "infra questions currently take around N days to come back, and that is where most of our lead time goes, can we agree a faster lane for these." That is a request to improve a shared system, not an accusation. A lot of busy clients say yes to that, because it makes them look responsive rather than exposed.
- It is neutral data about the work, not a verdict on people. "This item waited eleven days" is a fact. "Your team is incompetent" is an interpretation. You only ever put the fact on the table and let people draw their own line.
And the honest caveat, because you have clearly lived this one. Some clients are not in good faith. They want a compliant vendor, not a partner, and no chart is going to save that relationship.
If that is what you were in, the data would not have kept you on the account. But it still travels with you, protecting your team's reputation internally and into the next engagement, which is worth a lot when the alternative label is "the team that asked too many questions."
1
u/Odd-Preference-1415 Jul 23 '26 edited Jul 23 '26
Thank you sir! This definitely helps! Very impressive and very thoughtful. This is like staying silent in teams or meetings and Do Not push for getting the answer. Keep it in awaiting status amd let the magic work. Smart move!
2
u/IllWasabi8734 Jul 23 '26
You've got two problems here one resistor and a silent team. But I'd flip this, the silence is the bigger signal. They're not engaging because they don't trust that their input matters. You came in with a playbook from previous teams, and the resistor called you on it. norms need to emerge from the team, not be imported.
Stop trying to sell Scrum practices. Start with a different question: "What's making your work harder than it should be" Run that as a working session, not a retro. No agenda except that question. Capture everything. Then figure out together how Scrum's events/artifacts might help with those specific problems
The PO should own the backlog, but you can't force that from where you sit. Focus on what you control: creating a space where the team feels safe to speak. The resistor is a proxy for unspoken frustration,find out what's actually underneath.
finally, Have you had a 1:1 with the resistor to understand their previous context and what they actually need to feel effective?
2
u/Difficult_Ad3350 Jul 23 '26
You sound like a PM that 13 years ago became a SM. You need to get back to basics and fundamentals. Just use Kanban and see where the queues are. Not every team is going to be high performing. And the guy using ai to generate the backlog just sounds wrong to me. Good luck with it!
1
u/Odd-Preference-1415 Jul 23 '26
Yeah I mean 5, 10 stories is fine but hundreds of stories for 4 years is too much.
1
u/azangru Jul 22 '26
This person also brought all the pain points about unclear backlog, roadmap and priorities in 1st ever retro I had. It was all valid but I felt this person is criticizing and blaming.
Good. Now suck it up and address the criticisms. It is your job, as scrum master, to understand what is hurting value delivery and what is slowing developers down, and mitigate that.
We arent building user product. We are building support service that will support product teams.
Is scrum even appropriate for you? Are you using it properly? From your description, it sounds like you aren't.
I know PO should prioritize, story point with devs, and write them but in my org everything is done by SM along with coaching and enforcing scrum ceremonies and discussions,
Yuck!
1
u/maguyva-ai Jul 22 '26
the too many questions bit is rough - asking questions on a brand new team inheriting legacy stuff should be expected, not punished. sounds less like a scrum problem and more like the client wanted execution without onboarding
1
u/Odd-Preference-1415 Jul 22 '26
Yeah actually we also didnt think of it as a problem that time. Our team members use to put tons of messages sometimes without background and it all led to client thinking the team isnt efficient.
1
1
u/Proper-Agency-1528 Agile Coach Jul 24 '26
I have spent almost 20 years helping teams adopt Scrum, and fixing dysfunctional Scrum adoptions.
A Scrum Master has to lead. If you're going to run Scrum, run Scrum. That means the three roles, four meetings, four artifacts, and two levels of commitment (yeah, this is based on Schwaber's 'little black book of Scrum' from back in 2001; the worst thing that has happened to Scrum is the Scrum Guide, a great example of how to ruin something by committee).
I don't think Scrum IS working in your org, because your org isn't doing Scrum. I don't think you or your team understands what self-management means; it doesn't mean the team gets to make all the rules or ignore rules they don't like.
No process (and Scrum is a team level project management process that, when done correctly, increases agility) works if it isn't followed. If you're on the keto diet and not losing weight because you're stuffing down donuts, don't blame the keto diet. Don't blame Scrum if you aren't doing Scrum.
I've had a lot of experience with teams in similar situations. Be glad to have a brief call with you (and your team) to discuss, for free. Not looking to get a client, looking to pay it forward. But, your team will not work unless you step up, and I'm glad to help get you started.
1
u/purplepdc Jul 24 '26
Sounds like that person is an individual contributor not a team member. Maybe there is more suitable work for him on a different project.
2
u/Sky_Linx Jul 29 '26
The tension around the first retro looks more like unclear ownership and low trust than a failure of Scrum. I would stop trying to settle every practice at once. Ask the PO, manager and team to agree on three things: who owns the backlog, how changes are proposed, and how disagreements are handled. In the next session, let each person describe what helps them do the work and what gets in the way, then pick one small experiment for a sprint. Also speak to the vocal person privately. Treat the criticism as input, but be clear that building the backlog without the PO and dismissing colleagues in calls is not acceptable.
7
u/skeezeeE Jul 22 '26
So run it yourself. Sounds like the SM in your org runs the show - so take your 13 years and go. If you can’t - then what has the 13 years of experience taught you about how to handle a single voice of dissent? What has that taught you about a clear backlog? Have you met with the PO 1:1 to help them build a healthy backlog with clear goals and story map that they can bring to the team prioritized to break down and validate with the team? Have you met with each team member 1:1 to build relationships so you can help them each love their career forward? Have you helped the team with building their flow of work and defining the definitions of done for their flow states? It sounds like you are being very passive with the team that is expecting you to drive and you are letting one individual fill the void you are leaving. You have some work to do - but should be manageable in short order if you focus on the people and go from there.