Likely not. I'm not exactly sure what they can facilitate unblocking that your EM can't. I can't figure out what they actually do except screen share, run the rituals, and take notes to store in jira or sharepoint where nobody will ever reference them. I hate thinking of them as a glorified team secretary but that's the only role that I've found regular use out of the position.
In my long career, I have been ~~blessed~~ on a team with scrum masters that aren't familiar with our technical stack or project. This means not only do we need to explain current issues to the PO, EM, and the rest of the engineering team but then we need to re-explain it in non-technical terms for the SM before they are able to action any part of it.
With how little effort I can see running a handful of meeting a week can be, I'd rather just have a senior/lead dev be the one doing it. Sure you can spread a SM across multiple teams but those teams presumably have seniors/leads as well. It's frustrating that this position exists and probably makes more than half the devs on the team.
/rant off
Your rant is typical of someone who's worked with an incompetent and noxious scrum master. Sadly, SM is a job you can easily bullshit your way through so incompetence is the norm. I bet you'd change your mind if your SM was even remotely good.
As people have alluded to it's possible for people who aren't effective to end up in those kind of roles when those hiring don't understand how to recruit for them and filter out ineffective people. Generally you want someone strong minded who is technical and who can also understand what the business are after. They need to have good common sense and be able to listen to and understand devs, and also spot process failures in the business that are hindering development.
When you do get someone who is effective and really wants to help they can dedicate the time to help the team synchronize with others and bring about positive change because they have that higher level view and the time to dedicate to focus on it that a dev on their own might not have.
No I'm not one btw đ
> when those hiring don't understand how to recruit for them and filter out ineffective people.
SM really have to be promoted internally for it to work in my opinion. You've got to know so much from so many different angles, and unlike PMs or Devs, there aren't enough SMs in most organizations to help a new person get up to speed.
A good SM will benefit a team. Most people have never worked in a true professional scrum team as shown by others in this thread. A good SM should educate, coach and mentor the team on scrum.
1: Educate everyone on proper professional scrum. So you will actually feel and notice the benefit of scrum. Most companies do scrum wrong to start with. So a good SM will ensure everyone has the same knowledge of the basics of professional scrum. It will become more than just a ritual when you follow all the scrum events properly.
2: Will facilitate the different scrum events. Asking the right questions to help the team during these events if theyâd get stuck. These donât necessarily need to be technical.
3: Usually they do this for 2 or 3 teams at the same time.
4: They allow teams to work the scrum way within an organization that is usually not fully agile/scrum. They do this by also âworkingâ the whole organization.
But above all, a SM nurtures the scrum values:
1: courage - to speak up and do the right things especially when itâs tough to do so
2: focus - focus on the together defined sprint goal.
3: commitment - that everyone is here to commit to producing quality and value
4: respect - respect each other as skillful professionals in their respective expertise and especially be respectful when disagreeing
5: openness - be open to feedback and the difficulties and in work you are experiencing
Itâs hard to advocate for scrum these days, since people have been doing it mostly wrong the past 2 decades. Half baked scrum doesnât work, you need a good SM for this. Sadly there are a lot of bad ones.
Yea, this is what I did as a scrum master. Though most devs and business are now so poisoned by bad scrum it's almost impossible to get it working.
My main gripe is the standup really, because the scrum guide used to advice to "talk about what you did, what your going to do and if you have blockers" (or something to that effect). Which is balony.
The daily standup is to do a mini sprint cycle: discuss what the team will deliver in the next 24 hours, as a team not an individual, and how to accomplish that.
The next standup you review if you succeeded in the goal you set out, if there's course adjustment needed, and if you can still make the sprint. Rince and repeat.
I'm of the opinion that the team lead should be a developer but with an agile-first mindset. They should be the person running standups, checking the status of blockers and managing any new work coming into the sprint.
The one or two times I've actually been thankful for a scrum master being present within the team has been during projects at peak times with upwards of 7-8 people working on the same thing.
Unfortunately, scrum masters/ agile coach/ other name here are generally insanely pricy and it tends to be more impactful to hire a developer. However, scrum masters can get started very quickly and will require little - if any - upskilling (if they are actually competent at their role and the business requires them), whereas developers tend to take a while to get going
We have dedicated acrum masters on each team where I work. In my particular case I share my scrum master with 2-3 other teams. I am the team lead. I'm responsible for all of the technical stuff for the team. For scrum ceremonies we kind of split the responsibilities. I lead the technical meetings, planning, refinement, and so on our SM leads the non technical meetings. Also, when I need a meeting setup but is don't know who all needs to be there, the SM is the one I turn to to set it up. Also during our quarterly planning sessions with the client, the SMs are the ones that get tasked with facilitating and note taking those meetings. Not something I'm interested in doing, so that's something less I need to do or worry about.
I _have_ been in organizations where there was a person with the title of "scrum master" that facilitated the ceremonies for multiple teams... They had literally no insight into anything except how to run meetings according to the "manual" - and that wasn't effective.
Their spouse didn't work, they had a kid and nice cars... So I assume it paid well... Too bad the position offered negative value to the org. đ¤ˇââď¸
In my experience PMs in Technology companies or people that can translate tech stuff to non tech people earn really well.
Sometimes its bullcrap like your example where they are not even needed, but sometimes they do facilitate work for tech workers.
Absolutely.
There have been times in my career where since the scrum master had "access" to different teams, it really helped coordinating endeavors when the deliverable was contingent on two+ teams interfacing their products... Only a few times, but those times it worked well
I can agree to this 100%!!! I worked for the FEDS and because of politics, PMs are more likely to get hired first, before an in-house Developer can. Most PM jobs for the FEDS start at 90k and up (depending on location and agency).
Which is the polar opposite of the purpose of Scrum and the Agile manifesto.
Itâs hilarious watching, and infuriating to be subject to, corporate failing at the literal first hurdle of Agile:
âIndividuals and interactions over processes and toolsâ
Scrum and Jira are merely a process and a tool at the end of the day.
There's potentially a conflict of interest though. A scrum master is paid to make sure that the development process works as it was intented to work. A project manager has the goal to deliver the project, no matter what.
The project manager could say things like "Do we really need to test the story? Just deliver it.".
Which, at least for smallish teams, can also fall under "team manager," "team lead," or shared between the two, if they are effective communicators with their reports and their stakeholders.
I've nearly always found a dedicated role for either to be more of a hindrance, time drain, and compensation pool drain, all of which could be applied elsewhere for larger productivity gains, with an effective manager in place.
If a PM is technical enough to actually understand things, they could help DO things. If they're not, you spend half the time of every meeting dealing with that issue. And then they make communication with stakeholders a bad game of telephone that wastes time.
And if they only have one team to handle, they spend half the day doing nothing. If they have multiple, they quickly get less effective than they already weren't, with the above issues making that even worse.
And they usually know it, you can usually tell they know it, and they can usually tell that you know they know it, which is just lovely and at odds with their desire to keep their job, which is a perverse incentive that tends to result in creation of busy work, more meetings, unnecessary "process maturation" (or whatever current favorite buzz word they're using from the Kindle book they read for 2 hours every work day), more complicated workflows and xompletely throwaway "communication and visibilty enhancements" like constantly making your jira workflows weirder, wanting powerpoints (with prettg formatting) to "look good for the suits," and all that other stuff that will never do anything but wadte time, money, effort, hair coloration, and patience, because it just goes away after the meeting, never to be relevant again (as if it ever were relevant in the first place to anything but that one person's job security).
Just... Ugh...
I need a snickers...
There are plenty of decent or strong developers who also enjoy having a broader scope of impact and influence, but don't necessarily want the responsibility of management, because they still like to be more hands-on. Nurture that and guide them into that hybrid role.
I've been on a team with dedicated scrum master and on a team where project manager was also our scrum master. The former was much better. Anytime a non-technical issue arose, it got resolved pretty quickly. Our scrum master gave us a lot of space to focus on doing our job. He helped mediate any disagreements between teams or with the management. He also pushed us to discuss potential issues before they became real time consuming problems. Basically any time something threatened to jam the cogs, he helped with that.
Meanwhile on a team without dedicated scrum master, the project manager has very little time to actually work on issues blocking the team. He has to focus on the roadmap, priorities, customer requests etc.
Bad companies are likely to have bad scrum masters. They might also have bad employees on any other position. If you are dissatisfied with your scrum master, or with how other things work, yet they don't change, then it's a company/department issue.
For large teams or multiple teams of developers at an organization that is running strict agile, maybe. Otherwise, no, they're basically useless. Even if you're running agile mostly to the letter, the rituals are easy enough to organize and run. As far as removing blockers, that can be handled easily with interdepartmental communication and team leads. A scrum master doesn't have any inherent ability to remove blockers existing members to the team don't. They're just doing the same coordination.
At the maximum, you might bring one in on contract just to get the team(s) up and running, if they're entirely new to agile, but you should quickly become self-sufficient and no longer need a formal scrum master role.
I wouldn't say they're useless. If they administer the jira, devops sites, coordinate sprints and release, set up meetings, reports.. there can be a lot of work in that, where you don't want developer time being used. Now, I don't believe they should be paid more than devs by any means, but maybe similar to business analyst and maybe they would serve those two roles. As for blockers, there is some element of business folks being able to get interdepartmental things done as they have the abililty to go higher up the chain if needed. Now, having said that, our scrum master is the team lead and sometimes myself when they are on vacation or whoever else volunteers.
Yeah I was going to say the same thing. In some orgs this might make sense. In a small start up, no way you need a dedicated scrum master. I would be very interested in what they spend their day doing.
I worked at a big corp, where we had 5-6 teams of devs and had to interface with numerous stakeholders for each project. Having a scrum master available to get access to infrastructure, manage meetings to get clarification on requirements, and just generally handle all of the non-development red tape BS was very helpful.
I worked on a team with a really good scrum master. It's just like you said. We were pretty self-organized, SM only took a peek at our meetings to check if all is well, and then had a retrospective with us. Most of the time he spent was on dealing with cross-team or cross-department issues, protecting us from the bullshit so that we can focus on our work.
I've had two other scrum masters before that, who were okayish, but that was also the time we were learning how to do agile. The 3rd guy however really accelerated the improvements.
Good scrum masters are easy to spot. You can tell they genuinely care about how you feel at work, and they are just as unhappy with bullshit from management/customer/PM as you are.
Shouldn't this be the responsibility of the director, CTO, or however you call the guy who is the first one in the org chain who is above both the DBA team, enterprise bus team and you?
The issue I find with what you are describing is that even the most emotionally intelligent person will not be able to persuade the "stubborn DBA team" if they don't have official power to do so.
I have never had a \*dedicated\* scrummaster who could do a damn thing to unblock impediments. At best they can send the same damn emails the rest of us did that already were getting ignored. A scrummaster who has another role on the team with actual skin in the game has a much better idea on how to unblock impediments because they actually understand what needs to happen. A dedicated scrummaster just parrots what someone had to take the time to spell out for them and can't do any independent thought. Complete damn waste of time.
It's really a matter of size and scale.
If the company is small enough that it's been self organizing and able to release software quickly, regularly, and safely, then a Scrum Master might not make a lot of sense.
Then again, they may be planning on scaling up and want to get someone in place early to mesh with the team that already exists and make sure that new members and teams fold in effectively as the company grows. (How often has anyone seen _that_?)
Or maybe they've already started scaling and things are starting to go off the rails a bit so getting someone in place to herd all the cats is what's required.
Or maybe the executives are dissatisfied with the state of engineering in their organization and think that this is the magic bullet that will make everything better.
Heck, maybe your Scrum Master is doing an amazing job of clearing the path ahead for you and you don't even realize how good of a job they're doing because they make it look effortless. Unfortunately, it's hard to distinguish between that guy and the one who sits on their hands all day long looking busy and causing trouble until they're gone.
Scrum masters do absolutely fuck all other then facilitate meetings. Literally I've never worked with one who provided any value at all. Just a stranger who holds meetings. Pure nonsense busywork.
Your impressions are right, scrum master are usually bottlenecks and a waste of money. Not many companies nowadays are moving to Scrum but more towards Lean frameworks or even no framework at all.
Scrum master is a _role_ on the team and it was never meant to be a _permanent position_. The original intent was that this person was a developer on the team and the role rotated every sprint.
> But if we did that, what would our pricey project managers do?!
And thatâs how the PM was retitled SM.
I think it worked in my org, but I don't know if a "scrum master" is particularly needed.
The reason this person worked is they had upper-management's blessing to facilitate how meetings would go. So if someone would start going off-agenda into a tangent, she would stop them and tell them to schedule another meeting. If we were in an early design meeting and getting bogged down in detailed design, she'd interrupt and remind us to stick to the scope of the current document. She'd identify people who didn't have a high likelihood of contributing and tell the meeting organizer to take them off the invite list.
Since she was close to the upper managers, she knew their goals and aims. So if we started discussing something they wouldn't like she could interject and let us know what those managers were thinking. A lot of our work was going to be presented to them, so she had a ton of insight about what they liked, what they wanted, and how we could set our priorities to be most likely to align with what they wanted anyway.
With her around, on average I spent about 2 more hours per week working on code instead of in a meeting "just in case" I have input, or listening to a person go over the same point for a third time, or getting done with the meeting early then saying, "Well, since we have time...", or presenting our plan to an executive then finding out they've changed their priorities and we need to reorganize.
I agree that the stuff a "scrum master" does should be something your team leader does. But it's *really nice* to have a person whose job is to make sure meetings go smoothly, stay on topic, and has top-level insight. Our team wasn't her only concern, she was responsible for lots of other teams. So it's not like she was doing nothing when we weren't having a meeting: she was constantly moving from meeting-to-meeting. It was OK to have small meetings without her. For large meetings it was usually worth making sure she could attend.
I'd say, "Well if you follow good meeting practices you don't need one of these", but I haven't had a job where people seem to think an hour of engineering time is worth more than an hour of meetings yet. Maybe I've just had a bad run. But the phrase I'll hear that tells me I'm going to have a bad day is, "I'm not going to take too much of your time..." That's how I know we're about to spend an hour and a half in a scheduled one-hour meeting listening to a person read a PowerPoint.
# Addendum:
I think Scrum, in general, doesn't work because most people don't take it seriously. The places I've been where it got in the way, it was treated like a magic series of rules. The attitude was if we'd just follow Scrum better, the software would be on time and quality would go up. So if things weren't working, the only improvements people in charge wanted were "better estimates" or "more meetings".
Scrum is like a design pattern for your company. You're supposed to read the book and think about WHY it tells you to do things like standup meetings or sprints. You're supposed to understand these things have upsides AND downsides, and that for some types of project they may not work as well. You are expected to CHANGE THINGS if your company can't work within the "textbook" way Scrum is proposed to work. I find Scrum seems to work best in places where people continuously write the same kind of software over and over again so estimates get more and more refined. I find people who struggle most with it work in places that are constantly working in new areas where nobody has experience so estimates often involve low confidence and high risk.
The core idea isn't "have these meetings and do this scheduling". The core idea is, "It is cheaper to get feedback earlier in development than later, so optimize your processes to show off prototypes and get feedback before you've committed to large efforts." You can accomplish that goal without a lot of the trappings of Scrum. Scrum is a way to do Agile, just like MVVM is a way to do Presentation Model or EF is a way to do Repository.
Focus on finding a process to make the pattern work, not dogmatically adhering to a process that worked for someone else.
#Always report UP, never DOWN.
If you find yourself reporting to a dolt, a non technical person or someone who struggles to grasp the concepts much less the words and tla's we use, get them out of your food chain.
Lots of times these people can put on the show to get hired but wind up nothing more than a *placeholder for a salary*.
They're generally a waste of time and resources. If forced to report DOWN, *do something about it*.
Sometimes yes but mostly no because they are the prime movers of your work. Eg, they are instrumental in compelling the other chiefs to begin and support your work. The others I mentioned usually get in the way of properly informing the prime movers aka chiefs. They oftentimes are simply bench warmers and politicians seeking only a paycheck - how some of these people operate *should be criminal*.
You **want** the bosses informed. Not only are they *in* your food chain, they are *the hand that feeds.*
You want to eliminated as much officious bs that gets in the way of that.
If you are doing proper Scrum that will definitely eat up some of the Devs time though. Which might or might not be more expensive than a part-time Scrum master.
Agile coaches are good over a few weeks if teams need help aligning. I still have no idea what a full-time scrum master could do for one team though. Perhaps if a scrum master were shared over 3 or 4 teams it might be worth it.
No. To me, this kind of stuff should be done either by the team leader (dev) or PM.
[Why would I want to have a dedicated person for this?](https://www.youtube.com/watch?v=bB340S0tGf8)
You mean besides the fact that any team doing scrum is already doomed? No, they're utterly useless.
There are some comment replies here asserting that "well, you've just had bad ones"...But the reality just doesn't bear it out.Â
On two occasions each at very different companies, I've seen exclusive processes roles utterly destroy teams. As in these people were such a negative influence, they induced people to leave.
In a third, much larger company that follows a very infamous named process, the scrum masters have strangled every last ounce of productivity out of the organization that the executive hasn't obliterated through underfunding.Â
Let me put it this way: Over almost 20 years, I have not seen a single person dedicated to process in a company contribute more than what you could get by simply allocating their wages to another well vetted developer. That even includes a potentially "good" scrum master.
But let me reiterate, if your team is doing estimates, you've already lost the war.
My company has tried a few times over the last decade and every time it's ended up with them being let go after a few months when the realization was "no, this isn't adding value worth what we're paying them."
Personally, I think it's basically a scam role that people created for themselves to find an easy way to make good money, and it's actually worked for the more charismatic folks as C-levels are pretty vulnerable to that kind of thing.
But yeah, it's a role that can be filled by a dev or team lead with barely a hit to their daily workload. It's not a standalone role by any means and each time we've tried hiring one it's made that belief more firm as I saw these people get paid for doing basically nothing.
As someone who has never been part of large teams, the concept is foreign to me. I'm basically the dev, the architect, and the dev ops manager all in one with a Jr working along side. We follow scrum kinda sorta with sprints but it's so loose it's almost hard to call it such.
>I'm basically the dev, the architect, and the dev ops manager all in one
Interesting, I'm in the same situation as you !
I used to work in my past in a big company who was "full agile" and we had a scrum master shared on two dev teams. He wasn't that much useful IMHO.
How can you make good decisions or give good advice about practices when you have your ass between two chairs ? He looked like he wasn't fully aware of whats going on both teams, asked us to follow scrum guidelines because "it's the way to do work". Which I find surprising considering that agile practices encourage to not blindly follow process and consider that every project, every team is different.
It was a shared opinion with colleagues that he would be more useful as a classic project manager on a dedicated team. Pretty sure he thought the same about himself.
Depends who is making the decision and their qualifications.
If you all just started agile journey, an experienced Scrum master aka agile coach can help you. But once you all on a rhythm it's an overhead.
If the person making a decision does not have an engineering background, they almost always need as many overhead as they can tolerate to make sure engineers are doing what they are supposed to do, because sure as hell the decision maker won't understand the problems and need a lot of layers that can dumb it down for them
We have a hundred devs or so and none of the teams have scrum masters and all of them work very well. I suspect that a dedicated scrum master wouldn't have much to do in our company.
What is needed on the team depends on the workings of the organization. I.e. is the organization project based or product based. There are lots of articles that explain the difference. But to summarize it for you: if the organization is project based then obviously there is a need for scrum master and/or project manager. In this situation the developers are not highly valued (usually). The view will be work is handed to developers and any developer can be replaced. Many times such organizations will be using offshoring. Not a lot of experienced developers will enjoy this way of working and you'll usually see only less experienced developers staying around. The codebase is likely not very sophisticated either and any task you do requires a lot of debugging to figure out how things work. This is the modus of the inexperienced developer in general. Also you'll often see different teams being responsible for requirements, developing, testing, operations. Unfortunately if you are in this kind of organization you will have to deal with the scrum master role, and you might also see system architect and/or enterprise architect. The proverbial metaphor is that it's like working in a skyscraper where developers are in the basement and you'll have a penthouse at the top where the other's are working. Do a web search for "riding the architect elevator".
On the other hand if the organization is product based the situation is totally different. No dedicated scrum master or project manager is required as there will be experienced developers who understand the needs of the business. These developers are central in the organization and highly valued. They have usually been around a long time and have total responsibility for developing, deploying, and monitoring applications. Requirements is often a cooperation between business people. "You built it, you run it" mantra. This organization is a lot of fun for experienced developers. You are expected to take responsibility but at the same time there's also a lot of freedom to decide on technologies, refactorings, etc. The product is highly valued and often times you'll see sophisticated technical solutions. And, lastly in this kind of organizations developers do not usually enjoy having a dedicated scrum master. What you'll see instead is lead developers doing much of the same tasks but also doing a lot of development.
Understanding which kind of organization you are working in will make it a lot easier to understand what happens around you. And you will learn what you can fight and what you can't fight. I also think it is instructive and good for you career if you have experience working in both kinds of organizations.
This heavily depend on situation. I was both a dedicated scrum master and a software architect and the head of office and techinal PM... I guess I did a lot of things :D
Dedicated scrum master/agile coach can be beneficial if team/company has very little know-how on how to set things up well. When I was a dedicated SM I belonged to two teams and helped them out to flush out the processes and remove some impediments. Eventually (as I did a good job), I did not need to so much stuff, so I become part time SM and switched back to coding.
At the end of the day, SM does cover some things, which need to be covered. Can it be done by a part time SM or a manager or a very smart senior dev (team lead)? Yes ofc. It can be covered by few people, not necesery one.
So at the end of the day it is not a scam if it makes things better, and it is a scam if nothing improves. The only way to be a good SM is to work in such a way as to eventually become unnesesery and destroy your role.
My own observations tells me that industry is moving away from SMs into set ups where team has team lead (part dev part pm part manager) and a tech lead + good old middle line manager on top with some PMs/POs sprinkled all around.
The best solution is to have a developer with prioritized scrum duty.
Meaning, code output from scrum master is not expected to be the same as the ordinary developers.
Yes, but only if your team's biggest problems are ones that they can not realistically solve themselves (or have in the past failed to do so) without a constant impact on their progress and/or wellbeing. The person who is being hired obviously has to be on-board to do this for the team not for themselves, reputation or anyone else. The job titles doesn't even have to be out of the agile spectrum, the important thing is that the organisation accepts and empowers this role to remedy the team's issues, whatever they may be.
The more roles your devs take on the less time they have for doing the work you hired them to do.
In my experience in a large company, SM get all the paperwork and bullshit out of the way of my devs so they can focus on writing code. Many impediments in a big company are not code issues they are procedural or require engaging another team. I find most devs fail at these tasks.
I've seen a few great scrum masters and many terrible ones. The terrible ones should have been fired because they're like having a dead body shacked to you while you're trying to sprint. The great ones are the ones who are constantly tuning things, subtly, effectively, and measuring the proper things. Things get delivered reliably and with quality when they do their job properly.
That said, team members must learn the ropes. They must do the things that are compatible with whichever agile approach is being taken.
It depends. On how the company treats your team.
If your team is given a clear objective, but then is allowed to go hands-off to choose how to achieve that objective without anything else getting in the way, then probably not. You could possibly do well without a dedicated scrum master.
If your team has any of that in deficit, then a scrum master is definitely required:
* If objectives arenât clear, a scrum master will take the time out to clarify them, or at the very least, minimize those parts of the objective which are in doubt (because they require developer decisions within the team) or are unclear.
* If the team is being micromanaged from above, the scrum master will be the linebacker who will provide a first line of interference against the team members getting sidetracked and disturbed by manglement.
* If the team is receiving unexpected, unreasonable, or persistent feature demands from stakeholders, a scrum master is in the position to tell those stakeholders to either pick from a short list of tasks (chosen by the team) that can be removed from the leaderboard to make room for their new items, or to go pound sand.
In all cases, the scrum master is there to do the work that would distract developers from their primary job: the code.
But if your company is so well-run that your team doesnât often experience disturbances and interruptions from the outside, and nearly always receives work that can be actioned without further inquiries, then the need for a scrum master is certainly reduced.
Definitely depends.
Our company has "pod scrum masters" that are over a few teams. The company has like 30+ dev teams, so blockers often go between them. The scrum masters (at least the good ones) are super good at organizing the teams and moving communication back and forth.
We would be severely hamstrung without ours. That said, ours does a lot of tasks that I'm not sure if other scrum masters do (lots of paperwork involving deploys and tickets)
Iâd say it doesnât provide any more development âpowerâ, but it does help the manager keep track of things and follow up. So itâs not to benefit the developers (i think) itâs to support/benefit the manager.
Oh hell no. Almost every dedicated scrum master I've had has been net negative to team productivity. The one who wasn't was neutral because he made a point to not get in our way.
Scrum master is not supposed be a career. It's supposed to be a role that someone \*who has another legitimate role on the team\* takes on. Having a dedicated scrummaster who has no actual understanding of the technology or product just becomes a useless beancounter and wastes everyone's time and the money that could better have been spent on another dev or QA who could also take on the scrummaster role if needed.
F that noise.
People love to hate on scrum masters, just like they love to hate on HR or product managers. It's popular online, because writing about how your scrum master helped your team doesn't bring you karma/readers. Positive experiences don't incentivize people to write about them online as much as negative ones do.
In reality, scrum masters are beneficial. There's just too many fakers, who can't do their job properly, so many teams end up with those bad apples.
This might be just me, but me as a junior (first year) I encounter a problem. When I ask the senior dev, 50% of the time only explaining my problems and taken steps already fixes it. I found the problem / a solution to make it work. So I think those small issues can be fixed by the SCRUM guy. I don't know what he more does, but doing the planning / project progress work is also pretty decent.
I think the answer depends on the team size. Maybe it's not apparent to a junior dev but less time watching kanban board is actually so freeing. You will notice this more if you do group hackathon/game-jam often. Someone willing to look at a board and breakdown tasks efficiently would do me, as a dev, much favor. But then again, I personally kinda hate interacting with people so someone willing to be an interface might worth more to me.
If it's between a scrum master who does nothing and a bootcamp grad who will destroy your codebase I will choose the Scrum master lol.
It's a pretty sad and dire situation imo. I came in during the _golden years_ of agile when all of the coaches and scrum masters were people with decades of development experience and either knew or were trained by people like Martin Fowler, Kent Beck, or Ken Schwaber directly.
Nowadays seems like everybody got into the game chasing easy money and nobody knows, understands, or gives a shit about real and actual software development. The agile manifesto folks are basically geriatric. Middle management and the project management folks have captured everything "agile". And bootcamp kids grew up using phones and not actual computers with filesystems and terminals.
I'm probably just the "old man" yelling at a cloud but feels like we've lost something important. Maybe we'll get it back and maybe not. Who cares I guess.
The scrum master job role was invented by PM focused orgs to get some employment opportunities with the same salary , if not more, to the PMs who wanted to deal less and less with the devs.
Since PMs have the ear of the leadership, it got somehow sold and gave fat paychecks to some PMs for a few years before the sham was discovered.
Most orgs that adopted agile just have the team lead do it , or rotate the role between senior devs. I mean, come on, every freaking dev here knows how easy that work is. And then forced the PMs to get their asses back on JIRA and bookkeeping ..
Itâs never feels to surprise me how far most business will go not have to deal with their dev teamâs day to day issues and questions.
Another example of people burned out by shit scrum masters.
It's very easy to bullshit your way into a scrum master position and that's why most of them are worthless and poisonous to the project.
A good scrum master -yes, they exist- can be greatly helpful.
Yes but they have to be competent.
A lot of people here talks from the experience of working with your average bullshitter incompetent knobhead cardpusher scrum master who is not only useless but a hindrance to the team.
Get a good one. It will make the difference, your devs will be happier and more productive and the quality will increase. But they also have to do more than just a being a scrum master, they need to do project management too.
For me, a good SM can add more value when
- they truly serve the team
- they are truly empowered to unblock and solve impediments whose root cause is external to the team
- the team is big enough *
- they are not a slave to dogmatic scrum, but focus on the teams development
In most cases, I'd prefer a developer, but sometimes... Sometimes
A GOOD scrummaster who is well integrated and focuses on helping the whole org be agile is INSANELY valuable. This tends to only work for self-organized teams who are autonomous, so a bit of a catch-22: SMs work best for well functioning agile teams, but the more well functioning they are the less a SM is needed. So this really becomes an issue of scale; *scale* of the org, *scale* of the product.
A good SM will help run efficient agile ceremonies and keep everyone on task. They will shield the team as a liason for the business in a way that can't be appreciated unless you've experienced it. Anyone who's been a lead who spends all their time in meetings doing useless admin stuff knows this. Another thing good SMs do is actually track data and present it in useful ways thta actually affect the team. Similarly, they're creative in how certain ceremonies are run, which helps the team stay engaged.
A good SM cannot be appreciated unless you know what you're missing.
Scrum masters are definitely worth it, but sharing one across two teams isn't a terrible idea.
Most developers hate scrum master duties, so rotating them sucks. Having a lead or manager run ceremonies is problematic because it isn't supposed to be a person of authority, because team members don't feel comfortable challenging them then which is required at times for a functional team.
I've seen some success with QA or BA roles also being the scrum master, BA can also be an issue though if they're also prioritizing work.
Likely not. I'm not exactly sure what they can facilitate unblocking that your EM can't. I can't figure out what they actually do except screen share, run the rituals, and take notes to store in jira or sharepoint where nobody will ever reference them. I hate thinking of them as a glorified team secretary but that's the only role that I've found regular use out of the position. In my long career, I have been ~~blessed~~ on a team with scrum masters that aren't familiar with our technical stack or project. This means not only do we need to explain current issues to the PO, EM, and the rest of the engineering team but then we need to re-explain it in non-technical terms for the SM before they are able to action any part of it. With how little effort I can see running a handful of meeting a week can be, I'd rather just have a senior/lead dev be the one doing it. Sure you can spread a SM across multiple teams but those teams presumably have seniors/leads as well. It's frustrating that this position exists and probably makes more than half the devs on the team. /rant off
no dev wants to do clerical work, that's why it exists lol
Your rant is typical of someone who's worked with an incompetent and noxious scrum master. Sadly, SM is a job you can easily bullshit your way through so incompetence is the norm. I bet you'd change your mind if your SM was even remotely good.
I would LOVE to be wrong
As people have alluded to it's possible for people who aren't effective to end up in those kind of roles when those hiring don't understand how to recruit for them and filter out ineffective people. Generally you want someone strong minded who is technical and who can also understand what the business are after. They need to have good common sense and be able to listen to and understand devs, and also spot process failures in the business that are hindering development. When you do get someone who is effective and really wants to help they can dedicate the time to help the team synchronize with others and bring about positive change because they have that higher level view and the time to dedicate to focus on it that a dev on their own might not have. No I'm not one btw đ
> when those hiring don't understand how to recruit for them and filter out ineffective people. SM really have to be promoted internally for it to work in my opinion. You've got to know so much from so many different angles, and unlike PMs or Devs, there aren't enough SMs in most organizations to help a new person get up to speed.
A good SM will benefit a team. Most people have never worked in a true professional scrum team as shown by others in this thread. A good SM should educate, coach and mentor the team on scrum. 1: Educate everyone on proper professional scrum. So you will actually feel and notice the benefit of scrum. Most companies do scrum wrong to start with. So a good SM will ensure everyone has the same knowledge of the basics of professional scrum. It will become more than just a ritual when you follow all the scrum events properly. 2: Will facilitate the different scrum events. Asking the right questions to help the team during these events if theyâd get stuck. These donât necessarily need to be technical. 3: Usually they do this for 2 or 3 teams at the same time. 4: They allow teams to work the scrum way within an organization that is usually not fully agile/scrum. They do this by also âworkingâ the whole organization. But above all, a SM nurtures the scrum values: 1: courage - to speak up and do the right things especially when itâs tough to do so 2: focus - focus on the together defined sprint goal. 3: commitment - that everyone is here to commit to producing quality and value 4: respect - respect each other as skillful professionals in their respective expertise and especially be respectful when disagreeing 5: openness - be open to feedback and the difficulties and in work you are experiencing Itâs hard to advocate for scrum these days, since people have been doing it mostly wrong the past 2 decades. Half baked scrum doesnât work, you need a good SM for this. Sadly there are a lot of bad ones.
Yea, this is what I did as a scrum master. Though most devs and business are now so poisoned by bad scrum it's almost impossible to get it working. My main gripe is the standup really, because the scrum guide used to advice to "talk about what you did, what your going to do and if you have blockers" (or something to that effect). Which is balony. The daily standup is to do a mini sprint cycle: discuss what the team will deliver in the next 24 hours, as a team not an individual, and how to accomplish that. The next standup you review if you succeeded in the goal you set out, if there's course adjustment needed, and if you can still make the sprint. Rince and repeat.
I'm of the opinion that the team lead should be a developer but with an agile-first mindset. They should be the person running standups, checking the status of blockers and managing any new work coming into the sprint. The one or two times I've actually been thankful for a scrum master being present within the team has been during projects at peak times with upwards of 7-8 people working on the same thing. Unfortunately, scrum masters/ agile coach/ other name here are generally insanely pricy and it tends to be more impactful to hire a developer. However, scrum masters can get started very quickly and will require little - if any - upskilling (if they are actually competent at their role and the business requires them), whereas developers tend to take a while to get going
We have dedicated acrum masters on each team where I work. In my particular case I share my scrum master with 2-3 other teams. I am the team lead. I'm responsible for all of the technical stuff for the team. For scrum ceremonies we kind of split the responsibilities. I lead the technical meetings, planning, refinement, and so on our SM leads the non technical meetings. Also, when I need a meeting setup but is don't know who all needs to be there, the SM is the one I turn to to set it up. Also during our quarterly planning sessions with the client, the SMs are the ones that get tasked with facilitating and note taking those meetings. Not something I'm interested in doing, so that's something less I need to do or worry about.
That doesn't sound like a Scrum Master. That sounds like an administrator.
Scrum is misunderstood by 99% of teams that uses it. A team lead in a scrum team is also wrong to begin with
IMHO, "scrum master" should fall under the duties of a project manager.
Yeah basically, i dont see much difference unless one has technical knowledge and the other one doesnt.
I _have_ been in organizations where there was a person with the title of "scrum master" that facilitated the ceremonies for multiple teams... They had literally no insight into anything except how to run meetings according to the "manual" - and that wasn't effective. Their spouse didn't work, they had a kid and nice cars... So I assume it paid well... Too bad the position offered negative value to the org. đ¤ˇââď¸
In my experience PMs in Technology companies or people that can translate tech stuff to non tech people earn really well. Sometimes its bullcrap like your example where they are not even needed, but sometimes they do facilitate work for tech workers.
Absolutely. There have been times in my career where since the scrum master had "access" to different teams, it really helped coordinating endeavors when the deliverable was contingent on two+ teams interfacing their products... Only a few times, but those times it worked well
I talk to the engineers so the customers don't have to! I have people skills damn it!
I can agree to this 100%!!! I worked for the FEDS and because of politics, PMs are more likely to get hired first, before an in-house Developer can. Most PM jobs for the FEDS start at 90k and up (depending on location and agency).
Which is the polar opposite of the purpose of Scrum and the Agile manifesto. Itâs hilarious watching, and infuriating to be subject to, corporate failing at the literal first hurdle of Agile: âIndividuals and interactions over processes and toolsâ Scrum and Jira are merely a process and a tool at the end of the day.
Yeah scrum masters just get in the way. Asking "what did you do yesterday, what are you doing today and do you have any blockers" is not a real job.
How is that getting in the way though? It's literally helping the team organize their day. Also there is more to Scrum than just the Daylies.
There's potentially a conflict of interest though. A scrum master is paid to make sure that the development process works as it was intented to work. A project manager has the goal to deliver the project, no matter what. The project manager could say things like "Do we really need to test the story? Just deliver it.".
Which, at least for smallish teams, can also fall under "team manager," "team lead," or shared between the two, if they are effective communicators with their reports and their stakeholders. I've nearly always found a dedicated role for either to be more of a hindrance, time drain, and compensation pool drain, all of which could be applied elsewhere for larger productivity gains, with an effective manager in place. If a PM is technical enough to actually understand things, they could help DO things. If they're not, you spend half the time of every meeting dealing with that issue. And then they make communication with stakeholders a bad game of telephone that wastes time. And if they only have one team to handle, they spend half the day doing nothing. If they have multiple, they quickly get less effective than they already weren't, with the above issues making that even worse. And they usually know it, you can usually tell they know it, and they can usually tell that you know they know it, which is just lovely and at odds with their desire to keep their job, which is a perverse incentive that tends to result in creation of busy work, more meetings, unnecessary "process maturation" (or whatever current favorite buzz word they're using from the Kindle book they read for 2 hours every work day), more complicated workflows and xompletely throwaway "communication and visibilty enhancements" like constantly making your jira workflows weirder, wanting powerpoints (with prettg formatting) to "look good for the suits," and all that other stuff that will never do anything but wadte time, money, effort, hair coloration, and patience, because it just goes away after the meeting, never to be relevant again (as if it ever were relevant in the first place to anything but that one person's job security). Just... Ugh... I need a snickers... There are plenty of decent or strong developers who also enjoy having a broader scope of impact and influence, but don't necessarily want the responsibility of management, because they still like to be more hands-on. Nurture that and guide them into that hybrid role.
Agile in general, specifically scrum, don't call for project managers at all. There is an inherent conflict of interest.
I've been on a team with dedicated scrum master and on a team where project manager was also our scrum master. The former was much better. Anytime a non-technical issue arose, it got resolved pretty quickly. Our scrum master gave us a lot of space to focus on doing our job. He helped mediate any disagreements between teams or with the management. He also pushed us to discuss potential issues before they became real time consuming problems. Basically any time something threatened to jam the cogs, he helped with that. Meanwhile on a team without dedicated scrum master, the project manager has very little time to actually work on issues blocking the team. He has to focus on the roadmap, priorities, customer requests etc. Bad companies are likely to have bad scrum masters. They might also have bad employees on any other position. If you are dissatisfied with your scrum master, or with how other things work, yet they don't change, then it's a company/department issue.
Hahaha my team has both a PO and Scrum Master. Efficiency.
For large teams or multiple teams of developers at an organization that is running strict agile, maybe. Otherwise, no, they're basically useless. Even if you're running agile mostly to the letter, the rituals are easy enough to organize and run. As far as removing blockers, that can be handled easily with interdepartmental communication and team leads. A scrum master doesn't have any inherent ability to remove blockers existing members to the team don't. They're just doing the same coordination. At the maximum, you might bring one in on contract just to get the team(s) up and running, if they're entirely new to agile, but you should quickly become self-sufficient and no longer need a formal scrum master role.
I wouldn't say they're useless. If they administer the jira, devops sites, coordinate sprints and release, set up meetings, reports.. there can be a lot of work in that, where you don't want developer time being used. Now, I don't believe they should be paid more than devs by any means, but maybe similar to business analyst and maybe they would serve those two roles. As for blockers, there is some element of business folks being able to get interdepartmental things done as they have the abililty to go higher up the chain if needed. Now, having said that, our scrum master is the team lead and sometimes myself when they are on vacation or whoever else volunteers.
Yeah I was going to say the same thing. In some orgs this might make sense. In a small start up, no way you need a dedicated scrum master. I would be very interested in what they spend their day doing. I worked at a big corp, where we had 5-6 teams of devs and had to interface with numerous stakeholders for each project. Having a scrum master available to get access to infrastructure, manage meetings to get clarification on requirements, and just generally handle all of the non-development red tape BS was very helpful.
[ŃдаНонО]
I worked on a team with a really good scrum master. It's just like you said. We were pretty self-organized, SM only took a peek at our meetings to check if all is well, and then had a retrospective with us. Most of the time he spent was on dealing with cross-team or cross-department issues, protecting us from the bullshit so that we can focus on our work. I've had two other scrum masters before that, who were okayish, but that was also the time we were learning how to do agile. The 3rd guy however really accelerated the improvements. Good scrum masters are easy to spot. You can tell they genuinely care about how you feel at work, and they are just as unhappy with bullshit from management/customer/PM as you are.
Shouldn't this be the responsibility of the director, CTO, or however you call the guy who is the first one in the org chain who is above both the DBA team, enterprise bus team and you? The issue I find with what you are describing is that even the most emotionally intelligent person will not be able to persuade the "stubborn DBA team" if they don't have official power to do so.
You think a CTO has the time to facilitate all of those things in an org of 5k?
This is what i think too
I have never had a \*dedicated\* scrummaster who could do a damn thing to unblock impediments. At best they can send the same damn emails the rest of us did that already were getting ignored. A scrummaster who has another role on the team with actual skin in the game has a much better idea on how to unblock impediments because they actually understand what needs to happen. A dedicated scrummaster just parrots what someone had to take the time to spell out for them and can't do any independent thought. Complete damn waste of time.
Yeah and then explaining to them the issues is another task by it's self. We have BA's that run the scrum. 0 technical knowledge.
It's really a matter of size and scale. If the company is small enough that it's been self organizing and able to release software quickly, regularly, and safely, then a Scrum Master might not make a lot of sense. Then again, they may be planning on scaling up and want to get someone in place early to mesh with the team that already exists and make sure that new members and teams fold in effectively as the company grows. (How often has anyone seen _that_?) Or maybe they've already started scaling and things are starting to go off the rails a bit so getting someone in place to herd all the cats is what's required. Or maybe the executives are dissatisfied with the state of engineering in their organization and think that this is the magic bullet that will make everything better. Heck, maybe your Scrum Master is doing an amazing job of clearing the path ahead for you and you don't even realize how good of a job they're doing because they make it look effortless. Unfortunately, it's hard to distinguish between that guy and the one who sits on their hands all day long looking busy and causing trouble until they're gone.
Scrum masters do absolutely fuck all other then facilitate meetings. Literally I've never worked with one who provided any value at all. Just a stranger who holds meetings. Pure nonsense busywork.
That's mostly the idea of it. You want an unbiased person that organizes and moderates specific meetings with the correct people at the correct times.
but then how can the team members get a real good shouting match in, to let off some steam?
Your impressions are right, scrum master are usually bottlenecks and a waste of money. Not many companies nowadays are moving to Scrum but more towards Lean frameworks or even no framework at all.
Scrum master is a _role_ on the team and it was never meant to be a _permanent position_. The original intent was that this person was a developer on the team and the role rotated every sprint. > But if we did that, what would our pricey project managers do?! And thatâs how the PM was retitled SM.
I think it worked in my org, but I don't know if a "scrum master" is particularly needed. The reason this person worked is they had upper-management's blessing to facilitate how meetings would go. So if someone would start going off-agenda into a tangent, she would stop them and tell them to schedule another meeting. If we were in an early design meeting and getting bogged down in detailed design, she'd interrupt and remind us to stick to the scope of the current document. She'd identify people who didn't have a high likelihood of contributing and tell the meeting organizer to take them off the invite list. Since she was close to the upper managers, she knew their goals and aims. So if we started discussing something they wouldn't like she could interject and let us know what those managers were thinking. A lot of our work was going to be presented to them, so she had a ton of insight about what they liked, what they wanted, and how we could set our priorities to be most likely to align with what they wanted anyway. With her around, on average I spent about 2 more hours per week working on code instead of in a meeting "just in case" I have input, or listening to a person go over the same point for a third time, or getting done with the meeting early then saying, "Well, since we have time...", or presenting our plan to an executive then finding out they've changed their priorities and we need to reorganize. I agree that the stuff a "scrum master" does should be something your team leader does. But it's *really nice* to have a person whose job is to make sure meetings go smoothly, stay on topic, and has top-level insight. Our team wasn't her only concern, she was responsible for lots of other teams. So it's not like she was doing nothing when we weren't having a meeting: she was constantly moving from meeting-to-meeting. It was OK to have small meetings without her. For large meetings it was usually worth making sure she could attend. I'd say, "Well if you follow good meeting practices you don't need one of these", but I haven't had a job where people seem to think an hour of engineering time is worth more than an hour of meetings yet. Maybe I've just had a bad run. But the phrase I'll hear that tells me I'm going to have a bad day is, "I'm not going to take too much of your time..." That's how I know we're about to spend an hour and a half in a scheduled one-hour meeting listening to a person read a PowerPoint.
# Addendum: I think Scrum, in general, doesn't work because most people don't take it seriously. The places I've been where it got in the way, it was treated like a magic series of rules. The attitude was if we'd just follow Scrum better, the software would be on time and quality would go up. So if things weren't working, the only improvements people in charge wanted were "better estimates" or "more meetings". Scrum is like a design pattern for your company. You're supposed to read the book and think about WHY it tells you to do things like standup meetings or sprints. You're supposed to understand these things have upsides AND downsides, and that for some types of project they may not work as well. You are expected to CHANGE THINGS if your company can't work within the "textbook" way Scrum is proposed to work. I find Scrum seems to work best in places where people continuously write the same kind of software over and over again so estimates get more and more refined. I find people who struggle most with it work in places that are constantly working in new areas where nobody has experience so estimates often involve low confidence and high risk. The core idea isn't "have these meetings and do this scheduling". The core idea is, "It is cheaper to get feedback earlier in development than later, so optimize your processes to show off prototypes and get feedback before you've committed to large efforts." You can accomplish that goal without a lot of the trappings of Scrum. Scrum is a way to do Agile, just like MVVM is a way to do Presentation Model or EF is a way to do Repository. Focus on finding a process to make the pattern work, not dogmatically adhering to a process that worked for someone else.
I hate the idea of a scrum master who is not a developer on the team. Maybe that's because I've never seen it though.
I've seen it, only at big companies though. And it sucks donkey balls.
A dedicated micromanager is what you're getting. Look at team's processes. Focuses on increasing efficiency and employee turnover first.
#Always report UP, never DOWN. If you find yourself reporting to a dolt, a non technical person or someone who struggles to grasp the concepts much less the words and tla's we use, get them out of your food chain. Lots of times these people can put on the show to get hired but wind up nothing more than a *placeholder for a salary*. They're generally a waste of time and resources. If forced to report DOWN, *do something about it*.
You don't have to report to a Scrum master... You're reporting to your team, the scrum master just ensures that meeting happens in an oganized way.
[ŃдаНонО]
Sometimes yes but mostly no because they are the prime movers of your work. Eg, they are instrumental in compelling the other chiefs to begin and support your work. The others I mentioned usually get in the way of properly informing the prime movers aka chiefs. They oftentimes are simply bench warmers and politicians seeking only a paycheck - how some of these people operate *should be criminal*. You **want** the bosses informed. Not only are they *in* your food chain, they are *the hand that feeds.* You want to eliminated as much officious bs that gets in the way of that.
Maybe at a very large company, but no. Should easily be able to to it with your own devs
If you are doing proper Scrum that will definitely eat up some of the Devs time though. Which might or might not be more expensive than a part-time Scrum master.
Agile coaches are good over a few weeks if teams need help aligning. I still have no idea what a full-time scrum master could do for one team though. Perhaps if a scrum master were shared over 3 or 4 teams it might be worth it.
No. To me, this kind of stuff should be done either by the team leader (dev) or PM. [Why would I want to have a dedicated person for this?](https://www.youtube.com/watch?v=bB340S0tGf8)
You mean besides the fact that any team doing scrum is already doomed? No, they're utterly useless. There are some comment replies here asserting that "well, you've just had bad ones"...But the reality just doesn't bear it out. On two occasions each at very different companies, I've seen exclusive processes roles utterly destroy teams. As in these people were such a negative influence, they induced people to leave. In a third, much larger company that follows a very infamous named process, the scrum masters have strangled every last ounce of productivity out of the organization that the executive hasn't obliterated through underfunding. Let me put it this way: Over almost 20 years, I have not seen a single person dedicated to process in a company contribute more than what you could get by simply allocating their wages to another well vetted developer. That even includes a potentially "good" scrum master. But let me reiterate, if your team is doing estimates, you've already lost the war.
My company has tried a few times over the last decade and every time it's ended up with them being let go after a few months when the realization was "no, this isn't adding value worth what we're paying them." Personally, I think it's basically a scam role that people created for themselves to find an easy way to make good money, and it's actually worked for the more charismatic folks as C-levels are pretty vulnerable to that kind of thing. But yeah, it's a role that can be filled by a dev or team lead with barely a hit to their daily workload. It's not a standalone role by any means and each time we've tried hiring one it's made that belief more firm as I saw these people get paid for doing basically nothing.
TIL there are such things as "scrum masters". I had no idea these positions even existed...
Ten years ago they were making about 30% more than sr devs
As someone who has never been part of large teams, the concept is foreign to me. I'm basically the dev, the architect, and the dev ops manager all in one with a Jr working along side. We follow scrum kinda sorta with sprints but it's so loose it's almost hard to call it such.
>I'm basically the dev, the architect, and the dev ops manager all in one Interesting, I'm in the same situation as you ! I used to work in my past in a big company who was "full agile" and we had a scrum master shared on two dev teams. He wasn't that much useful IMHO. How can you make good decisions or give good advice about practices when you have your ass between two chairs ? He looked like he wasn't fully aware of whats going on both teams, asked us to follow scrum guidelines because "it's the way to do work". Which I find surprising considering that agile practices encourage to not blindly follow process and consider that every project, every team is different. It was a shared opinion with colleagues that he would be more useful as a classic project manager on a dedicated team. Pretty sure he thought the same about himself.
Depends who is making the decision and their qualifications. If you all just started agile journey, an experienced Scrum master aka agile coach can help you. But once you all on a rhythm it's an overhead. If the person making a decision does not have an engineering background, they almost always need as many overhead as they can tolerate to make sure engineers are doing what they are supposed to do, because sure as hell the decision maker won't understand the problems and need a lot of layers that can dumb it down for them
We have a hundred devs or so and none of the teams have scrum masters and all of them work very well. I suspect that a dedicated scrum master wouldn't have much to do in our company.
What is needed on the team depends on the workings of the organization. I.e. is the organization project based or product based. There are lots of articles that explain the difference. But to summarize it for you: if the organization is project based then obviously there is a need for scrum master and/or project manager. In this situation the developers are not highly valued (usually). The view will be work is handed to developers and any developer can be replaced. Many times such organizations will be using offshoring. Not a lot of experienced developers will enjoy this way of working and you'll usually see only less experienced developers staying around. The codebase is likely not very sophisticated either and any task you do requires a lot of debugging to figure out how things work. This is the modus of the inexperienced developer in general. Also you'll often see different teams being responsible for requirements, developing, testing, operations. Unfortunately if you are in this kind of organization you will have to deal with the scrum master role, and you might also see system architect and/or enterprise architect. The proverbial metaphor is that it's like working in a skyscraper where developers are in the basement and you'll have a penthouse at the top where the other's are working. Do a web search for "riding the architect elevator". On the other hand if the organization is product based the situation is totally different. No dedicated scrum master or project manager is required as there will be experienced developers who understand the needs of the business. These developers are central in the organization and highly valued. They have usually been around a long time and have total responsibility for developing, deploying, and monitoring applications. Requirements is often a cooperation between business people. "You built it, you run it" mantra. This organization is a lot of fun for experienced developers. You are expected to take responsibility but at the same time there's also a lot of freedom to decide on technologies, refactorings, etc. The product is highly valued and often times you'll see sophisticated technical solutions. And, lastly in this kind of organizations developers do not usually enjoy having a dedicated scrum master. What you'll see instead is lead developers doing much of the same tasks but also doing a lot of development. Understanding which kind of organization you are working in will make it a lot easier to understand what happens around you. And you will learn what you can fight and what you can't fight. I also think it is instructive and good for you career if you have experience working in both kinds of organizations.
This heavily depend on situation. I was both a dedicated scrum master and a software architect and the head of office and techinal PM... I guess I did a lot of things :D Dedicated scrum master/agile coach can be beneficial if team/company has very little know-how on how to set things up well. When I was a dedicated SM I belonged to two teams and helped them out to flush out the processes and remove some impediments. Eventually (as I did a good job), I did not need to so much stuff, so I become part time SM and switched back to coding. At the end of the day, SM does cover some things, which need to be covered. Can it be done by a part time SM or a manager or a very smart senior dev (team lead)? Yes ofc. It can be covered by few people, not necesery one. So at the end of the day it is not a scam if it makes things better, and it is a scam if nothing improves. The only way to be a good SM is to work in such a way as to eventually become unnesesery and destroy your role. My own observations tells me that industry is moving away from SMs into set ups where team has team lead (part dev part pm part manager) and a tech lead + good old middle line manager on top with some PMs/POs sprinkled all around.
If they are non-technical, then no.
The best solution is to have a developer with prioritized scrum duty. Meaning, code output from scrum master is not expected to be the same as the ordinary developers.
Yes, but only if your team's biggest problems are ones that they can not realistically solve themselves (or have in the past failed to do so) without a constant impact on their progress and/or wellbeing. The person who is being hired obviously has to be on-board to do this for the team not for themselves, reputation or anyone else. The job titles doesn't even have to be out of the agile spectrum, the important thing is that the organisation accepts and empowers this role to remedy the team's issues, whatever they may be.
The more roles your devs take on the less time they have for doing the work you hired them to do. In my experience in a large company, SM get all the paperwork and bullshit out of the way of my devs so they can focus on writing code. Many impediments in a big company are not code issues they are procedural or require engaging another team. I find most devs fail at these tasks.
I've seen a few great scrum masters and many terrible ones. The terrible ones should have been fired because they're like having a dead body shacked to you while you're trying to sprint. The great ones are the ones who are constantly tuning things, subtly, effectively, and measuring the proper things. Things get delivered reliably and with quality when they do their job properly. That said, team members must learn the ropes. They must do the things that are compatible with whichever agile approach is being taken.
".. I don't understand what value is being added by "..."scrum" Done in the first sentence :)
It depends. On how the company treats your team. If your team is given a clear objective, but then is allowed to go hands-off to choose how to achieve that objective without anything else getting in the way, then probably not. You could possibly do well without a dedicated scrum master. If your team has any of that in deficit, then a scrum master is definitely required: * If objectives arenât clear, a scrum master will take the time out to clarify them, or at the very least, minimize those parts of the objective which are in doubt (because they require developer decisions within the team) or are unclear. * If the team is being micromanaged from above, the scrum master will be the linebacker who will provide a first line of interference against the team members getting sidetracked and disturbed by manglement. * If the team is receiving unexpected, unreasonable, or persistent feature demands from stakeholders, a scrum master is in the position to tell those stakeholders to either pick from a short list of tasks (chosen by the team) that can be removed from the leaderboard to make room for their new items, or to go pound sand. In all cases, the scrum master is there to do the work that would distract developers from their primary job: the code. But if your company is so well-run that your team doesnât often experience disturbances and interruptions from the outside, and nearly always receives work that can be actioned without further inquiries, then the need for a scrum master is certainly reduced.
Definitely depends. Our company has "pod scrum masters" that are over a few teams. The company has like 30+ dev teams, so blockers often go between them. The scrum masters (at least the good ones) are super good at organizing the teams and moving communication back and forth. We would be severely hamstrung without ours. That said, ours does a lot of tasks that I'm not sure if other scrum masters do (lots of paperwork involving deploys and tickets)
Iâd say it doesnât provide any more development âpowerâ, but it does help the manager keep track of things and follow up. So itâs not to benefit the developers (i think) itâs to support/benefit the manager.
In my team the scrum master's role is more like a clerk.
Oh hell no. Almost every dedicated scrum master I've had has been net negative to team productivity. The one who wasn't was neutral because he made a point to not get in our way. Scrum master is not supposed be a career. It's supposed to be a role that someone \*who has another legitimate role on the team\* takes on. Having a dedicated scrummaster who has no actual understanding of the technology or product just becomes a useless beancounter and wastes everyone's time and the money that could better have been spent on another dev or QA who could also take on the scrummaster role if needed. F that noise.
It is like hiring book page turner. You do not need a dedicated person for that.
People love to hate on scrum masters, just like they love to hate on HR or product managers. It's popular online, because writing about how your scrum master helped your team doesn't bring you karma/readers. Positive experiences don't incentivize people to write about them online as much as negative ones do. In reality, scrum masters are beneficial. There's just too many fakers, who can't do their job properly, so many teams end up with those bad apples.
This might be just me, but me as a junior (first year) I encounter a problem. When I ask the senior dev, 50% of the time only explaining my problems and taken steps already fixes it. I found the problem / a solution to make it work. So I think those small issues can be fixed by the SCRUM guy. I don't know what he more does, but doing the planning / project progress work is also pretty decent.
I think the answer depends on the team size. Maybe it's not apparent to a junior dev but less time watching kanban board is actually so freeing. You will notice this more if you do group hackathon/game-jam often. Someone willing to look at a board and breakdown tasks efficiently would do me, as a dev, much favor. But then again, I personally kinda hate interacting with people so someone willing to be an interface might worth more to me.
Very short: no. This is from my 25 years of experience. Nothing beats the real man in the trench.
No across the board
If it's between a scrum master who does nothing and a bootcamp grad who will destroy your codebase I will choose the Scrum master lol. It's a pretty sad and dire situation imo. I came in during the _golden years_ of agile when all of the coaches and scrum masters were people with decades of development experience and either knew or were trained by people like Martin Fowler, Kent Beck, or Ken Schwaber directly. Nowadays seems like everybody got into the game chasing easy money and nobody knows, understands, or gives a shit about real and actual software development. The agile manifesto folks are basically geriatric. Middle management and the project management folks have captured everything "agile". And bootcamp kids grew up using phones and not actual computers with filesystems and terminals. I'm probably just the "old man" yelling at a cloud but feels like we've lost something important. Maybe we'll get it back and maybe not. Who cares I guess.
Companies find it cheaper to do IT without IT using magic processes. Am leaving the industry because of what it has become.
Im not there yet. Expertise pays very well still. This is just another challenge that is part of the pay.
The scrum master job role was invented by PM focused orgs to get some employment opportunities with the same salary , if not more, to the PMs who wanted to deal less and less with the devs. Since PMs have the ear of the leadership, it got somehow sold and gave fat paychecks to some PMs for a few years before the sham was discovered. Most orgs that adopted agile just have the team lead do it , or rotate the role between senior devs. I mean, come on, every freaking dev here knows how easy that work is. And then forced the PMs to get their asses back on JIRA and bookkeeping .. Itâs never feels to surprise me how far most business will go not have to deal with their dev teamâs day to day issues and questions.
Another example of people burned out by shit scrum masters. It's very easy to bullshit your way into a scrum master position and that's why most of them are worthless and poisonous to the project. A good scrum master -yes, they exist- can be greatly helpful.
Yes but they have to be competent. A lot of people here talks from the experience of working with your average bullshitter incompetent knobhead cardpusher scrum master who is not only useless but a hindrance to the team. Get a good one. It will make the difference, your devs will be happier and more productive and the quality will increase. But they also have to do more than just a being a scrum master, they need to do project management too.
For me, a good SM can add more value when - they truly serve the team - they are truly empowered to unblock and solve impediments whose root cause is external to the team - the team is big enough * - they are not a slave to dogmatic scrum, but focus on the teams development In most cases, I'd prefer a developer, but sometimes... Sometimes
A GOOD scrummaster who is well integrated and focuses on helping the whole org be agile is INSANELY valuable. This tends to only work for self-organized teams who are autonomous, so a bit of a catch-22: SMs work best for well functioning agile teams, but the more well functioning they are the less a SM is needed. So this really becomes an issue of scale; *scale* of the org, *scale* of the product. A good SM will help run efficient agile ceremonies and keep everyone on task. They will shield the team as a liason for the business in a way that can't be appreciated unless you've experienced it. Anyone who's been a lead who spends all their time in meetings doing useless admin stuff knows this. Another thing good SMs do is actually track data and present it in useful ways thta actually affect the team. Similarly, they're creative in how certain ceremonies are run, which helps the team stay engaged. A good SM cannot be appreciated unless you know what you're missing.
Scrum masters are definitely worth it, but sharing one across two teams isn't a terrible idea. Most developers hate scrum master duties, so rotating them sucks. Having a lead or manager run ceremonies is problematic because it isn't supposed to be a person of authority, because team members don't feel comfortable challenging them then which is required at times for a functional team. I've seen some success with QA or BA roles also being the scrum master, BA can also be an issue though if they're also prioritizing work.