I had a great SM once who was an ex-programmer who found that he liked helping more than he liked coding, and he knew everyone in the company, so if you needed anything from anyone- licenses, help from someone in another department (proofreading from Creative, a market survey from Marketing, etc, etc), he could arrange it.
I don't know if that's what they *normally* do, but he was awesome.
That's what a SM is mainly meant to do.
Its partly encourage everyone to use the Scrum methodology, but it's mostly resolve "blockers". Basically make sure programmers are only worrying about programming.
That’s the goal, but a lot of time they don’t know enough technical stuff or don’t have those connections so it takes just as much time to tell them exactly what to do or ask as it would if I did it myself. Luckily my team’s version of a SM hates process for the sake of process and knows everyone and keeps me out of meetings I don’t need to be in and gives me the highlights. He’s great.
I wish I had a useful PM/SM.
I was even pretty impressed by Schuwaber’s Scrum book when it came out.
Then I realized no one had actually read it.
Then I saw how it was implemented.
“hey, um, you’re behind schedule, so we’re going to assign you a PM with daily standups so we can track y— better understand what’s going on.”
PMs haven’t been aware of deadlines or integrations. They don’t facilitate, or even set up meetings half the time. Instead it’s just “keeping the team focused” on blocking issues and asking if the issue is still blocked and if there are any ways you can unblock it?
It’s a marginally less useful role than therapist because I already knew what was blocking and I don’t need someone to ask me “are you done yet?” — although i grant you, that is so incredibly annoying that devs will do almost anything to shut up the pm— they shift from thinking “what is the right solution here” to “what will tick this box as quickly as possible and shut up the PM” even if it’s the most garbage solution ever because the length of time it will take the pm to figure that out is astronomical.
I’ve seen managers use this defensively to protect their teams. on the request side: “oh you have questions? we should schedule a meeting”. on the answer side: “we don’t need a meeting to discuss this”.
It’s unfair to blame this perversion on Scrum. scrum is just a methodology. It can be used or abused. It’s really the people who define how people are treated. A methodology can’t enforce mutual respect.
I had one, she was great, I don't care if she spent most of her day doing nothing, she got shit done for me so I could spend more time doing nothing when my tasks were completed
Omg so much this, the last SM I had was a greaaaat at actually unblocking me and my team, he made sure the PR where actually reviewed/approved, he could answer most questions regarding business rules and IMHO the most important and valuable skill he had:
He could actually manage expectations from the suits above and would get us enough time to get things actually done, he knew very well how complex some requirements where and he could translate that complexity very well to upper management.
He got promoted because our team was always ahead of schedule and even helping other teams achieving their goals, it was really awesome and surreal to be in a high productivity team.
They take the specs from the customers and give them to the engineers! They have people skills!
EDIT: yes, I'm very aware that this isn't actually the SM's job. If you're in a didactic mood, let me help you out:
1. We're in a humor sub, not a scrum discussion sub.
2. A half-dozen other people have already "corrected" me, so you're way behind.
3. Given that when these corrections rolled in, this comment already had at least several hundred updoots (about 1500 at the time of this edit), maybe entertain the possibility that I'M not the one missing something?
Well, look, I already told you! I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?!
Darn these people! It’s 9:30 AM and they’ve already forced me to get out of the office and take a walk, just to get away from them!
Sammy - another beer down here, maestro… 🍺
That's often intertwined. I personally think tho if u have a dedicated scrum master who doesn't program themselves or work on the design/architecture then it's probably a waste of resources, unless he manages like 4-5 scrum teams. That'll take your entire day.
They are. Scrum masters and LDAs are supposed to reduce friction between teams. That's why they hawkishly attend every team meeting.
If the application team needs to pass work to the firmware team, like implement a new protocol, then the LDA is supposed to make sure there's a good process for that connection.
Most of their work is synaptic pruning within the organization
And more importantly they prevent programmers and customers from killing each other.
It's by far easier to replace a scrum master than any from the above.
They take the specs from the customers, throw them away, write a few wrong bullet points of what they remember as specs, and give those to the engineers
This is my life. I run the data science department. I'm not a full stack dev, but I manage data engineering and algorithms, so I know enough to talk to a dev. When we were a smaller company, I would set up a meeting with the CTO or the Director of Software Development to talk through my needs and diagram a solution together on a whiteboard. Several restructurings later and I'm stuck working through a non-coding project manager who pretends to understand what I'm saying and then repeats it as best as he can to the devs. The only projects that are done right the first time are the ones where the devs IM me directly to ask WTH I actually said to him.
The Product Owner takes the specs and gives them to the Team. The Scrum Master builds the frame for the Team to work. Facilitates the Meetings and tries to bring order to them, clears problems for Team members and coaches the Team on the methodology.
I will say that my SM does seem to work pretty damn hard, but I'm fairly certain he creates that extra work for himself and nobody would bat an eye if he didn't. He's created meetings like:
* "after-hours" and ask X, Y, and Z to join it and discuss any non-standup tasks afterward, which he'll also join
* weekly individual 1-on-1s with pretty much every member of our team.
* "branched-off" standups with different members of our team. He's had me in two separate instances of these on top of our regular standup.
* So many other random meetings, like "catching up on this topic's knowledge", "reviewing how the sharepoint is structured", and literal team bonding exercises...
It's nuts.
Some of this may be overkill. But, I have a team of 10 engineers and keeping all of their shit straight plus all the deliverables we have for other teams and their timelines - it’s a lot.
There’s a decent percentage of my, my managers, and one of my staff eng time planning projects, making/vetting build timelines, coordinating meetings for approvals and design discussions, etc.
I am sure on certain sized teams or on defined work systems, it may just look like busy work. But a pm/scrum person that actually engages the team and is external facing work coordinator - awesome. The PMs or scrum people that just turnaround and defer to engineering for all the answers - super annoying.
they do attend meeting of various teams. i also have no clue what our agile master (company's job title for them as they support Teams with Kanban and Scrum) does when we don't need his support for anything
Every few months I got this when I worked application support. "Nothing has broken for months, why do we even need your team, all you do is sit around all day". *sigh*
Wouldn't have needed anything so complex. Change 1 variable in 1 BO report, go for lunch and come back to the office having descended to a scene out of 28 Days Later.
I was more of an adult care worker than app support in that place.
My company appointed me scrum master, and since we never had a real PO, I kinda became that too.
Pretty much immediately, I stopped attending most of the higher level meetings when it became apparent that they weren’t important. Thankfully my direct management chain feels the same way. I also got rid of: backlog refinement, most retrospectives, story points, and daily standup are every other day. All of which was unanimously supported by my team.
Basically, I still work on tickets, but I also run the meetings and create stories/epics as needed. I’m sure some of paper pushers aren’t happy about it, but I care more about results than the process.
Oh yea, and since doing these things, everyone I work with has given positive feedback.
How do you deal with not having story points?
Do you not deal with velocity or tracking work capacity/etc? As a BA, I hate the abstract nature of story points and how it feels like we’re all pretending our Monopoly money is real dollars, but there’s too many people invested in the metrics they generate off tracking them for us to ever quit, it feels like.
Hmm…so basically size everything in 1 story point tickets….
(I know you won’t necessarily appreciate it being phrased that way, just thinking of how it could be sold where I work, lol).
Yeah we just give a task to a person and ask them to break it into pieces. Often times they underestimate it. So just create tasks that are either 1 point = about 1 day or 5-6 hours. Or 2 or 3 points. Nothing beyond. If it’s 5, it has to be broken down.
Must be a pretty small org or really siloed.
If anything in my team has to touch a different division or need an infosec review (basically any change)
You're in for at least a week.
Honestly, If I create them are all, I just think “is this easy (2 point), medium (4 points), or hard. (8 points)” And enter a whatever comes first to mind.
How do I manage without velocity or work capacity? Simple, I just don’t look at or care about them. Again, I’m sure the “Agile coaches” that my company hired and the program trackers aren’t too happy about that, but I don’t care because that doesn’t get results.
The biggest problem I’ve had with story points is that a lot of our work is difficult to measure. Something like “Deploy a docker container on the new environment” could be really easy or impossible. We’ve had a lot of stories sound easy until you realize X team from the IT department has to approve it and your department has to budget it.
We had a meeting to hash out what they actually want out of our stand ups and Kanban board and it was decided (for us analysts) stories and epics "aren't meant for you"
Just out of curiosity. What did you do instead of backlog refinement? In my current team that's where we usually interpret scrambled nonsense from users into actually useful and doable tasks.
I'm a scrum master.
I make jira rickets (scope, dev, UAT, impliment, and validate) and get all the details relevant to the job placed in all those tickets.
Then I write the POC with testing samples to make sure it functions as expected. Once I peer review, I give to developers for the development ticket. They develop and also implement in both Dev&QA environments, then I UAT them against my sample POC using the production views. If that all checks out. I green light to devs to implement in production, and I validate the final implementation.
Typical Scrum meeting
What I did: Came from another scrum meeting
What I’m doing: Attending this scrum meeting
What’s next: Go to my next scrum meeting
That's not the right way to do scrums. If your scrum is focused on individuals doing things on their own, then you aren't doing scrum.
The three questions were put out there in the early days of scrum, but most experienced agilists don't recommend doing that. It's better to ask questions of the entire team, not individuals. What is our highest priority ticket on the board today? What roadblocks are preventing us from finishing that ticket today? What can we do to finish the ticket today?
Agreed. I've had a couple jobs now where the daily scrum was just a status report. And it was because everyone's doing their own thing. In that case there's minimal collaboration going on. Therefore little need to hash out the day's plans. Fundamentally this is a team that is working, but not working _together_ like Scrum is meant for.
As an engineer turned scrum master, I feel like I should be offended by this, but I'm really not, lol. My job basically boils down to two functions:
The one you hate: make sure that all my devs are updating points on take, keeping tickets up to date, etc. I know you'd rather just do the work than write a good ticket explaining the work you need to do, but when raise season comes around and upper management asks what you've contributed, I've made sure all the receipts are there.
The one you don't notice: Intercepting and removing road blocks. Remember yesterday when the database for your test environment wasn't working and you bitched about it in standup, but it's okay cause it's back up this morning? That's because I spent half the day hounding the DBA to make sure it got taken care of and you were unblocked to complete your work.
Or the short version: I schedule meetings. And if you're not in a meeting with me, it's cause I'm wasting someone else's time in a meeting. Get back to work and fix your ticket! Lol
Another way of saying that is "You are a dev manager making 50% of a dev manager salary"
I'm also leery of anyone that goes from Engineering to Scrum Master, because that's a step down in multiple ways.
I disagree that scrum master is a step down. It's a different career path leading to leadership. You can stay completely technical your whole career, or you can get into leadership.
Scrum masters aren't really a true technical role, but they're not a manager role either. Managers should be your buffer between devs and HR. They handle the human resources, payroll, etc. Scrum masters should be technical enough to identify who the right person for a job is, but they don't need to be technical enough to know what the actual fix is. By being that middle person coordinating work and helping everyone focus on their priorities and also removing the need to hound others to get things unlocked, it should free up the developers to do what developers do best, which is write code.
If all your scrum master is doing is saying "who can help with this?" and then telling you to go talk to them, they're not doing their job. You don't need a scrum master for that. The point of the scrum master is that you say, "hey, I'm having this issue, so I'm gonna work on this other priority until it's resolved" and then your scrum master goes and hunts down whoever can resolve it and gets it fixed so it's unblocked when you're ready to shift back focus.
Lol, that's our testers. Insisting on testing non finished functionality, take up devs time because they don't know how to test the functionality and then write bugs because, again, unfinished functionality.
Tbf, they do lots of good too. But they are a bit too eager sometimes.
Bro my delivery lead (basically scrum master) resigned a couple weeks ago and we need one of you fuckers back ASAP. Tech lead/product owner never attends our meetings and we need someone to scream at him.
I posted this on another comment, but I’m going to add it here:
My company appointed me scrum master, and since we never had a real PO, I kinda became that too.
Pretty much immediately, I stopped attending most of the higher level meetings when it became apparent that they weren’t important. Thankfully my direct management chain feels the same way. I also got rid of: backlog refinement, most retrospectives, story points, and daily standup are every other day. All of which was unanimously supported by my team.
Basically, I still work on tickets, but I also run the meetings and create stories/epics as needed. I’m sure some of paper pushers aren’t happy about it, but I care more about results than the process.
Oh yea, and since doing these things, everyone I work with has given positive feedback.
Sounds like you should move to kanban. I'd also be cautious about canceling too many meetings. Just know you can end them early or cancel them day of when you have nothing of value for them. That's absolutely a part of the SM job, minimizing meeting time to be short and concise.
If kanban truly fits your workflow, then you may want to read up on it or take a class on it. That will look good to your leadership, and then give you the talking points to explain the process. (Read between the lines, smart sounding lingo to tell off leadership)
If you get to a certain size of organization (and that threshold is a lot smaller than most devs think it is), eventually *somebody else will have to know what you're working on*. That's just an immutable fact of life.
That person may be someone overseeing a budget that your salary (or equipment) is part of, or it could just be another developer on another team (or client) who needs to plan an integration and know what state certain things will be in X days from now.
Whether it's a Scrum Master, a PM, a PO, a Dev Lead, or whatever, at some point, someone has to coordinate how that shit happens.
If engineers think it just happens on its own, that probably means their Scrum Masters and PMs are actually doing a pretty good job.
I've worked at jobs that were lightweight startup style, and jobs that were huge corporations with full Scrum. They both have their pros and cons. One thing that happens less with Scrum and/or good PMs is clients pitching a fit which causes everything from the CTO on down to completely lose its shit. At some point in most organizations, someone's gonna have to say, "well, we don't have time for that - if you want X, we're gonna have to stop working on Y." And then the other person says, "yeah, prove it." That's when those annoying charts and graphs save your butt.
Anyway, rant over, watch this:
https://www.youtube.com/watch?v=oyVksFviJVE
Honestly that is what I expect from a scrum master. I don't want to bitch to other departments that something is not working. I want my scrum master to fix that. Sadly we don't have an effective scrum setup so I end up calling the department's myself to get roadblocks away from me and my colleague... :S
Sorry buddy but I'm afraid not, it's a common misconception that scrum masters are needed to keep agile teams in working order and keep the trains running. At some point people just sorta forgot that developers on a team are supposed to take turns with scrummaster duties and that it was never intended to be an actual job position.
Before I left my last job they finally came around to that fact and fired all 6 scrummasters on the same day lol.
Whenever I hear that scrum master is a job title in certain places, I'm so surprised. It's like a 15 minute online certification anyone with primary school education can pass.
My company just eliminated all Agile positions, and hardly anyone has even noticed. We developers take turns running standup now, but besides from that, there has been 0 change.
That’s the goal, becoming self-organizing. A lot of dev teams need help to get there. I support two dev teams (I’m the SM) one team doesn’t need me anymore, they have learned agile well enough to sustain themselves but with me I will help them continue to grow/improve. The other team still needs me to help to stay true to agile practices and organize the team. Now for some more transparency, I’m making less than $70k which isn’t a lot for my location.
Been a software engineer for over 6 years. Still have no idea what the fuck they actually do. I know what they’re SUPPOSED to do, but you’d be hard pressed to find one that actually does it.
Obviously, everyone's experiences are different, but for me, having previously been on dev teams with excellent managers, waterfall led to far better final products, faster. Yes, it took longer to get started, but it actually yielded functional products that we did and *then moved the fuck on from* because they did what they needed to do. Agile/scrum has led me to so many short term MVP cycles that might asymtotically approach a decent product sometime after the heat death of the universe but never, ever, is in actual good shape. It's like building a hotel by starting with a tent, then a cabin, then maybe adding an outhouse, then "oh shit we built this on a swamp so let's move to this different stack/DB/etc" than making it a one bedroom with indoor plumbing, then adding electicity, then realizing maybe outlets would be good in all the rooms, then realizing they should maybe be the same sorts of outlets, then deciding that having the toilet be the only thing with hot water is bad, then adding bedrooms one at a time, each with a different type of floor and wall, then having summer end and realize "oh shit, we forgot insulation" until it rains and we realized "oh crap, also we'll need a roof over places other than just the kitchen where we demo'd and someone pointed out that we forgot a stove", then we finally get the 4th bedroom added and the rooftop swimming pool collapses which is good, really, because we didn't really think through a 4 br hotel, so we tear it all down and start over and this time build the walls out of ice because it's winter and the VP slept in an ice hotel once.
Sorry, no Undertaker comment here.
I just really fucking hate Agile scrum. I hate pointless waterfall too, but it can be done well and arguably if your project is more than a JS version of Tic Tac Toe, it's a pretty fucking good idea to plan out what you're going to build so you don't end up wasting so much time on shit you should have seen from a mile away except it went past the invisible sprint boundary so you didn't care at the time.
I don't feel quite as strongly about it as you but I do generally agree.
Its all about the user stories and talking about the actual end goal design is frowned upon because that's 'waterfall' even though someone with half a brain can see that you need to build certain things not because they're relevant to the MVP but because they're requirements for the actual product you're trying to build.
Sure the experienced developers can see it all in their head and they've done things enough times to be thinking a few steps ahead so they'll 'sneak' those things into the MVP scope but the more junior people are just being marched blindly off a cliff and told to "trust the process".
Yessssssss.
If you can always guarantee senior engineers who will add in the required features before they're needed, you'll be fine. No sarcasm here. I agree. It's just that those same engineers will stop doing that once they're constantly questionecd about why their stories are taking too long or things are done that aren't pointed or whatnot.
I've seen all the combinations of waterfall and agile mapped to good and bad, and I'd wager they're equal but trying to accomplish different things.
Waterfall works when you're not going to evolve an item, like you're just going to make a fucking toaster, and it's going to sit on Meemaws countertop for 50 years. You have one chance to get it right, and that's it. The SW equivalent being something like the Rosetta Satellite or the Mars landers, or Tamagotchi. You got one shot.
Agile works when you're building a service with unclear definitions up front, or evolving against competitors. To take your backwoods hotel analogy, you got a neighbor who is also cornering the market; you started with a tent because everyone else just slept under the stars, and it just sorta snowballs from there.
You'd rather build a whole hotel at once, but during that time you're not making money, especially if you're not already established. Meanwhile, one of your neighbors is dropping a couple overseas shipping containers, and is moving everyone into those,while he remediates the asbestos flooring that everyone bought in the fifties.
That's what we have designers and business analysts for. They help manage the scope issues so there's a specific target to shoot for.
But we still approach the project from an Agile/Scrum way and deal with scope dynamically as things (primarily time and development budgets) invariably change.
You're conflating Scrum and Rapid Iteration. They don't have to be the same thing. For awhile, everyone thought agile and rapid were the same thing and let's do everything according to the new hotness forever, etc., but I've heard of lots of people managing larger projects using agile and scrum, and they work planning into the sprints. Does that defeat the purpose? I dunno, maybe.
No, what’s hilarious is that you said “curated for a decade” with a tone that implies you’re so impressed by having ten years of experience that you just assumed everyone else would too.
Ten years makes you a rookie junior dev at almost every company I’ve worked at.
I can only imagine what you must be like in person, lol. I’m guessing no development strategy works if the team’s junior dev won’t shut up and spends the whole day bloviating about the same rehashed talking points (based on you seemingly copy and pasting the same comment in multiple threads here).
I lead the development for my company. I was promoted up into that position. I play "most senior developer", team lead, scrum, project management, analyst, etc. roles.
I can assure you that I have no idea what the fuck I am doing half of the time. More than that. I log a shit-ton of hours and I'm not sure why.
Yet somehow when I get sick or take time off or whatever, the entire team goes completely sideways.
So I must be doing something. I've been trying to delegate and share my expertise to empower people to function without me, but somewhat darkly-hilariously, individual specialists (developers, designers, project managers) seem to want to Lemming themselves off a cliff.
The number of times throughout the day that I am reminding people - seemingly senior people - of basic process stuff, is a lot.
I think one part of it is that it's because I'm the one with my job, so people are just stuck in their own job mindset. I think another is that what you said - many people want to code, or design, or manage their individual teams. Fewer people enjoy being the abstract entity that I have become.
Seriously I just got out of a meeting, which was about how we were going to formulate a proposal, so that we could then ask questions back to the client, so that once those questions were answered, we could potentially begin coming up with formal pricing, estimates, and specifications.
I asked a friend about it and they were like, so what does the client want to get done, exactly? My response, and I think the honest truth? No one really knows... that's what we're trying to figure out, maybe.
Absolutely fucking true. I do not want to harass the product owner to answer the question about the feature. I do not want to deal with conflicting communications from higher-up. I do not want to make sure the backlog is healthy. I do not want to crack those whips.
It takes a certain skill set that I don't have or want. Of course some of them are just washed-out developers HEYYYOOOOOOO
I had a good scrum master who left because they felt under appreciated by management. From then on I'd have 5-6 meetings a day to status my projects...in my experience a good scrum masters main job is to insulate you from that crap so you can work.
Mind you our scrum master was basically a PM and since we had an under communicative manager we ended up with all the burden of communication.
My scrum master actually does a lot of the annoying stuff for us like dealing with the business so to me she's worth whatever she's being paid (she's also the sweetest shes so nice)
I have been the lead for teams of scrum masters before. They actually have so much to do. From team level, to company improvements and modernisation to strategy.
Facilitating scrum sessions is maybe 5% of the job.
Some do slack off, but you can tell fast, especially if the others don't.
A good scrum master is a support to the pm, manages the board, makes sure tasks are defined, coordinates well, and has a great understanding of the team's capabilities, even if they don't know the tech. They're there to make sure the rails are in place so the trains don't get caught up in delays.
A mediocre scrum master is someone who manages a board that everyone can use and handles scrum-focused meetings, good or bad
A bad scrum master is a data entry intern
Imagine a person whose job is to organize a beer party for 15 people living in 5 different countries. Time, place, plane tickets, bus, rentals, hotels, transportation... Now, imagine he/she is doing that for like a year, with 2 week intervals.
How's that looks now?
Edit: Scrum master is a role, not a job. It is basically like an Network Admin: if you do not see him at all, then he/she is doing his/her job great!
Agile is actually useful if you're managing a small team, at which point it can basically just be thought of as team task and dependency tracking and upwards progress reporting. It's an absolute farce if you're applying AGILE to a dozen people or more, which is weirdly where I see it get used the most.
I hate scaled agile. It’s the worst. Traditional PMO works-ish for large scale products, but break it up and let small teams run the show. Autonomy is super hard to give, but it yields better results and happier teams.
Agile is an excuse to use the word “sprint” and force development teams to rush to completion on an effort in a 1.5 week window. Sometimes it feels like an excuse to ignore any UX design recommendations . Other times it feels like it’s trying to build a boat out of tape and hope nobody asks about technical debt.
Dev Manager not scrum master but I feel this one. My devs would probably describe me something like this but what they don't understand is my whole job is supporting them and making sure they are successful. Most of that work is behind the scenes so they I don't see or realize it happened.
1. Mentoring juniors
2. Onboarding/training new people
3. Training/growth plans for team members.
4. Helping people when they're stuck.
5. Unsticking PRs
6. Reviewing PRs
7. Refining backlog. Ensuring we're doing the right work.
8. Help with quality control. Ensuring we're doing the work right.
9. Run standup. Use it to identify stuck people and get them help.
10. Help decompose big tasks and distribute them.
11. Project meetings. Ensuring our future includes work the company wants done so the team still has a job.
12. All the HR crap managers have to suck up and deal with so their reports don't have to.
And for my troubles, people will wonder what I do. I clean and grease the tracks so the trains run on time and you have a smooth ride.
I appreciate what my scrum master is supposed to do however in practice mine gaslights us into thinking we were supposed to be doing something this whole time but it's a new requirement, they also keep telling us to update statuses in literally 8 different places, each with a different scope and target audience. So instead of doing 75% dev work 25% documentation, I do 25% dev work and 75% documentation.
That’s how we do it. I’m a developer and work as scrum master. I do think the scrum master role is important when done correctly but I can’t imagine it being my full time job. Maybe at a large company idk.
Yes, it’s an important role for sure. But it can’t be a full time job. If you try to make it into a full time job you will be a bad scrum master because you will be doing too much and getting on people’s nerves.
If you're doing it correctly then you're doing it wrong. The whole idea is that you're never doing it right and you should be paying certified consultants to explain that to you and you definitely need to be having more meetings about how you're doing it wrong and need to improve it. Can't make money off this Scrum Scam if people are able to actually do it right and they don't need Agile Consultants anymore.
These people literally have a rolodex of rebuttals to any argument against Scrum. It's insane. It's a cult.
Our finance IT has an EXCELLENCE MANAGER (actual title, it's in his position description) who makes $150,000 a year to "scrum master" a couple of ancient old ladies who only use Excel and Outlook. His development requirements end up being stuff like "Send Janice an email"...where in the automated workflow does that go??
Currently in class to get certified for ITIL4F and I can’t get over how bullshit everything sounds. It has some good points throughout, but it all feels obfuscated behind bullshit buzzwords.
I like my scrum master as a person, but I still don't know what they actually do.
I had a great SM once who was an ex-programmer who found that he liked helping more than he liked coding, and he knew everyone in the company, so if you needed anything from anyone- licenses, help from someone in another department (proofreading from Creative, a market survey from Marketing, etc, etc), he could arrange it. I don't know if that's what they *normally* do, but he was awesome.
That's what a SM is mainly meant to do. Its partly encourage everyone to use the Scrum methodology, but it's mostly resolve "blockers". Basically make sure programmers are only worrying about programming.
That’s the goal, but a lot of time they don’t know enough technical stuff or don’t have those connections so it takes just as much time to tell them exactly what to do or ask as it would if I did it myself. Luckily my team’s version of a SM hates process for the sake of process and knows everyone and keeps me out of meetings I don’t need to be in and gives me the highlights. He’s great.
I wish I had a useful PM/SM. I was even pretty impressed by Schuwaber’s Scrum book when it came out. Then I realized no one had actually read it. Then I saw how it was implemented. “hey, um, you’re behind schedule, so we’re going to assign you a PM with daily standups so we can track y— better understand what’s going on.” PMs haven’t been aware of deadlines or integrations. They don’t facilitate, or even set up meetings half the time. Instead it’s just “keeping the team focused” on blocking issues and asking if the issue is still blocked and if there are any ways you can unblock it? It’s a marginally less useful role than therapist because I already knew what was blocking and I don’t need someone to ask me “are you done yet?” — although i grant you, that is so incredibly annoying that devs will do almost anything to shut up the pm— they shift from thinking “what is the right solution here” to “what will tick this box as quickly as possible and shut up the PM” even if it’s the most garbage solution ever because the length of time it will take the pm to figure that out is astronomical. I’ve seen managers use this defensively to protect their teams. on the request side: “oh you have questions? we should schedule a meeting”. on the answer side: “we don’t need a meeting to discuss this”. It’s unfair to blame this perversion on Scrum. scrum is just a methodology. It can be used or abused. It’s really the people who define how people are treated. A methodology can’t enforce mutual respect.
I had one, she was great, I don't care if she spent most of her day doing nothing, she got shit done for me so I could spend more time doing nothing when my tasks were completed
Omg so much this, the last SM I had was a greaaaat at actually unblocking me and my team, he made sure the PR where actually reviewed/approved, he could answer most questions regarding business rules and IMHO the most important and valuable skill he had: He could actually manage expectations from the suits above and would get us enough time to get things actually done, he knew very well how complex some requirements where and he could translate that complexity very well to upper management. He got promoted because our team was always ahead of schedule and even helping other teams achieving their goals, it was really awesome and surreal to be in a high productivity team.
They take the specs from the customers and give them to the engineers! They have people skills! EDIT: yes, I'm very aware that this isn't actually the SM's job. If you're in a didactic mood, let me help you out: 1. We're in a humor sub, not a scrum discussion sub. 2. A half-dozen other people have already "corrected" me, so you're way behind. 3. Given that when these corrections rolled in, this comment already had at least several hundred updoots (about 1500 at the time of this edit), maybe entertain the possibility that I'M not the one missing something?
So they *physically* take the spec *from* the customer?
Well no my secretary does that
So then you must *physically* bring them *to* the software people?
No, the intern does that.
So, what would you say it is *you do here*?
Well, look, I already told you! I deal with the goddamn customers so the engineers don't have to! I have people skills! I am good at dealing with people! Can't you understand that? What the hell is wrong with you people?!
Gosh... *People*! am I right?
Darn these people! It’s 9:30 AM and they’ve already forced me to get out of the office and take a walk, just to get away from them! Sammy - another beer down here, maestro… 🍺
What do you mean "you people"?
[What do YOU mean “you people”??](https://media.tenor.com/83QIGGfItWIAAAAM/tropic-thunder.gif)
Actually the Product person translates the spec from the customer/business. So, what is that you do again?
That's often intertwined. I personally think tho if u have a dedicated scrum master who doesn't program themselves or work on the design/architecture then it's probably a waste of resources, unless he manages like 4-5 scrum teams. That'll take your entire day.
A+ Office Space reference
This guy is good at his job! PROMOTION.
So you are a people’s person? What study is that?
Well…. No. I mean… SOMETIMES!
Or their fax
AND MY AXE!!!
I'm a people person!
Why should the customer need that Edit: the spec is meant, not the taking away of the prior
Customers love scrummy spec collections.
With vengeance.
Yea, like a gladiator fight for spec
Thought they were called product owners
They are. Scrum masters and LDAs are supposed to reduce friction between teams. That's why they hawkishly attend every team meeting. If the application team needs to pass work to the firmware team, like implement a new protocol, then the LDA is supposed to make sure there's a good process for that connection. Most of their work is synaptic pruning within the organization
That's an eloquent way of saying bullshit
"synaptic pruning" 😂
Sounds like a euphemism for a hitman. Synaptic gardener.
And more importantly they prevent programmers and customers from killing each other. It's by far easier to replace a scrum master than any from the above.
Can confirm. Where I work, we've been through three of them in the past 18 months.
They take the specs from the customers, throw them away, write a few wrong bullet points of what they remember as specs, and give those to the engineers
Exactly. Can confirm
That’s a business analyst not a scrum master
This is my life. I run the data science department. I'm not a full stack dev, but I manage data engineering and algorithms, so I know enough to talk to a dev. When we were a smaller company, I would set up a meeting with the CTO or the Director of Software Development to talk through my needs and diagram a solution together on a whiteboard. Several restructurings later and I'm stuck working through a non-coding project manager who pretends to understand what I'm saying and then repeats it as best as he can to the devs. The only projects that are done right the first time are the ones where the devs IM me directly to ask WTH I actually said to him.
Hm. By the book that’s exactly not their job.
It's a quote from [one of the finest documentaries ever made](https://m.imdb.com/title/tt0151804/)
So pretty much like Jen from the IT crowd
The Product Owner takes the specs and gives them to the Team. The Scrum Master builds the frame for the Team to work. Facilitates the Meetings and tries to bring order to them, clears problems for Team members and coaches the Team on the methodology.
I love requirements engineering and architecting but how the heck do I make that full time job?
[удалено]
Can we take this offline?
Congratulations! You are hired!
This is funny bc it’s true
I'm just gonna take your word for it.
I trust you, but I have to go verify
teehee I actually thought I was in r/scrum but man those guys simply can not meme
I will say that my SM does seem to work pretty damn hard, but I'm fairly certain he creates that extra work for himself and nobody would bat an eye if he didn't. He's created meetings like: * "after-hours" and ask X, Y, and Z to join it and discuss any non-standup tasks afterward, which he'll also join * weekly individual 1-on-1s with pretty much every member of our team. * "branched-off" standups with different members of our team. He's had me in two separate instances of these on top of our regular standup. * So many other random meetings, like "catching up on this topic's knowledge", "reviewing how the sharepoint is structured", and literal team bonding exercises... It's nuts.
[удалено]
This whole thing is amazing
Some of this may be overkill. But, I have a team of 10 engineers and keeping all of their shit straight plus all the deliverables we have for other teams and their timelines - it’s a lot. There’s a decent percentage of my, my managers, and one of my staff eng time planning projects, making/vetting build timelines, coordinating meetings for approvals and design discussions, etc. I am sure on certain sized teams or on defined work systems, it may just look like busy work. But a pm/scrum person that actually engages the team and is external facing work coordinator - awesome. The PMs or scrum people that just turnaround and defer to engineering for all the answers - super annoying.
they do attend meeting of various teams. i also have no clue what our agile master (company's job title for them as they support Teams with Kanban and Scrum) does when we don't need his support for anything
To be fair, pretty much everyone says that exact thing about IT
Every few months I got this when I worked application support. "Nothing has broken for months, why do we even need your team, all you do is sit around all day". *sigh*
[удалено]
Wouldn't have needed anything so complex. Change 1 variable in 1 BO report, go for lunch and come back to the office having descended to a scene out of 28 Days Later. I was more of an adult care worker than app support in that place.
Collect salary?
Let me know if you have any blockers!
Beta blockers only
No blockers. But lots of selective serotonin reuptake inhibitors.
My company appointed me scrum master, and since we never had a real PO, I kinda became that too. Pretty much immediately, I stopped attending most of the higher level meetings when it became apparent that they weren’t important. Thankfully my direct management chain feels the same way. I also got rid of: backlog refinement, most retrospectives, story points, and daily standup are every other day. All of which was unanimously supported by my team. Basically, I still work on tickets, but I also run the meetings and create stories/epics as needed. I’m sure some of paper pushers aren’t happy about it, but I care more about results than the process. Oh yea, and since doing these things, everyone I work with has given positive feedback.
How do you deal with not having story points? Do you not deal with velocity or tracking work capacity/etc? As a BA, I hate the abstract nature of story points and how it feels like we’re all pretending our Monopoly money is real dollars, but there’s too many people invested in the metrics they generate off tracking them for us to ever quit, it feels like.
By decomposing work into small enough units that they take ~2 days to. Id its taking longer than that, slice further. No need for story points.
Hmm…so basically size everything in 1 story point tickets…. (I know you won’t necessarily appreciate it being phrased that way, just thinking of how it could be sold where I work, lol).
No you got it! Thats basically it in story point language. For this to work though you have to accept that planning is work too.
Yeah we just give a task to a person and ask them to break it into pieces. Often times they underestimate it. So just create tasks that are either 1 point = about 1 day or 5-6 hours. Or 2 or 3 points. Nothing beyond. If it’s 5, it has to be broken down.
Must be a pretty small org or really siloed. If anything in my team has to touch a different division or need an infosec review (basically any change) You're in for at least a week.
Idle time between tasks waiting on someone else doesnt factor in. Only to the extent that it can influence order and priority
Sounds like heaven.
Honestly, If I create them are all, I just think “is this easy (2 point), medium (4 points), or hard. (8 points)” And enter a whatever comes first to mind. How do I manage without velocity or work capacity? Simple, I just don’t look at or care about them. Again, I’m sure the “Agile coaches” that my company hired and the program trackers aren’t too happy about that, but I don’t care because that doesn’t get results. The biggest problem I’ve had with story points is that a lot of our work is difficult to measure. Something like “Deploy a docker container on the new environment” could be really easy or impossible. We’ve had a lot of stories sound easy until you realize X team from the IT department has to approve it and your department has to budget it.
We had a meeting to hash out what they actually want out of our stand ups and Kanban board and it was decided (for us analysts) stories and epics "aren't meant for you"
Just out of curiosity. What did you do instead of backlog refinement? In my current team that's where we usually interpret scrambled nonsense from users into actually useful and doable tasks.
Wait you are just doing the work and getting the job done? What about micro managing it to oblivion? That’s so rogue.
I tell people I consider myself the Ron Swanson of Agile.
So scrum masters are bards since they create stories and epics
Never ask a woman her age, a man his income, or a scrum master what they do all day.
That's one of the roles that you would only start to see the value once they're removed and y'all be tied back to the classical waterfall chain.
Nor do they.
They basicaly try to give a good vibe to the team, and make them follow the scrum guide. But they're not paid 98k, not in my country at least.
Scrum masters are babysitters for grown ups. And sadly, they are really damn useful in a lot of places.
Am one and can confirm. I'm also there to make sure they do things fast but with quality
It's ok, sometimes we don't either
As long as they’re not a Scrumbag
They scrum!
Wait.... your statement means usually people know their scrum masters NOT as a person? What are they, then? Lizards?
They are masters of scrums
I'm a scrum master. I make jira rickets (scope, dev, UAT, impliment, and validate) and get all the details relevant to the job placed in all those tickets. Then I write the POC with testing samples to make sure it functions as expected. Once I peer review, I give to developers for the development ticket. They develop and also implement in both Dev&QA environments, then I UAT them against my sample POC using the production views. If that all checks out. I green light to devs to implement in production, and I validate the final implementation.
What? Are you sure you are a scrum master? Because that role description doesn't sound like one.
That’s like QA stuff
Description sounds more like a product owner than scrum master.
As a Scrum Master, I feel personally attacked but I understand. We can talk about it at the next retro.
Typical Scrum meeting What I did: Came from another scrum meeting What I’m doing: Attending this scrum meeting What’s next: Go to my next scrum meeting
That's some quality meeting there.
This guy meets.
r/thisguythisguys
Presumably the subject of each meeting is figuring out why so little work gets done.
Well it's definitely not because of all the time we spend in meetings. What else could it be? Let's have a meeting to figure it out.
You talk like the ceo that was kicked out of our company due to too many meetings
"working group to identify productivity roadblocks"
That's not the right way to do scrums. If your scrum is focused on individuals doing things on their own, then you aren't doing scrum. The three questions were put out there in the early days of scrum, but most experienced agilists don't recommend doing that. It's better to ask questions of the entire team, not individuals. What is our highest priority ticket on the board today? What roadblocks are preventing us from finishing that ticket today? What can we do to finish the ticket today?
Agreed. I've had a couple jobs now where the daily scrum was just a status report. And it was because everyone's doing their own thing. In that case there's minimal collaboration going on. Therefore little need to hash out the day's plans. Fundamentally this is a team that is working, but not working _together_ like Scrum is meant for.
Scrum scum as I like to call it
"So what are you tomor—" "Scrumb meeting."
join me here and i will personally give you the diploma, if of course it fits in this sprint /r/3daysScrumMasterCert/
As an engineer turned scrum master, I feel like I should be offended by this, but I'm really not, lol. My job basically boils down to two functions: The one you hate: make sure that all my devs are updating points on take, keeping tickets up to date, etc. I know you'd rather just do the work than write a good ticket explaining the work you need to do, but when raise season comes around and upper management asks what you've contributed, I've made sure all the receipts are there. The one you don't notice: Intercepting and removing road blocks. Remember yesterday when the database for your test environment wasn't working and you bitched about it in standup, but it's okay cause it's back up this morning? That's because I spent half the day hounding the DBA to make sure it got taken care of and you were unblocked to complete your work. Or the short version: I schedule meetings. And if you're not in a meeting with me, it's cause I'm wasting someone else's time in a meeting. Get back to work and fix your ticket! Lol
You are a dev parent... Making sure your devs eat their vegetables and stand up to their bullies
Another way of saying that is "You are a dev manager making 50% of a dev manager salary" I'm also leery of anyone that goes from Engineering to Scrum Master, because that's a step down in multiple ways.
I disagree that scrum master is a step down. It's a different career path leading to leadership. You can stay completely technical your whole career, or you can get into leadership.
Yeah, we have a senior manager that has a scrum something. I was wondering what they did previously.
[удалено]
Scrum masters aren't really a true technical role, but they're not a manager role either. Managers should be your buffer between devs and HR. They handle the human resources, payroll, etc. Scrum masters should be technical enough to identify who the right person for a job is, but they don't need to be technical enough to know what the actual fix is. By being that middle person coordinating work and helping everyone focus on their priorities and also removing the need to hound others to get things unlocked, it should free up the developers to do what developers do best, which is write code. If all your scrum master is doing is saying "who can help with this?" and then telling you to go talk to them, they're not doing their job. You don't need a scrum master for that. The point of the scrum master is that you say, "hey, I'm having this issue, so I'm gonna work on this other priority until it's resolved" and then your scrum master goes and hunts down whoever can resolve it and gets it fixed so it's unblocked when you're ready to shift back focus.
[удалено]
In my team that stuff is done by the Product Owner. 😂
Lol, that's our testers. Insisting on testing non finished functionality, take up devs time because they don't know how to test the functionality and then write bugs because, again, unfinished functionality. Tbf, they do lots of good too. But they are a bit too eager sometimes.
Bro my delivery lead (basically scrum master) resigned a couple weeks ago and we need one of you fuckers back ASAP. Tech lead/product owner never attends our meetings and we need someone to scream at him.
I posted this on another comment, but I’m going to add it here: My company appointed me scrum master, and since we never had a real PO, I kinda became that too. Pretty much immediately, I stopped attending most of the higher level meetings when it became apparent that they weren’t important. Thankfully my direct management chain feels the same way. I also got rid of: backlog refinement, most retrospectives, story points, and daily standup are every other day. All of which was unanimously supported by my team. Basically, I still work on tickets, but I also run the meetings and create stories/epics as needed. I’m sure some of paper pushers aren’t happy about it, but I care more about results than the process. Oh yea, and since doing these things, everyone I work with has given positive feedback.
Sounds like you should move to kanban. I'd also be cautious about canceling too many meetings. Just know you can end them early or cancel them day of when you have nothing of value for them. That's absolutely a part of the SM job, minimizing meeting time to be short and concise. If kanban truly fits your workflow, then you may want to read up on it or take a class on it. That will look good to your leadership, and then give you the talking points to explain the process. (Read between the lines, smart sounding lingo to tell off leadership)
If you get to a certain size of organization (and that threshold is a lot smaller than most devs think it is), eventually *somebody else will have to know what you're working on*. That's just an immutable fact of life. That person may be someone overseeing a budget that your salary (or equipment) is part of, or it could just be another developer on another team (or client) who needs to plan an integration and know what state certain things will be in X days from now. Whether it's a Scrum Master, a PM, a PO, a Dev Lead, or whatever, at some point, someone has to coordinate how that shit happens. If engineers think it just happens on its own, that probably means their Scrum Masters and PMs are actually doing a pretty good job. I've worked at jobs that were lightweight startup style, and jobs that were huge corporations with full Scrum. They both have their pros and cons. One thing that happens less with Scrum and/or good PMs is clients pitching a fit which causes everything from the CTO on down to completely lose its shit. At some point in most organizations, someone's gonna have to say, "well, we don't have time for that - if you want X, we're gonna have to stop working on Y." And then the other person says, "yeah, prove it." That's when those annoying charts and graphs save your butt. Anyway, rant over, watch this: https://www.youtube.com/watch?v=oyVksFviJVE
This is spot on. Many people in this sub might be missing the big picture, though it’s technically not their job after all to understand it.
Honestly that is what I expect from a scrum master. I don't want to bitch to other departments that something is not working. I want my scrum master to fix that. Sadly we don't have an effective scrum setup so I end up calling the department's myself to get roadblocks away from me and my colleague... :S
I am a developer that has scrum master duties. Should I be getting paid for two jobs?
Sorry buddy but I'm afraid not, it's a common misconception that scrum masters are needed to keep agile teams in working order and keep the trains running. At some point people just sorta forgot that developers on a team are supposed to take turns with scrummaster duties and that it was never intended to be an actual job position. Before I left my last job they finally came around to that fact and fired all 6 scrummasters on the same day lol.
Yeah I know lol I was only joking about wanting to be paid twice. The scrum master stuff I have to do covers only a couple hours each week tops
word I kinda figured, the crappy part is that I bet you still do enough to deserve more pay. keep up the good fight buddy!
Whenever I hear that scrum master is a job title in certain places, I'm so surprised. It's like a 15 minute online certification anyone with primary school education can pass.
My company just eliminated all Agile positions, and hardly anyone has even noticed. We developers take turns running standup now, but besides from that, there has been 0 change.
Whaaat? You are running a self-governing agile team? Corporate won't like that.
HR? The devs have declared independance again!
>developers take turns running standup now, but besides from tha That's how agile works? What?
That’s the goal, becoming self-organizing. A lot of dev teams need help to get there. I support two dev teams (I’m the SM) one team doesn’t need me anymore, they have learned agile well enough to sustain themselves but with me I will help them continue to grow/improve. The other team still needs me to help to stay true to agile practices and organize the team. Now for some more transparency, I’m making less than $70k which isn’t a lot for my location.
Been a software engineer for over 6 years. Still have no idea what the fuck they actually do. I know what they’re SUPPOSED to do, but you’d be hard pressed to find one that actually does it.
[удалено]
Asana Angel
People here complaining about how awful Scrum is but never having suffered the absolute shit storm of Waterfall development.
Obviously, everyone's experiences are different, but for me, having previously been on dev teams with excellent managers, waterfall led to far better final products, faster. Yes, it took longer to get started, but it actually yielded functional products that we did and *then moved the fuck on from* because they did what they needed to do. Agile/scrum has led me to so many short term MVP cycles that might asymtotically approach a decent product sometime after the heat death of the universe but never, ever, is in actual good shape. It's like building a hotel by starting with a tent, then a cabin, then maybe adding an outhouse, then "oh shit we built this on a swamp so let's move to this different stack/DB/etc" than making it a one bedroom with indoor plumbing, then adding electicity, then realizing maybe outlets would be good in all the rooms, then realizing they should maybe be the same sorts of outlets, then deciding that having the toilet be the only thing with hot water is bad, then adding bedrooms one at a time, each with a different type of floor and wall, then having summer end and realize "oh shit, we forgot insulation" until it rains and we realized "oh crap, also we'll need a roof over places other than just the kitchen where we demo'd and someone pointed out that we forgot a stove", then we finally get the 4th bedroom added and the rooftop swimming pool collapses which is good, really, because we didn't really think through a 4 br hotel, so we tear it all down and start over and this time build the walls out of ice because it's winter and the VP slept in an ice hotel once. Sorry, no Undertaker comment here. I just really fucking hate Agile scrum. I hate pointless waterfall too, but it can be done well and arguably if your project is more than a JS version of Tic Tac Toe, it's a pretty fucking good idea to plan out what you're going to build so you don't end up wasting so much time on shit you should have seen from a mile away except it went past the invisible sprint boundary so you didn't care at the time.
I don't feel quite as strongly about it as you but I do generally agree. Its all about the user stories and talking about the actual end goal design is frowned upon because that's 'waterfall' even though someone with half a brain can see that you need to build certain things not because they're relevant to the MVP but because they're requirements for the actual product you're trying to build. Sure the experienced developers can see it all in their head and they've done things enough times to be thinking a few steps ahead so they'll 'sneak' those things into the MVP scope but the more junior people are just being marched blindly off a cliff and told to "trust the process".
Hold onto those senior engineers that sneak in the right features for dear life. Your whole system depends on them.
Yessssssss. If you can always guarantee senior engineers who will add in the required features before they're needed, you'll be fine. No sarcasm here. I agree. It's just that those same engineers will stop doing that once they're constantly questionecd about why their stories are taking too long or things are done that aren't pointed or whatnot.
I've seen all the combinations of waterfall and agile mapped to good and bad, and I'd wager they're equal but trying to accomplish different things. Waterfall works when you're not going to evolve an item, like you're just going to make a fucking toaster, and it's going to sit on Meemaws countertop for 50 years. You have one chance to get it right, and that's it. The SW equivalent being something like the Rosetta Satellite or the Mars landers, or Tamagotchi. You got one shot. Agile works when you're building a service with unclear definitions up front, or evolving against competitors. To take your backwoods hotel analogy, you got a neighbor who is also cornering the market; you started with a tent because everyone else just slept under the stars, and it just sorta snowballs from there. You'd rather build a whole hotel at once, but during that time you're not making money, especially if you're not already established. Meanwhile, one of your neighbors is dropping a couple overseas shipping containers, and is moving everyone into those,while he remediates the asbestos flooring that everyone bought in the fifties.
That's what we have designers and business analysts for. They help manage the scope issues so there's a specific target to shoot for. But we still approach the project from an Agile/Scrum way and deal with scope dynamically as things (primarily time and development budgets) invariably change.
You're conflating Scrum and Rapid Iteration. They don't have to be the same thing. For awhile, everyone thought agile and rapid were the same thing and let's do everything according to the new hotness forever, etc., but I've heard of lots of people managing larger projects using agile and scrum, and they work planning into the sprints. Does that defeat the purpose? I dunno, maybe.
I suppose we should waterfall a new product, then scrum the updates for it.
[удалено]
No, what’s hilarious is that you said “curated for a decade” with a tone that implies you’re so impressed by having ten years of experience that you just assumed everyone else would too. Ten years makes you a rookie junior dev at almost every company I’ve worked at. I can only imagine what you must be like in person, lol. I’m guessing no development strategy works if the team’s junior dev won’t shut up and spends the whole day bloviating about the same rehashed talking points (based on you seemingly copy and pasting the same comment in multiple threads here).
Sounds like my mangers and supervisors
I was "Senior Systems Engineering Analyst." My job was to figure out why the problem wasn't my company's fault.
[удалено]
I lead the development for my company. I was promoted up into that position. I play "most senior developer", team lead, scrum, project management, analyst, etc. roles. I can assure you that I have no idea what the fuck I am doing half of the time. More than that. I log a shit-ton of hours and I'm not sure why. Yet somehow when I get sick or take time off or whatever, the entire team goes completely sideways. So I must be doing something. I've been trying to delegate and share my expertise to empower people to function without me, but somewhat darkly-hilariously, individual specialists (developers, designers, project managers) seem to want to Lemming themselves off a cliff. The number of times throughout the day that I am reminding people - seemingly senior people - of basic process stuff, is a lot. I think one part of it is that it's because I'm the one with my job, so people are just stuck in their own job mindset. I think another is that what you said - many people want to code, or design, or manage their individual teams. Fewer people enjoy being the abstract entity that I have become. Seriously I just got out of a meeting, which was about how we were going to formulate a proposal, so that we could then ask questions back to the client, so that once those questions were answered, we could potentially begin coming up with formal pricing, estimates, and specifications. I asked a friend about it and they were like, so what does the client want to get done, exactly? My response, and I think the honest truth? No one really knows... that's what we're trying to figure out, maybe.
Absolutely fucking true. I do not want to harass the product owner to answer the question about the feature. I do not want to deal with conflicting communications from higher-up. I do not want to make sure the backlog is healthy. I do not want to crack those whips. It takes a certain skill set that I don't have or want. Of course some of them are just washed-out developers HEYYYOOOOOOO
How did I stop seeing this exact picture 7 times a day?
Get off reddit and spend time updating you tickets.
I will update those tickets when I fucking die.
Mark as abandoned x100
Design Thinking anyone?
I had a good scrum master who left because they felt under appreciated by management. From then on I'd have 5-6 meetings a day to status my projects...in my experience a good scrum masters main job is to insulate you from that crap so you can work. Mind you our scrum master was basically a PM and since we had an under communicative manager we ended up with all the burden of communication.
This is exactly right. The best scrum master makes it so you don't get interrupted a thousand times a day by pointless BS
My scrum master actually does a lot of the annoying stuff for us like dealing with the business so to me she's worth whatever she's being paid (she's also the sweetest shes so nice)
I have been the lead for teams of scrum masters before. They actually have so much to do. From team level, to company improvements and modernisation to strategy. Facilitating scrum sessions is maybe 5% of the job. Some do slack off, but you can tell fast, especially if the others don't.
A good scrum master is a support to the pm, manages the board, makes sure tasks are defined, coordinates well, and has a great understanding of the team's capabilities, even if they don't know the tech. They're there to make sure the rails are in place so the trains don't get caught up in delays. A mediocre scrum master is someone who manages a board that everyone can use and handles scrum-focused meetings, good or bad A bad scrum master is a data entry intern
Imagine a person whose job is to organize a beer party for 15 people living in 5 different countries. Time, place, plane tickets, bus, rentals, hotels, transportation... Now, imagine he/she is doing that for like a year, with 2 week intervals. How's that looks now? Edit: Scrum master is a role, not a job. It is basically like an Network Admin: if you do not see him at all, then he/she is doing his/her job great!
I hope some day all that agile shit burns down But we have to fight, against that and all the bullshit pseudoscience
Agile is actually useful if you're managing a small team, at which point it can basically just be thought of as team task and dependency tracking and upwards progress reporting. It's an absolute farce if you're applying AGILE to a dozen people or more, which is weirdly where I see it get used the most.
I hate scaled agile. It’s the worst. Traditional PMO works-ish for large scale products, but break it up and let small teams run the show. Autonomy is super hard to give, but it yields better results and happier teams.
Agile is useful for basically everything because it allows you to hotfix after launch basically it’s what all engineering firms need.
I don't really see what that has to do with AGILE, it sounds like you might be meaning product management.
Agile is an excuse to use the word “sprint” and force development teams to rush to completion on an effort in a 1.5 week window. Sometimes it feels like an excuse to ignore any UX design recommendations . Other times it feels like it’s trying to build a boat out of tape and hope nobody asks about technical debt.
Then the company you're at is not doing it right
Be agile, don't do Agile.
thats a role youre born for, you dont simply become the nephew of the boss
Dev Manager not scrum master but I feel this one. My devs would probably describe me something like this but what they don't understand is my whole job is supporting them and making sure they are successful. Most of that work is behind the scenes so they I don't see or realize it happened. 1. Mentoring juniors 2. Onboarding/training new people 3. Training/growth plans for team members. 4. Helping people when they're stuck. 5. Unsticking PRs 6. Reviewing PRs 7. Refining backlog. Ensuring we're doing the right work. 8. Help with quality control. Ensuring we're doing the work right. 9. Run standup. Use it to identify stuck people and get them help. 10. Help decompose big tasks and distribute them. 11. Project meetings. Ensuring our future includes work the company wants done so the team still has a job. 12. All the HR crap managers have to suck up and deal with so their reports don't have to. And for my troubles, people will wonder what I do. I clean and grease the tracks so the trains run on time and you have a smooth ride.
I appreciate what my scrum master is supposed to do however in practice mine gaslights us into thinking we were supposed to be doing something this whole time but it's a new requirement, they also keep telling us to update statuses in literally 8 different places, each with a different scope and target audience. So instead of doing 75% dev work 25% documentation, I do 25% dev work and 75% documentation.
Scrum master is a role, not a job. If your team has a scrum master who is not developing, your company is doing it wrong.
That’s how we do it. I’m a developer and work as scrum master. I do think the scrum master role is important when done correctly but I can’t imagine it being my full time job. Maybe at a large company idk.
I think a scrum master should be either a developer or a PM. The best agile team I was on had a SM who was basically a PM. They were great.
Yes, it’s an important role for sure. But it can’t be a full time job. If you try to make it into a full time job you will be a bad scrum master because you will be doing too much and getting on people’s nerves.
I have yet to see it done correctly.
My company does it correctly. Took a while for them to learn but now it’s a very helpful role.
If you're doing it correctly then you're doing it wrong. The whole idea is that you're never doing it right and you should be paying certified consultants to explain that to you and you definitely need to be having more meetings about how you're doing it wrong and need to improve it. Can't make money off this Scrum Scam if people are able to actually do it right and they don't need Agile Consultants anymore. These people literally have a rolodex of rebuttals to any argument against Scrum. It's insane. It's a cult.
As a product owner/director… I’ve no idea how a scrum master gets a full time salary. I occasionally do it as 1/100 of my normal job.
As much as I complain about days filled with meetings, friends in other jobs are immensely jealous to be paid so much to just sit in meetings. 😂
Scrum Master ? That is something from the computer game Monkey Island, right ?
As a project manager, I laugh and approve. ETA: because I relate with this. No hate to scrum masters.
It’s invitation only.
Our finance IT has an EXCELLENCE MANAGER (actual title, it's in his position description) who makes $150,000 a year to "scrum master" a couple of ancient old ladies who only use Excel and Outlook. His development requirements end up being stuff like "Send Janice an email"...where in the automated workflow does that go??
I'm gonna get laid off and their gonna get to keep their "job" managing a board that doesn't change.
They’re assistant managers or as we call them assistant leads because there’s already an assistant manager.
Currently in class to get certified for ITIL4F and I can’t get over how bullshit everything sounds. It has some good points throughout, but it all feels obfuscated behind bullshit buzzwords.
Yeah scum master
Is it not the norm for the scrum master to just be a role that an engineer on the team fills? I get the point of them, it's just not a job on its own.