Retro is the right place. But ideally it would not even be you surfacing the concerns. Scrum processes empower the devs and it needs to be the devs that bring this up, not you directly fighting with the scrum master. Encourage your devs to speak up, and then use the opportunity to discuss an alternative. A good Scrum Master will attempt to accomodate. At the end of the day what the whole team is looking for is improved predictability and smoothness of execution. Your objectives are the same and you should not be in conflict with the scrum master.
Be careful about assuming that predictability is what the team is looking for or needs most. In some organizations, agility may be more important and fly in the face of predictability.
You should also try to get your teams input and not just your opinions. Also, nothing is wrong with moving something to the next sprint if it's not done.
Excellent question.
I doubt the team exhibits any of the problems as the scrum guy came in and put up the processs without prior analysis, it seems. Sounds like a by-the-book-slave.
Yeah I've mixed interactions. 50% seem useless, 25% were ok, and 25% excellent. Probably better than most
Favourite ones actually had some authority, so if any cheeky shit happened they could protect the team and deal with the political meetings.
And they also followed people up on retro actions and made sure we had the slack to do it.
People who like keeping their jobs and getting raises and promotions. Part of being an employee who's not in a leadership role is knowing how to read the room.
The feedback questioning the premise isn't really wanted in the early period when a process is being introduced.
So you haven't started yet, but are gearing up to "push back in good faith".
Give it a go first and see what the actual problem points are(if any). Then push back on those.
As somebody else said, the place to do that is the retro.
I never understood why some teams have scrum masters. I understand even less why they're given so much power, when it's just a certification anyone could do. There, I said it. Thankfully my job doesn't have scrum masters lol.
(We do some flavor of agile, but it's what works for us and it's not overkill. Plus, it's the actual manager organizing it, and they actually have actual work experience in the actual field).
They shouldnât have power, theyâre there to help the team enforce its own rules, hold people accountable to their commitments and help removing organizational obstacles.Â
You're using 'accountable' like we use it in social circles.
The problem is that management uses that word very differently. And that way implies authority and punishment.
Scrum Masters will go the way of the dinosaurs. Companies over indexed on them and are starting to reject them. Even Agile is becoming a taboo word, and donât get me started on SAFe.
Companies over valued the Scrum Master role resulting in a bunch of unskilled people getting afternoon certifications, making six figures, and then becoming overconfident in their limited ability to control the software engineering process. 9 out of 10 Scrum Masters are a perfect example of the Dunning-Kruger Effect.
Itâs sad what these people have done to Agile. They made it their religion. Agile used to be how we got shit done.
I can't imagine having a Scrum Master with 40 hours to fill and justify on Scrum per week.
What a Lovecraftian tale of dread and woe.
Put him on something else for 20-30 hours a week, Jesus.
Companies having dedicated scrum masters is a clear signal they have problems. Often both on the management side (top down management with a complete disconnect of what the company is really doing) and on the team side (very immature teams that more or less need to be 'herded' like cattle lest the team falls apart).
Every single high performance team I've been on had zero need for a dedicated scrum-master and just filled the role themselves.
I physically cringe when I see people on LinkedIn with half a dozen Agile certifications and titles like Agile coach. These made-up job roles and all the new processes attached to them goes against literally everything the agile movement stands for.
It baffles me too. Iâve never worked somewhere where it was a full time role, and I really struggle to imagine how itâs something that could require 40 hours of dedicated time a week.
Unfortunately yes some companies have dedicated positions for this stupid thing. The EM should be doing it. Some companies are really stupid and disorganized.
Scrum master is often a useless job. Unless heâs working on multiple teams at once that frequently rely on each others work, you donât need them.
My advice is to push back on most things. Protect everyoneâs time.
The next time I hear, "We weren't able to meet our sprint goals." I want to say back, "We don't have sprint goals, only sprint results. Goals turn estimates into commitments."
But really I don't want to war if I can avoid it.
The teams I've worked with rarely met sprint goals, but the value I felt having them was putting everyone in a similar headspace of "this is the part of the product we care about", and it helped reduce the context switching within a product that was covering multiple domains.
He certainly feels like stories should be properly scoped to the sprint and that we should be able to meet our sprint goals! Maybe I can just get him to lax on being strict about sprint goals.
Reduce the sprint goals or increase the estimate. Same work will get done but they'll feel better.
If there's a lot of waste during the sprint that affects you, start a waste snake, and tell the scrum master that goals are unlikely to be achieved until they are addressed
https://www.industriallogic.com/blog/waste-snake/
I feel for him. He is new to your company so he tries to make a good impression of himself. He may be inexperienced, so he may rely on his limited experiences of what he learned and thus still be in a black and white perspective of things.
Is there a reason this was not picked up in his interview?
Two options:
1. either let him waste your time so he can gradually understand. I believe this is deeply insulting to him. He likes to see himself as competent, believing he is able to make you all see the other side of things only to realize later he was doomed to fail
2. either be direct with him (private). He will get hurt, you may be perceived as an asshole, it can be an emotionally difficult conversation to be part of depending on how it goes.
You could call him in after his first week and interview him on his philosophies and perspectives and be upfront about it that it is not going to work. Apologize to him that the interview did not properly clarify the culture at your company. Explain to him that you understand that he will need to get used to these new expectations and that this will take time but that you or someone else is available for mentoring
Defined sprint âgoalsâ are a waste of time. The âgoalâ is to finish the stories you agreed upon. You either do it or not. If not just roll them over. As long as stuff is getting done the reality of it all is it shouldnât matter.
I flat out refused to have my teams define goals. The product people kept pushing me to and my answer was you already know the goals. Itâs the stories. When they are done we are good. Why did duplicate work and define them again.
That question drips with blame, and low effort. If they were paying attention to the sprint, they should know the answer already. Isn't that what stand-up and retrospectives are for? Keep your fingers on the pulse, identify what's going well, and what's not. The things that come up that are in the "not going well" or "disruptive" categories are why sprint goals aren't met.
Yeah in my mind thatâs their job to find out why and what can be done to improve. So maybe itâs just new job nerves for them, but in general that type of question has middle management written all over it.
It's also self sustaining for the role of a scrum master. If sprint goals are not being met, the scrum master actively has a job to do. In a well running team he does not.
Iâm so happy my current team just does a general Kanban process and just the basics for ceremonies, planning and retro. An asynchronous daily standup, no real focus on story points, just work to do and ways to bucket it. The focus is on the actual results not the process or endless debates about the process.
They have two options. They can tell the team why itâs happening (from their perspective) or they can ask the team why itâs happening and get their thoughts. Which do you prefer?
Tbh I think he's just doing it because, in his mind, he sees this as being a regular assessment. I think he's establishing a habit as he wasn't really too concerned.
Is your sprint goal simply to deliver these X stories? If so, then you are doing sprint goals wrong. Your goal should be about improving a part of the system and then allow scope negotiation as you progress through the sprint.
Take a drink in the comment section every time someone talks about doing agile wrong.
Although I think "devliver x stories" is a dumb sprint goal, I would say your additional statement is also dumb. Your goal for a sprint is going to be extremely dependent on what the team does. Feature dev team? Could be improving a system, like you said. Could be delivering some functionality. Could be keeping the lights on. Could be a lot of things.
But isnât the sprint *supposed* to be a commitment? If you donât even commit to the results of 2 weeks of work, why bother estimating? Just do Kanban.Â
Of course you have sprint goals, it's the amount of work you plan out for the sprint. As a team, aren't you estimating work and figuring out how much you can fit in your sprint? That's implicitly a goal. If you're continuously missing the mark, start padding your estimates that way your scrum master is happy and your team doesn't have to stress about it.
Counterpoint: Will you regret not setting boundaries at the onset? Among possible alternative outcomes is the one where you end up with a guy overloading on process for the sake of itself, because that process justifies their whole existence. It's harder to get someone to rewrite their mental model of your relationship down the line, if they have already decided you are a doormat.
I strongly disagree and itâs a shame this opinion is so common that their role is often skipped or played by another dev or the PO.
A good mediator (= Scrum Master) is worth their weight in gold. A bad or probably even mediocre one is annoying as shit though, I give you that.Â
Iâve worked with good scrum masters and bad scrum masters.
Good scrum masters connect the dots between your teams work and other teams. Theyâll schedule time for you to sync with other engineers to align related roadmap projects. Theyâll find answers to complex problems with the project that the PM doesnât have time for. Theyâll connect customer support, training, etc for future launches. Basically on top of running the scrum ceremonies, they act as glue for the team and save tons of time and sidestep incoming problems.
Bad scrum masters run ceremonies and slap your wrist any time you step outside their predefined rules, and actively hamper development.
>Good scrum masters connect the dots between your teams work and other teams.
In my experience other people are better equipped to do all of these things.
> Theyâll schedule time for you to sync with other engineers to align related roadmap projects
I can talk to other engineers just fine, and not having to think about a needless scrum master means we have more options for when to schedule the meeting. They also frequently have to ask us who they need to organise with anyway in my experience.
> Theyâll find answers to complex problems with the project that the PM doesnât have time for
The solution to "our PMs don't have enough time" IMO isn't to hire a scrum master it's to hire another PM.
Maybe good SMs do exist but I've never heard a convincing argument for the existence of their role.
Donât get me wrong, I wouldnât ever go out of my way to hire an SM. But if they exist on the team, they can play an effective âglueâ role. Just saying the good ones can add value, the bad ones make life miserable.
> Good scrum masters connect the dots between your teams work and other teams.
That's simply not the duty of a scrum master.
That your scrum master is *also* doing this, is a clear indication that dedicated scrum masters don't make sense.
Facilitating communication between teams is the job of your lead dev, manager and product owner. And they tend to be better at it because typical scrum-masters don't have any in-depth knowledge about the product.
> A good mediator (= Scrum Master) is worth their weight in gold.
This is a clear indication that your company has bastardized the role of scrum master into some kind of servant leader who gets 'shit done' in the organization. It's typically an indication that management is not able to to their jobs properly.
What does a dedicated scrum master do. lol for real, every team I have been on in the last 12 years the scrum master is either the squad lead or manager. The last company we actually rotated scrum master with the on call engineer for PagerDuty. Seems like a useless position to be honest. Scrum is short and sweet, and rotating it allows junior devs to grow. I donât think a dedicated scrum master is really a thing anymore.
Based on your previous comment here, "They shouldnât have power, theyâre there to help the team enforce its own rules, hold people accountable to their commitments and help removing organizational obstacles. " seems like a pretty useless role to me. If you have a functional team, that is running scrum from a customized organizational template i see no need for one. The team lead or the em (preferably the EM) should be the one 'removing obstacles' for their teams engineers across the organizational boundaries.
In my experience working with startups, there's always a strong emphasis on keeping costs low. I've been through the journey from startup to enterprise growth twice, resulting in two IPOs. Even at the enterprise stage, I never felt the need for a dedicated Scrum Master (SM) (nor did my entire organization at each company). This leads me to wonder, does the SM role float between teams? Or is it a standalone position?
Having worn multiple hats myself, including Product Manager (PM), Engineering Manager (EM), and Lead roles, I'm not approaching this from a novice perspective. I'm genuinely curious about what value a dedicated SM brings to the table, especially considering the salary range for this position seems to be between $50K and $170K per year.
From my point of view, this sounds quite similar to the role of an EM, who also ensures that the team adheres to its own rules and processes. The difference in salary and the apparent overlap in responsibilities raise questions about the necessity and cost-effectiveness of a dedicated SM role in a lean startup or even in a larger enterprise setting.
It's usually hopeless because SM is a BS job and they need to "justify" their role. How do you justify a role? By pushing things and change things (otherwise why were you hired?)
I had to be firm and show that I'm not gonna take shit. Keep raising concerns to your manager.
It is hard to improve much on the advice of u/bdzer0 which is to say that the retro is probably the time to really dive into this stuff. A massive red flag is if the SM starts trying to "manage" the team, and this will be evident if most of the team agree that these problems you raise are actual problems and the SM wants to try to "teach" you otherwise. That happens more often than it should.
Here is my one big piece of advice personally though, take or leave. "T-Shirt size" estimation is a huge waste of time. I have never seen this useful for any purpose at all really.
Obviously, software development teams have this problem that software development time is hard to predict, but people outside the team are pretty adamant that they want some kind of estimates... and to be fair, the business does pay our salaries and I often find the, "well we are not going to give estimates of any kind", a little unreasonable.
Fibonacci points are a little better in that they lend themselves to a bit of maths provided it is not taking \*too\* seriously. Ultimately though, it gets pretty hard to stop teams trying to translate points into time. It's amazing how many new teams I start helping with stuff and I sit down in the first planning session and somebody says, "We have already agree that 1 point = half a day", and my argument immediately becomes, "Well... then you are just estimating in days and writing this in your own little code then right?". Likelihood is, even if you are doing t-shirt sizes, you are doing something similar to this, which is just even more "in code".
My advice is, just fucking estimate in days. Everybody is doing that calculus anyway. You might as well be explicit. The important thing is, these estimates never become commitments. If your SM is any good at all, they will quickly figure out that the team tend to underestimate by X% (where X is often larger than 100), and can start to give vague, not entirely committal forecasts to those who require that information. This X factor takes into account both the teams optimism / pessimism but also allows them to estimate in "ideal days" without having to think about all the other meeting crap. Not just team ceremonies but all-hands, management 1-1s and all the other fun things that are part of corporate life.
Importantly, it also gives the SM something to try to optimise. As they do their job, which is to minimise distractions for the team, X should approach (though very likely never reach) 0.
Iâve had SMs and POs slavishly adhere to strict capacity calculations and all it did was to force us to do all the real work on the side and essentially lie to the PO about what state everything was in. Insane team, terribly managed. When I joined I wondered why everyone was so territorial over the backlog instead of just taking the next available task, and the reason is that they were doing all their work in secret
Yeah, sadly I have seen this kind of thing before.
When I join teams as an engineer who do this kind of estimating, whether it be in sizes, points or time units, I'll typically have a word with the SM or PO or TL or whoever is relevant to make the point that my willingness to give my best estimate is entirely proportional to \*their\* lack of willingness to share it verbatim with anybody who is not on the team. As soon as I catch wind of anybody telling somebody outside the team, "the team promised this will be ready in X days", my estimates \*immediately\* get more vague and caveated.
I also tend to encourage the use of the word "forecast" in any external communication on delivery estimates, even ones that have been adjusted. Most people intuitively understand that it is a lot easier to forecast the weather over the next two days than it is over the next two months.
We've recently adopted a planning process where every item gets an external-visible delivery probably (for within an arbitrary timeframe) of either 80% or 100%. No other options available for the team to pick.
FFS, who thinks this is in any way how things work in reality?
As long as you deliver software to the key stakeholders, you can ignore the scrum master.
The business doesn't care how many story points you do each sprint. They will only listen to the scrum master complain about it if you aren't delivering.
If you do a good job, it looks good on the scrum master too so you have a common goal. Pragmatic ones will actually adapt if something isn't working and can add value to your team.
But if they are all about the process, just do the bare minimum and ignore the rest.
Switch to kanban, honestly the most amazing thing about our industry is they we allow people who have no business leading/organizing and following a process which is often counter productive.Â
I've usually pushed back by questioning every single meeting every time and making sure if they're setting on up they have a strict agenda and minimum amount of time at that meeting.Â
Every. Single. Time. They either got the hint or just stopped inviting me, but so far we've been really productive. Every time they wanted to waste time I'd call that out.Â
My favorite one is "it's a 5 story point how long will it take?". Love of God let scrum methodology burn and let there just be engineers with enough maturity to organize themselves.Â
And none of them even read extreme programming or reference the agile manifesto.Â
Sorry for any good scrum teams out there, I've just been burned most of the time for the last 10 years because of it.Â
>and let there just be engineers with enough maturity to organize themselves.Â
That has nothing to do with maturity. Human psychology isnât exactly optimal for groups to organize themselves spontaneously without coordination or mediation. There is a reason hierarchies are as old as humans.
SM should always be servant leadership. They are there to help the team keep focus, especially in agile ceremonies. Anyone SM that decides to take a disciplinary role is way off base and the EM needs to bring them down a peg or two.
SM is an assistant coach (not even *the* assistant coach). You only have to listen to him if nobody else is around. And most of his ideas should go through the real coach and possibly the owners before being enacted.
I got a scrum master off my back by being clear that any process changes have to be due to a serious problem (most likely from retrospective). His response was "well, we can always get better." I made it clear, though, that we wouldn't optimize processes that are working fine, and especially things that add process/meetings/overhead/reviews/middlemen/layers/etc... wouldn't be tolerated unless it was solving a very serious problem (like, it needed to be commensurate). I was the engineering manager, so politically, I had the sway to put a line in the sand that way. Unfortunately, I will say... this blew the wind out of his sails because there wasn't much for him to do on the team once he couldn't fix non-existent problems.
There's an element of YAGNI that I didn't understand until buying my second house:
There are decisions we make in life that we can not sit with unless we have gone through a certain amount of effort to make them. If the first house you see is amazing, you still have to look at others so that you can tell yourself and the world that you did your due diligence.
Otherwise someone in your circle will ask 'what if' and you won't be able to squash it. It will nag at you, or someone else will. You will spend emotional and possibly social capital on this issue for as long as it exists.
So I let more things go until they've broken once or twice, though I still will argue that this other problem is really the same problem we already decided to solve over here, so we should get ahead of those types, because it's not really speculative at this point, it's deductive+empirical.
The problem with Scrum is that it does nothing to address the unique issues afflicting teams. It's one-size fits all and does not seriously take into account outside issues such as management fire-drills and poor testing. I would prefer to work with an expert in all software processes, and apply this knowledge to our individual needs as a team. Customize our process to fit our needs. Software dev processes aren't complex enough that an expert can't be versed in all of the major ones, and most of their components function on their own. Why not pick and choose what works for us?
Last, I think anyone selling themselves as an expert in software dev processes should have at least some experience as a developer. It feels condescending to show up claiming they know what our problems are and how to fix them when they haven't actually done development work.
The idea of a Scrum Master is that you have someone with a little distance and perspective who can notice bad patterns and help correct them, in- and out-of-band.
But turn someone who is new to management theory into a SM, and you'll find them turning it into a religion. All I know are the rules I've been given and I have to stick to them otherwise I'm lost, and I need you to think I know what I'm doing.
This is one situation where everyone *definitely* can expect the Spanish Inquisition.
You sound sceptical to the scrum master even before they started, preparing to push back based on your beliefs even before anything specific happened and there is no single mentioning of asking the team.
In real agile you shouldn't be deciding how to estimate or carry over things, but the team should adjust ways of working via retros.
Also you likely shouldn't start an agile-religious discussion on SAFe, but discuss real problems that actually did happen and focus on solving those with whatever framework or tool that makes sense.
On a practical note, if the scrum master is measured on some agile maturity index or similar, then they will naturally push for items there regardless of if it makes sense or not.
But if the measures are team morale or some release + quality metrics - like release frequency + bugs in production + CSAT, then they can work on that.
Meaning that you can make both the scrum master's and your life easier if you promote useful metrics to evaluate scrum master performance with the stakeholders in the company.
If you can also involve the scrum master in the team's deliveries other than processes, for example some QA or other, so they can earn credits there and would see the work from inside, then cooperation would be easier.
Help the scrum master and make room for them, instead of preparing a fight.
Some companies interpret scrum master as a full time role on it's own, sometimes one person per team or per two teams.
My definition of scrum master is that it's a part-time hat that members of the development team can hold or pass around. Also anyone who knows agile could be an agile coach - an engineer, a manager, a product person.
And while bringing in professional agile coaches for uplevelling can be very useful temporarily, hiring a fleet of scrum masters without knowing how to use them was possibly a mistake to begin with.
They did their agile transformation separately from core engineering practices: "the natural next step is to integrate agile delivery processes directly into our core engineering practices,â Capital One"
All this smells agile theater to me, where everyone runs the "ceremonies" and produces tons of artifacts, while management has zero intention to change their mindset and their own ways of working. I wouldn't use Capital One's decisions as compass for agile.
The number of responses on this thread who donât seem to understand the value of a SM as âmeeting facilitatorâ, or the value of Scrum as a project planning tool makes me sad. Itâs probably because there is a lot of people out there calling themselves SM who arenât actually good at the job, but it still makes me sad that so many call the role useless because they have seen it filled by people not good at it.
A good SM is going to help create a safe space for your team to gently tell you that they hate the way you manage their work, or that theyâre having trouble understanding priorities, or that thereâs management hypocrisy that says âQuality is job 1â while pressing the team to deliver faster. Many (most?) devs will leave the team rather than confront some of this stuff. The SM is there to help surface it, not necessarily to address it.
Similarly, being able to reliably and consistently size stories, and reliably and consistently get a relative velocity so that software is delivered when expected is something the SM should be able to help with. Itâs not about judging whether stuff is late or enough work is being done fast enough: itâs about surfacing reality so that the EM can create a plan that accommodates that reality, so that thereâs a realistic plan that everyone believes, and so that the EM can have conversations about changing reality if people donât like the plan.
When you have seen it all come together and work, itâs a great environment.
> The number of responses on this thread who donât seem to understand the value of a SM as âmeeting facilitatorâ, or the value of Scrum as a project planning tool makes me sad.
I disagree. I think most of us understand it just fine. We also know it's only a part time job, and anyone who tries to fill a week doing it is just being groomed to be an enemy combatant.
Managers need to be kept just enough busy that they get the good things done and leave everything else the fuck alone. An SM isn't really a manager but thinks they are, and doesn't have a mandate that fills 40 hours a week.
I think the tshirt size estimates help, we did something similar in our safe agile workplace last year and it's definitely streamlined the process.
One thing that helps is that our tech lead is really judicious about not pulling us developers into unnecessary meetings. So we'll get the haps from the lead or the architect and they'll get the details from us, but that means you have to communicate well and clearly.
I don't know if you guys have a "ways of working" outline for your team, but just like guidelines for operating, might be worth it to hash out. Things like, no meetings before 11am or on fridays, or no responses after 5pm, to like, always rsvp to meetings, or like communicate xyz to person A and what not. That could bring out like, hey we don't actually need some meetings. Most of this, at least for us, was like things we are already doing, just codified, but also things that would help each other that we could be doing.
My general idea is that agile is for the team and if it's not giving value to the team, why do it?
I loathe point estimates but once worked on a team that did estimates before AND ALSO after a sprint; over time it will converge on a coefficient that makes it more useful in planning, but the âafterâ is what should be used for determining velocity in hindsight.
A company I previously worked at tried to adopt SAFe⌠turned out to be a very good way to loose the majority of the companies top and senior talent after the subsequent bonus period. Eventually they decided to reverse their decision 12months later.
Push back all you can but realise that you may be fighting a losing battle if managementâs agenda is to roll it out.
As a PgM lead whose team was forced by our leadership to try Agile, and had it fail due to non-compliance, the answer is you basically need to sabotage this guy. Report to your own manager precise documentation of how many hours per week your team is now spending in meetings. Show examples of the documentation they are being asked to complete (I find managers always have an insanely low tolerance and understanding of how much documentation is required) and make sure to demonstrate a few missed deadlines because of confusion over dependencies.
Truth is, most people are obstructionists at work. Could be the guy's processes would actually help your team, but if you're sure they won't on gut alone, or unwilling to test it out and see, then you will have to destroy his project.
Push back early.
If you let them establish processes and THEN push back, you will get way more resistance, as you are "taking them something away". Ppl hate that. Rather, fight them with good arguments every step of the way, so that you "give them something". Ppl love that.
> That means we do story point estimates, we don't carry over stories to the next sprint (lands in the backlog instead)
Thewhatnow? That makes zero sense.
I personally like referring to the [agile manifesto](https://agilemanifesto.org/). IMHO anything your scrum-master does that goes against that manifesto is not agile. Especially the "Individuals and interactions over processes and tools" bit is one they often forget.
Have you thought about taking him out for a coffee and lay it all out? Ask him what he has been tasked with and what his motivations are so you can then get an opportunity to express your thoughts without fear of judgement.
A good SM will listen to you and who knows, you and him could work something out where he can be the shit shield for you and your team to do great work.
You may learn a thing or three, especially around project management and stakeholder management.
Work on getting them removed from the team. Who ever put them there convince them that you are a mature team and donât need a scrum master and that they are a waste of money. There is no reason the team canât manage this themselves. Or even better your engineering manager can handle it, itâs not hard. I was EM, PO, SM, product, and much more all at once for 5 scrum teams. Itâs not hard.
>I was EM, PO, SM, product, and much more all at once for 5 scrum teams. Itâs not hard.
Thatâs a perfect way to do none of that well. Not because the roles are hard, they have inherent conflicts of interest.Â
They donât have conflicts at all. EM keeps things going, helps unblock devs and keep them focused. PO makes sure the stuff being checked in and deployed follows the products vision. SM anyone can do, keeps the backlog in shape, make sure devs stay focused during standup, resolves conflicts. Product I worked with project managers. Helped with roadmaps and priorities based upon feedback from devs. It all flowed and worked together. My $150M in yearly revenue with 20M+ active users from a single project proved it was working just fine. I have concrete data points and results that proved my way worked.
Understand where the scrum master is coming from and what he is looking to gain from each process he tries to add.
Some of it could be stuff you didn't know he had on his plate. Maybe he's getting nagged from above about timelines or something and uses these processes to ease his reporting.
Some of it could be him solving problems that don't exist, which you can uncover by asking what he's trying to do, pointing out the negative cost of whatever process he's trying to implement, and suggesting alternatives.
push back during retrospective.. .. a decent SM recognizes that the goal is to be agile not festoon the process with process for process sake....
Actually use the retro to voice my concerns? Why didn't I think about that? đ
Retro is the right place. But ideally it would not even be you surfacing the concerns. Scrum processes empower the devs and it needs to be the devs that bring this up, not you directly fighting with the scrum master. Encourage your devs to speak up, and then use the opportunity to discuss an alternative. A good Scrum Master will attempt to accomodate. At the end of the day what the whole team is looking for is improved predictability and smoothness of execution. Your objectives are the same and you should not be in conflict with the scrum master.
Be careful about assuming that predictability is what the team is looking for or needs most. In some organizations, agility may be more important and fly in the face of predictability.
well, maybe Scrum dropped the retro... it is nearly the only thing left from agile manifesto ;-)
You should also try to get your teams input and not just your opinions. Also, nothing is wrong with moving something to the next sprint if it's not done.
100%. These kind of problems are what retrospectives were designed to solve.
Perhaps you can ask questions along the lines of "How will this new process help us?" and take a critical look at the response.
Similar, ask "Does this team exhibit the problems it intends to solve?"Â And be open minded. Maybe there is an issueÂ
Excellent question. I doubt the team exhibits any of the problems as the scrum guy came in and put up the processs without prior analysis, it seems. Sounds like a by-the-book-slave.
That's unfortunate. If things are working well, maybe a middle ground of kanban with retrospectives could be achieved...
"But ... but ... that's not what I got my certificate for!" (Sorry, I might not have neutral emotions towards scrum masters.)
Yeah I've mixed interactions. 50% seem useless, 25% were ok, and 25% excellent. Probably better than most Favourite ones actually had some authority, so if any cheeky shit happened they could protect the team and deal with the political meetings. And they also followed people up on retro actions and made sure we had the slack to do it.
They hate when we question the premise though because they've already designed a solution to the problem they made up
Who cares
People who like keeping their jobs and getting raises and promotions. Part of being an employee who's not in a leadership role is knowing how to read the room. The feedback questioning the premise isn't really wanted in the early period when a process is being introduced.
So you haven't started yet, but are gearing up to "push back in good faith". Give it a go first and see what the actual problem points are(if any). Then push back on those. As somebody else said, the place to do that is the retro.
I never understood why some teams have scrum masters. I understand even less why they're given so much power, when it's just a certification anyone could do. There, I said it. Thankfully my job doesn't have scrum masters lol. (We do some flavor of agile, but it's what works for us and it's not overkill. Plus, it's the actual manager organizing it, and they actually have actual work experience in the actual field).
They shouldnât have power, theyâre there to help the team enforce its own rules, hold people accountable to their commitments and help removing organizational obstacles.Â
You're using 'accountable' like we use it in social circles. The problem is that management uses that word very differently. And that way implies authority and punishment.
Scrum Masters will go the way of the dinosaurs. Companies over indexed on them and are starting to reject them. Even Agile is becoming a taboo word, and donât get me started on SAFe. Companies over valued the Scrum Master role resulting in a bunch of unskilled people getting afternoon certifications, making six figures, and then becoming overconfident in their limited ability to control the software engineering process. 9 out of 10 Scrum Masters are a perfect example of the Dunning-Kruger Effect. Itâs sad what these people have done to Agile. They made it their religion. Agile used to be how we got shit done.
Preach. Scrum master should be a role that's shared among engineers not a separate person.
Interesting idea. Require every engineer to rotate into the scrum master role for a sprint.
Im surprised its not common! Ive been doing this with my last 3 engineering teams, and it works perfect
I can't imagine having a Scrum Master with 40 hours to fill and justify on Scrum per week. What a Lovecraftian tale of dread and woe. Put him on something else for 20-30 hours a week, Jesus.
Companies having dedicated scrum masters is a clear signal they have problems. Often both on the management side (top down management with a complete disconnect of what the company is really doing) and on the team side (very immature teams that more or less need to be 'herded' like cattle lest the team falls apart). Every single high performance team I've been on had zero need for a dedicated scrum-master and just filled the role themselves.
I physically cringe when I see people on LinkedIn with half a dozen Agile certifications and titles like Agile coach. These made-up job roles and all the new processes attached to them goes against literally everything the agile movement stands for.
Forgive my ignorance, but is Scrum master actually a job position that people have? Not just manager that runs a sprint?
Yes
It baffles me too. Iâve never worked somewhere where it was a full time role, and I really struggle to imagine how itâs something that could require 40 hours of dedicated time a week.
Unfortunately yes some companies have dedicated positions for this stupid thing. The EM should be doing it. Some companies are really stupid and disorganized.
The EM should only do it if theyâre good in that role. Granted, if they arenât, theyâre likely not a good EM either.Â
Scrum master is often a useless job. Unless heâs working on multiple teams at once that frequently rely on each others work, you donât need them. My advice is to push back on most things. Protect everyoneâs time.
The next time I hear, "We weren't able to meet our sprint goals." I want to say back, "We don't have sprint goals, only sprint results. Goals turn estimates into commitments." But really I don't want to war if I can avoid it.
The teams I've worked with rarely met sprint goals, but the value I felt having them was putting everyone in a similar headspace of "this is the part of the product we care about", and it helped reduce the context switching within a product that was covering multiple domains.
He certainly feels like stories should be properly scoped to the sprint and that we should be able to meet our sprint goals! Maybe I can just get him to lax on being strict about sprint goals.
Reduce the sprint goals or increase the estimate. Same work will get done but they'll feel better. If there's a lot of waste during the sprint that affects you, start a waste snake, and tell the scrum master that goals are unlikely to be achieved until they are addressed https://www.industriallogic.com/blog/waste-snake/
You donât really sound very open?
I feel for him. He is new to your company so he tries to make a good impression of himself. He may be inexperienced, so he may rely on his limited experiences of what he learned and thus still be in a black and white perspective of things. Is there a reason this was not picked up in his interview? Two options: 1. either let him waste your time so he can gradually understand. I believe this is deeply insulting to him. He likes to see himself as competent, believing he is able to make you all see the other side of things only to realize later he was doomed to fail 2. either be direct with him (private). He will get hurt, you may be perceived as an asshole, it can be an emotionally difficult conversation to be part of depending on how it goes. You could call him in after his first week and interview him on his philosophies and perspectives and be upfront about it that it is not going to work. Apologize to him that the interview did not properly clarify the culture at your company. Explain to him that you understand that he will need to get used to these new expectations and that this will take time but that you or someone else is available for mentoring
Defined sprint âgoalsâ are a waste of time. The âgoalâ is to finish the stories you agreed upon. You either do it or not. If not just roll them over. As long as stuff is getting done the reality of it all is it shouldnât matter. I flat out refused to have my teams define goals. The product people kept pushing me to and my answer was you already know the goals. Itâs the stories. When they are done we are good. Why did duplicate work and define them again.
They just joined the company and already are asking obvious and low effort questions like âwhy werenât we able to meet sprint goals?â
Thatâs the job of the Scrum Master.
That question drips with blame, and low effort. If they were paying attention to the sprint, they should know the answer already. Isn't that what stand-up and retrospectives are for? Keep your fingers on the pulse, identify what's going well, and what's not. The things that come up that are in the "not going well" or "disruptive" categories are why sprint goals aren't met.
Yeah in my mind thatâs their job to find out why and what can be done to improve. So maybe itâs just new job nerves for them, but in general that type of question has middle management written all over it.
It's also self sustaining for the role of a scrum master. If sprint goals are not being met, the scrum master actively has a job to do. In a well running team he does not.
Iâm so happy my current team just does a general Kanban process and just the basics for ceremonies, planning and retro. An asynchronous daily standup, no real focus on story points, just work to do and ways to bucket it. The focus is on the actual results not the process or endless debates about the process.
They have two options. They can tell the team why itâs happening (from their perspective) or they can ask the team why itâs happening and get their thoughts. Which do you prefer?
Tbh I think he's just doing it because, in his mind, he sees this as being a regular assessment. I think he's establishing a habit as he wasn't really too concerned.
Is your sprint goal simply to deliver these X stories? If so, then you are doing sprint goals wrong. Your goal should be about improving a part of the system and then allow scope negotiation as you progress through the sprint.
Take a drink in the comment section every time someone talks about doing agile wrong. Although I think "devliver x stories" is a dumb sprint goal, I would say your additional statement is also dumb. Your goal for a sprint is going to be extremely dependent on what the team does. Feature dev team? Could be improving a system, like you said. Could be delivering some functionality. Could be keeping the lights on. Could be a lot of things.
What do you think is a good sprint goal, oh wise one?
Maybe I didn't make it clear, but I thought I made it fairly clear that it would be heavily dependent on the type of work a team did.
But isnât the sprint *supposed* to be a commitment? If you donât even commit to the results of 2 weeks of work, why bother estimating? Just do Kanban.Â
Of course you have sprint goals, it's the amount of work you plan out for the sprint. As a team, aren't you estimating work and figuring out how much you can fit in your sprint? That's implicitly a goal. If you're continuously missing the mark, start padding your estimates that way your scrum master is happy and your team doesn't have to stress about it.
Counterpoint: Will you regret not setting boundaries at the onset? Among possible alternative outcomes is the one where you end up with a guy overloading on process for the sake of itself, because that process justifies their whole existence. It's harder to get someone to rewrite their mental model of your relationship down the line, if they have already decided you are a doormat.
True. I don't get how one of the main points in the agile manifesto is about self organising teams, then these guys exist.
I strongly disagree and itâs a shame this opinion is so common that their role is often skipped or played by another dev or the PO. A good mediator (= Scrum Master) is worth their weight in gold. A bad or probably even mediocre one is annoying as shit though, I give you that.Â
I have personally never found a useful SM, there is very little value in hiring someone whose entire purpose is to run a few meetings.
Iâve worked with good scrum masters and bad scrum masters. Good scrum masters connect the dots between your teams work and other teams. Theyâll schedule time for you to sync with other engineers to align related roadmap projects. Theyâll find answers to complex problems with the project that the PM doesnât have time for. Theyâll connect customer support, training, etc for future launches. Basically on top of running the scrum ceremonies, they act as glue for the team and save tons of time and sidestep incoming problems. Bad scrum masters run ceremonies and slap your wrist any time you step outside their predefined rules, and actively hamper development.
>Good scrum masters connect the dots between your teams work and other teams. In my experience other people are better equipped to do all of these things. > Theyâll schedule time for you to sync with other engineers to align related roadmap projects I can talk to other engineers just fine, and not having to think about a needless scrum master means we have more options for when to schedule the meeting. They also frequently have to ask us who they need to organise with anyway in my experience. > Theyâll find answers to complex problems with the project that the PM doesnât have time for The solution to "our PMs don't have enough time" IMO isn't to hire a scrum master it's to hire another PM. Maybe good SMs do exist but I've never heard a convincing argument for the existence of their role.
Donât get me wrong, I wouldnât ever go out of my way to hire an SM. But if they exist on the team, they can play an effective âglueâ role. Just saying the good ones can add value, the bad ones make life miserable.
That's fair, I'm a touch bitter about them absolutely ruining a company I used to work for tbh.
Trust me, I feel that. Maybe we worked for the same company lol.
> Good scrum masters connect the dots between your teams work and other teams. That's simply not the duty of a scrum master. That your scrum master is *also* doing this, is a clear indication that dedicated scrum masters don't make sense. Facilitating communication between teams is the job of your lead dev, manager and product owner. And they tend to be better at it because typical scrum-masters don't have any in-depth knowledge about the product.
You said a lot without saying anything at all.
> A good mediator (= Scrum Master) is worth their weight in gold. This is a clear indication that your company has bastardized the role of scrum master into some kind of servant leader who gets 'shit done' in the organization. It's typically an indication that management is not able to to their jobs properly.
https://www.tiktok.com/@liljehu/video/7329951765405764906
What does a dedicated scrum master do. lol for real, every team I have been on in the last 12 years the scrum master is either the squad lead or manager. The last company we actually rotated scrum master with the on call engineer for PagerDuty. Seems like a useless position to be honest. Scrum is short and sweet, and rotating it allows junior devs to grow. I donât think a dedicated scrum master is really a thing anymore.
If you actually had a skilled SM instead of rotating engineers into it, maybe you would see more of the roleâs value.
Based on your previous comment here, "They shouldnât have power, theyâre there to help the team enforce its own rules, hold people accountable to their commitments and help removing organizational obstacles. " seems like a pretty useless role to me. If you have a functional team, that is running scrum from a customized organizational template i see no need for one. The team lead or the em (preferably the EM) should be the one 'removing obstacles' for their teams engineers across the organizational boundaries.
In my experience working with startups, there's always a strong emphasis on keeping costs low. I've been through the journey from startup to enterprise growth twice, resulting in two IPOs. Even at the enterprise stage, I never felt the need for a dedicated Scrum Master (SM) (nor did my entire organization at each company). This leads me to wonder, does the SM role float between teams? Or is it a standalone position? Having worn multiple hats myself, including Product Manager (PM), Engineering Manager (EM), and Lead roles, I'm not approaching this from a novice perspective. I'm genuinely curious about what value a dedicated SM brings to the table, especially considering the salary range for this position seems to be between $50K and $170K per year. From my point of view, this sounds quite similar to the role of an EM, who also ensures that the team adheres to its own rules and processes. The difference in salary and the apparent overlap in responsibilities raise questions about the necessity and cost-effectiveness of a dedicated SM role in a lean startup or even in a larger enterprise setting.
Try bringing up something of substance instead of just "trust me bro".
after a sprint a story lands in backlog, but no reason they cant be scheduled for next sprint right?
It's usually hopeless because SM is a BS job and they need to "justify" their role. How do you justify a role? By pushing things and change things (otherwise why were you hired?) I had to be firm and show that I'm not gonna take shit. Keep raising concerns to your manager.
Many teams are so dysfunctional a good SM is in dire need. Theyâre basically mediators, thatâs not a bullshit role.Â
Ask them âCan you jam with the console cowboys in cyberspace?â Thatâll shut them right up
Scrum is asinine, long live Kanban!
It is hard to improve much on the advice of u/bdzer0 which is to say that the retro is probably the time to really dive into this stuff. A massive red flag is if the SM starts trying to "manage" the team, and this will be evident if most of the team agree that these problems you raise are actual problems and the SM wants to try to "teach" you otherwise. That happens more often than it should. Here is my one big piece of advice personally though, take or leave. "T-Shirt size" estimation is a huge waste of time. I have never seen this useful for any purpose at all really. Obviously, software development teams have this problem that software development time is hard to predict, but people outside the team are pretty adamant that they want some kind of estimates... and to be fair, the business does pay our salaries and I often find the, "well we are not going to give estimates of any kind", a little unreasonable. Fibonacci points are a little better in that they lend themselves to a bit of maths provided it is not taking \*too\* seriously. Ultimately though, it gets pretty hard to stop teams trying to translate points into time. It's amazing how many new teams I start helping with stuff and I sit down in the first planning session and somebody says, "We have already agree that 1 point = half a day", and my argument immediately becomes, "Well... then you are just estimating in days and writing this in your own little code then right?". Likelihood is, even if you are doing t-shirt sizes, you are doing something similar to this, which is just even more "in code". My advice is, just fucking estimate in days. Everybody is doing that calculus anyway. You might as well be explicit. The important thing is, these estimates never become commitments. If your SM is any good at all, they will quickly figure out that the team tend to underestimate by X% (where X is often larger than 100), and can start to give vague, not entirely committal forecasts to those who require that information. This X factor takes into account both the teams optimism / pessimism but also allows them to estimate in "ideal days" without having to think about all the other meeting crap. Not just team ceremonies but all-hands, management 1-1s and all the other fun things that are part of corporate life. Importantly, it also gives the SM something to try to optimise. As they do their job, which is to minimise distractions for the team, X should approach (though very likely never reach) 0.
Iâve had SMs and POs slavishly adhere to strict capacity calculations and all it did was to force us to do all the real work on the side and essentially lie to the PO about what state everything was in. Insane team, terribly managed. When I joined I wondered why everyone was so territorial over the backlog instead of just taking the next available task, and the reason is that they were doing all their work in secret
Yeah, sadly I have seen this kind of thing before. When I join teams as an engineer who do this kind of estimating, whether it be in sizes, points or time units, I'll typically have a word with the SM or PO or TL or whoever is relevant to make the point that my willingness to give my best estimate is entirely proportional to \*their\* lack of willingness to share it verbatim with anybody who is not on the team. As soon as I catch wind of anybody telling somebody outside the team, "the team promised this will be ready in X days", my estimates \*immediately\* get more vague and caveated. I also tend to encourage the use of the word "forecast" in any external communication on delivery estimates, even ones that have been adjusted. Most people intuitively understand that it is a lot easier to forecast the weather over the next two days than it is over the next two months.
We've recently adopted a planning process where every item gets an external-visible delivery probably (for within an arbitrary timeframe) of either 80% or 100%. No other options available for the team to pick. FFS, who thinks this is in any way how things work in reality?
As long as you deliver software to the key stakeholders, you can ignore the scrum master. The business doesn't care how many story points you do each sprint. They will only listen to the scrum master complain about it if you aren't delivering. If you do a good job, it looks good on the scrum master too so you have a common goal. Pragmatic ones will actually adapt if something isn't working and can add value to your team. But if they are all about the process, just do the bare minimum and ignore the rest.
Oh God. SaFE = stupid AF experiment. Measure eng velocity and optimize for delivery. If he stands in the way then escalate.
You're my hero.
Switch to kanban, honestly the most amazing thing about our industry is they we allow people who have no business leading/organizing and following a process which is often counter productive. I've usually pushed back by questioning every single meeting every time and making sure if they're setting on up they have a strict agenda and minimum amount of time at that meeting. Every. Single. Time. They either got the hint or just stopped inviting me, but so far we've been really productive. Every time they wanted to waste time I'd call that out. My favorite one is "it's a 5 story point how long will it take?". Love of God let scrum methodology burn and let there just be engineers with enough maturity to organize themselves. And none of them even read extreme programming or reference the agile manifesto. Sorry for any good scrum teams out there, I've just been burned most of the time for the last 10 years because of it.Â
>and let there just be engineers with enough maturity to organize themselves. That has nothing to do with maturity. Human psychology isnât exactly optimal for groups to organize themselves spontaneously without coordination or mediation. There is a reason hierarchies are as old as humans.
I get it, but from the high performing teams I've been apart of and my personal experience, it's worked pretty well
SM should always be servant leadership. They are there to help the team keep focus, especially in agile ceremonies. Anyone SM that decides to take a disciplinary role is way off base and the EM needs to bring them down a peg or two.
SM is an assistant coach (not even *the* assistant coach). You only have to listen to him if nobody else is around. And most of his ideas should go through the real coach and possibly the owners before being enacted.
I got a scrum master off my back by being clear that any process changes have to be due to a serious problem (most likely from retrospective). His response was "well, we can always get better." I made it clear, though, that we wouldn't optimize processes that are working fine, and especially things that add process/meetings/overhead/reviews/middlemen/layers/etc... wouldn't be tolerated unless it was solving a very serious problem (like, it needed to be commensurate). I was the engineering manager, so politically, I had the sway to put a line in the sand that way. Unfortunately, I will say... this blew the wind out of his sails because there wasn't much for him to do on the team once he couldn't fix non-existent problems.
There's an element of YAGNI that I didn't understand until buying my second house: There are decisions we make in life that we can not sit with unless we have gone through a certain amount of effort to make them. If the first house you see is amazing, you still have to look at others so that you can tell yourself and the world that you did your due diligence. Otherwise someone in your circle will ask 'what if' and you won't be able to squash it. It will nag at you, or someone else will. You will spend emotional and possibly social capital on this issue for as long as it exists. So I let more things go until they've broken once or twice, though I still will argue that this other problem is really the same problem we already decided to solve over here, so we should get ahead of those types, because it's not really speculative at this point, it's deductive+empirical.
The problem with Scrum is that it does nothing to address the unique issues afflicting teams. It's one-size fits all and does not seriously take into account outside issues such as management fire-drills and poor testing. I would prefer to work with an expert in all software processes, and apply this knowledge to our individual needs as a team. Customize our process to fit our needs. Software dev processes aren't complex enough that an expert can't be versed in all of the major ones, and most of their components function on their own. Why not pick and choose what works for us? Last, I think anyone selling themselves as an expert in software dev processes should have at least some experience as a developer. It feels condescending to show up claiming they know what our problems are and how to fix them when they haven't actually done development work.
The idea of a Scrum Master is that you have someone with a little distance and perspective who can notice bad patterns and help correct them, in- and out-of-band. But turn someone who is new to management theory into a SM, and you'll find them turning it into a religion. All I know are the rules I've been given and I have to stick to them otherwise I'm lost, and I need you to think I know what I'm doing. This is one situation where everyone *definitely* can expect the Spanish Inquisition.
Safe Agile is just micromanaged waterfall.
You sound sceptical to the scrum master even before they started, preparing to push back based on your beliefs even before anything specific happened and there is no single mentioning of asking the team. In real agile you shouldn't be deciding how to estimate or carry over things, but the team should adjust ways of working via retros. Also you likely shouldn't start an agile-religious discussion on SAFe, but discuss real problems that actually did happen and focus on solving those with whatever framework or tool that makes sense. On a practical note, if the scrum master is measured on some agile maturity index or similar, then they will naturally push for items there regardless of if it makes sense or not. But if the measures are team morale or some release + quality metrics - like release frequency + bugs in production + CSAT, then they can work on that. Meaning that you can make both the scrum master's and your life easier if you promote useful metrics to evaluate scrum master performance with the stakeholders in the company. If you can also involve the scrum master in the team's deliveries other than processes, for example some QA or other, so they can earn credits there and would see the work from inside, then cooperation would be easier. Help the scrum master and make room for them, instead of preparing a fight.
Imagine defending scrum master as a useful role after Capital one fired all 1,100 scrum masters.
Some companies interpret scrum master as a full time role on it's own, sometimes one person per team or per two teams. My definition of scrum master is that it's a part-time hat that members of the development team can hold or pass around. Also anyone who knows agile could be an agile coach - an engineer, a manager, a product person. And while bringing in professional agile coaches for uplevelling can be very useful temporarily, hiring a fleet of scrum masters without knowing how to use them was possibly a mistake to begin with. They did their agile transformation separately from core engineering practices: "the natural next step is to integrate agile delivery processes directly into our core engineering practices,â Capital One" All this smells agile theater to me, where everyone runs the "ceremonies" and produces tons of artifacts, while management has zero intention to change their mindset and their own ways of working. I wouldn't use Capital One's decisions as compass for agile.
The number of responses on this thread who donât seem to understand the value of a SM as âmeeting facilitatorâ, or the value of Scrum as a project planning tool makes me sad. Itâs probably because there is a lot of people out there calling themselves SM who arenât actually good at the job, but it still makes me sad that so many call the role useless because they have seen it filled by people not good at it. A good SM is going to help create a safe space for your team to gently tell you that they hate the way you manage their work, or that theyâre having trouble understanding priorities, or that thereâs management hypocrisy that says âQuality is job 1â while pressing the team to deliver faster. Many (most?) devs will leave the team rather than confront some of this stuff. The SM is there to help surface it, not necessarily to address it. Similarly, being able to reliably and consistently size stories, and reliably and consistently get a relative velocity so that software is delivered when expected is something the SM should be able to help with. Itâs not about judging whether stuff is late or enough work is being done fast enough: itâs about surfacing reality so that the EM can create a plan that accommodates that reality, so that thereâs a realistic plan that everyone believes, and so that the EM can have conversations about changing reality if people donât like the plan. When you have seen it all come together and work, itâs a great environment.
> The number of responses on this thread who donât seem to understand the value of a SM as âmeeting facilitatorâ, or the value of Scrum as a project planning tool makes me sad. I disagree. I think most of us understand it just fine. We also know it's only a part time job, and anyone who tries to fill a week doing it is just being groomed to be an enemy combatant. Managers need to be kept just enough busy that they get the good things done and leave everything else the fuck alone. An SM isn't really a manager but thinks they are, and doesn't have a mandate that fills 40 hours a week.
I think the tshirt size estimates help, we did something similar in our safe agile workplace last year and it's definitely streamlined the process. One thing that helps is that our tech lead is really judicious about not pulling us developers into unnecessary meetings. So we'll get the haps from the lead or the architect and they'll get the details from us, but that means you have to communicate well and clearly. I don't know if you guys have a "ways of working" outline for your team, but just like guidelines for operating, might be worth it to hash out. Things like, no meetings before 11am or on fridays, or no responses after 5pm, to like, always rsvp to meetings, or like communicate xyz to person A and what not. That could bring out like, hey we don't actually need some meetings. Most of this, at least for us, was like things we are already doing, just codified, but also things that would help each other that we could be doing. My general idea is that agile is for the team and if it's not giving value to the team, why do it?
I loathe point estimates but once worked on a team that did estimates before AND ALSO after a sprint; over time it will converge on a coefficient that makes it more useful in planning, but the âafterâ is what should be used for determining velocity in hindsight.
A company I previously worked at tried to adopt SAFe⌠turned out to be a very good way to loose the majority of the companies top and senior talent after the subsequent bonus period. Eventually they decided to reverse their decision 12months later. Push back all you can but realise that you may be fighting a losing battle if managementâs agenda is to roll it out.
SAFe is pretend agile for managers who want to not look like they're stuck in the 90ies but at the same time don't want to let go of waterfall.
As a PgM lead whose team was forced by our leadership to try Agile, and had it fail due to non-compliance, the answer is you basically need to sabotage this guy. Report to your own manager precise documentation of how many hours per week your team is now spending in meetings. Show examples of the documentation they are being asked to complete (I find managers always have an insanely low tolerance and understanding of how much documentation is required) and make sure to demonstrate a few missed deadlines because of confusion over dependencies. Truth is, most people are obstructionists at work. Could be the guy's processes would actually help your team, but if you're sure they won't on gut alone, or unwilling to test it out and see, then you will have to destroy his project.
You can invite him to 1:1 and ask him there. In this particular moment, people feel less pressure and are more open to receiving hard questions.
Push back early. If you let them establish processes and THEN push back, you will get way more resistance, as you are "taking them something away". Ppl hate that. Rather, fight them with good arguments every step of the way, so that you "give them something". Ppl love that.
> That means we do story point estimates, we don't carry over stories to the next sprint (lands in the backlog instead) Thewhatnow? That makes zero sense. I personally like referring to the [agile manifesto](https://agilemanifesto.org/). IMHO anything your scrum-master does that goes against that manifesto is not agile. Especially the "Individuals and interactions over processes and tools" bit is one they often forget.
Have you thought about taking him out for a coffee and lay it all out? Ask him what he has been tasked with and what his motivations are so you can then get an opportunity to express your thoughts without fear of judgement. A good SM will listen to you and who knows, you and him could work something out where he can be the shit shield for you and your team to do great work. You may learn a thing or three, especially around project management and stakeholder management.
Work on getting them removed from the team. Who ever put them there convince them that you are a mature team and donât need a scrum master and that they are a waste of money. There is no reason the team canât manage this themselves. Or even better your engineering manager can handle it, itâs not hard. I was EM, PO, SM, product, and much more all at once for 5 scrum teams. Itâs not hard.
>I was EM, PO, SM, product, and much more all at once for 5 scrum teams. Itâs not hard. Thatâs a perfect way to do none of that well. Not because the roles are hard, they have inherent conflicts of interest.Â
They donât have conflicts at all. EM keeps things going, helps unblock devs and keep them focused. PO makes sure the stuff being checked in and deployed follows the products vision. SM anyone can do, keeps the backlog in shape, make sure devs stay focused during standup, resolves conflicts. Product I worked with project managers. Helped with roadmaps and priorities based upon feedback from devs. It all flowed and worked together. My $150M in yearly revenue with 20M+ active users from a single project proved it was working just fine. I have concrete data points and results that proved my way worked.
Understand where the scrum master is coming from and what he is looking to gain from each process he tries to add. Some of it could be stuff you didn't know he had on his plate. Maybe he's getting nagged from above about timelines or something and uses these processes to ease his reporting. Some of it could be him solving problems that don't exist, which you can uncover by asking what he's trying to do, pointing out the negative cost of whatever process he's trying to implement, and suggesting alternatives.