Related Posts
Need Likes !
Additional Posts in Tech
FAANG written in order of tier, go.
I need a career mentor for the tech industry!!!
New to Fishbowl?
Download the Fishbowl app to
unlock all discussions on Fishbowl.
unlock all discussions on Fishbowl.



Chief
Uh no. Scrum is a thankless glorified project manager just like all the other variations of program/project manager. They have to do a job nobody wants, with little job security since their job is a luxury, not a necessity, and they have little to no actual power.
But sure, blame them for the layoffs.
I beg to differ with you. First, Scrum has got nothing to do with a project manager. Scrum Master has no authority in any decision making during the project. Next, PMs has a great role in orchestrating the project team, who has a bigger picture in mind and can take appropriate corrective action if a project is being derailed. Sorry that you have such a small thought about PMs.
That’s a pretty strong take! I’ve seen how Scrum can be misused, but it’s also helped teams stay focused and deliver value faster when managed properly. It's all about the execution and culture—if it's turning toxic, that’s a sign of bigger management issues, not the framework itself. IMHO
100% - I have seen versions of scrum/agile save projects. I've also seen it add useless overhead. It's a tool - how you use it is up to you.
Astoundingly immature take from a Senior Software Engineer.
As a methodology, it allows for an extremely measured path through software development projects. When used right, scrum/agile can be a protective approach to avoid engineer burnout, and deliver on a known and accepted schedule.
For Automation ENG 1, re-read the original post. That's an immature take. How does someone become a Senior dev with an assumption that SCRUM is a bean counters job to "narc and snitch"? That's immature.
Cynical, sure. Outstandingly immature.
And for Costco Wholesale 1, you think I've never been on a scrum team? I learned scrum from Ken Schwaber back in 2000. I've used scrum on many teams as lead dev and dev manager. I've implemented scrum into several difference companies. I guess somewhere along the line I've just neglected the "narc and snitch" duties
To add, Scrum coaches are usually the first to be laid off.
Rising Star
100%. Many - not all - are useless manipulators. Scrum/Agile is a huge part of the reasons working conditions in tech have deteriorated
Spoken just like someone who has no idea how much worse things were *before* Scrum came along. Working conditions in tech are waaaaaaay better than they were when Waterfall was the only methodology available. All processes and methodologies can be implemented well or badly, and blaming the methodology when it is used badly makes absolutely no sense at all.
I have also seen it used nefariously.
However, what methods and tools are better where this could not also happen?
If someone is going to burn you, they’re going to do it regardless.
Scrum was developed to deal with the lack of qualified software professionals willing to be employed and extremely underpaid.All SL should have fought against but most aren’t to intelligent, it similar to peer to peer programming was developed because hardware was so expensive someone convinced others, wrote a book on the subject and people followed until it was failing and hardware got cheaper… I don’t understand why Reality is hard to understand.
Scrum only will work if you are a true SAAS designed product from the ground up… not a legacy company trying to buy products to create a larger portfolio with 100 different silos and processes
Maybe I should write a book on this. Seems anyone can do that and easily find sheep to follow…
Ouch!
But, I get it. I think the scrum master role is the most wildly interpreted role in most industries, and because of that, can become a weapon. I also think scrum masters tend to end up as chameleons of their environment, and will adapt to the culture of the organization they're part of as a survival mechanism. If the culture is poor, so can be the attitudes and usages of any team member. But, as others have pointed out here, we're generally first up when layoffs come. (Hello, from a currently laid-off SM :) )
I am certain your observations are valid for what you have experienced, and I'm truly sorry for that. In an organization with better culture, SMs are supposed to be much different. We prefer to be a force multiplier, owning the responsibility for squashing the non-technical roadblocks technical teammates shouldn't have to worry about, while seeking growth opportunities for each individual on the team. A great SM empowered for positivity and growth can do great things.
Hope today is going better for you!
Wish you were on my team
I saw someone else post something similar. Scrum is a tool that is only as good as it's implemented. I have worked for companies that "claim" they were "agile scrum" but threw it out the window the moment that timeframes / deadlines would be compromised. I have also worked for companies that implemented it very well. When I was first introduced to Scrum I was extremely skeptical and thought similarly that it was a "big brother" move to try and squeeze more work out of us software engineers. However after working for a company that implemented it very well, I found that Scrum "can" (notice I did not say "will" because again, it depends on how it's used) but "can" empower the "worker bees" to manage their own priorities and timeframes. It's much better to get time estimates from the people that actually do the work than from some "project manager" that might have taken one programming class as a college requirement telling you "when it should get done". I have had both positive and negative experiences from Scrum. Scrum can't make bad companies better... if a company is alread bad at its core, then they are probably going to implement Scrum poorly. Odds are the people that have shared negative experiences with Scrum were probably working for a bad company to begin with.
Story points are used to measure velocity. Once the team has a stable velocity the team is better at predicting how much work they can commit to in a sprint. Velocity along with capacity helps to create a timeline of when the work is expected to get done. Story points should not be used to measure someone’s performance.
I think you mean the scrum master role? In my experience, the most effective teams rotate the scrum master role between devs on the team. This person facilitates the daily huddle where everyone (including the product manager) reports out on progress, challenges, dependencies, etc. They also facilitate sprint planning where devs pick up work that’s been prioritized in the backlog. When done well, the role creates an element of peer accountability that drives quality and performance through transparency and trust. It’s also an opportunity for engineers to develop their facilitation skills, which can be helpful for those looking to eventually move into leadership.
What creates tension is when there’s a (real or perceived) power gap between the scrum master and others on the team. This dynamic often makes it feel like work is being pushed rather than pulled, which contradicts agile fundamentals.
A scrum coach’s role should be to train teams in how to structure work items so that there is a focus on delivering value, how to plan sprints in a way that is realistic and practical, and how to track progress so that the team can predict velocity for upcoming work.
Yeah, so this is a bad idea. When engineers report progress to a PM, they tend to dumb down their comments and gloss over aspects that should spark conversations with others on the team. Of course, there are other ways of improving the team dynamic, but it will likely be much better very quickly if huddles and sprint planning are facilitated by an engineer.
No. You just clearly don't know the first thing about Scrum, or you've seen bad behaviors labeled as Scrum that have nothing to do with it.
Seriously? You probably think the rule of 40 is anything more than something Bessemer Venture Partners made up during a meeting to justify a mistake…or Brad Feld didn’t make it popular on his blog which allowed to write 23 books around the subject… at least he gives back to many amazing organizations but really had nothing to do with its creation…and admits it . Just remember Education is just process of learning how to learn. Being intelligent is being able to understand and make it your own.. not follow others. So make it your own and don’t follow blindly
Smart managers don't hire Scrum masters; they choose them from development teams. And smart Scrum masters know when to include elements of Scrum and when to leave some out. A coach who says "we're going to do this because it's part of Scrum and we do Scrum" is too rigid to call himself an Agile coach in the first place.
Also, Scrum masters are not project managers. Those are two separate jobs that may or may not be done by the same person. In my opinion, it's ideal that they are not.
I totally agree with your comment on Scrum Masters. PM's don't fit this role.
Your animosity is misdirected, you are describing toxic culture not toxic tools. If your company replaced agile with waterfall, but did nothing else, you would still be making the same gripe.
I'll try not to make a 10,000 word comment here. First off, a "Scrum Master" who spends their time hunched over Jira, wails about story points and comments, and pits people against each other is either poorly trained, or has been forced into that role by a shouty/intimidating superior.
I've heard a lot of similar complaints about Scrum and they aren't without merit. But if you dig deeper, you'll find the misgivings people have about Scrum - or really any other framework for Agile ways of working - are rooted in poor leadership. The Scrum Guide is a very brief document that describes a very simple process that's meant to build an environment where the customer is embedded with the team and therefore the team is aware of pivots in requirements or overall strategy far sooner. It's far easier to change course on a much smaller codebase than learn a plan you developed years ago and have been coding against now needs to be tossed aside. When these inspect/adapt behaviors clash with PMs' and directors' and others' desire for command and control, Scrum, Kanban, or SAFe is the easy scapegoat. Too often, these frameworks are taught as merely "something the devs do," and not as a dual operating system that turns siloed organizations into product powerhouses.
The best thing for any organization trying to build something with emergent requirements is to understand the customer's needs and the larger operational construct, and to understand from the team(s) building the desired outcome(s) how they need to work. Don't immediately stuff something into Scrum or any other framework. Inspect and adapt and treat knowledge workers like human beings.
PMI has also embraced Agile/adaptive environments and teaches how to operate in them, and doesn't exclusively focus on Waterfall.
Seems like you're stuck with a bad one. Scrum masters, the good ones, have really changed our team dynamics and helped us achieve more. And the different roles you mentioned don't fall in the same category. Scrum master is the least secure position in today's market.
Maybe I am in the 19th century but what does SCRUM stand for and what does it/they do?
Scrum is just another cult or religion.
these stories and questions hurt my sole. yeah, grumpy and awful people take manager roles all over the place because it's seen as powerful.
I'm sorry you have a shi**Y person in a position that's supposed to be helping and protecting the team.
As with most "luxury" tech jobs, they are there to make the engineering layer less annoyed with the stakeholder layer.
Obviously this can be very easily abused.
Oh btw, you're 10x more likely to be screwed by a fellow developer or your engineering manager than a product/project/scrum manager.
Too many developers are too trusting of their fellow workers.
Assertion: If you aren't accountable for money, you aren't doing real project management.
Companies are made of people, teams are made of people, roles are filled by people. People are who they are regardless of the methodology used at their current compnay. A shitty person who wants to tear down others will do it and call it Agile. A person who lifts others up will really dig into the Agile principles and use those to amplify their ability to unblock and support their team, but that person would have done it regardless of calling it Agile or calling it servant leadership or whatever buzz word. It really sucks that layoffs impacted you and it's easy to blame a methodology or even a single person on a team. But truly it's a greedy corporate culture and the fact is they want us blaming each other or Agile or Scrum masters or project managers so that we don't disect the motivations of the people at the top making these decisions. If were blaming and tearing eachother apart then we arent looking at the top and asking them questions.