Can you please activate your webcams?
Please choose a sticky note color to use for this meeting
Please take one of these smiley stickers and tell the others how you feel now
I just recently learned what “scrum manager” is and it sounds like a cult of useless middle managers.
I started at a new company and have been filling a scrum master role until they find me a replacement and I can move to the position I was supposed to be hired for and honestly, its the worst job I’ve ever had. Its literally hand holding and baby sitting. Its terrible. I almost got pushed in front of traffic when I asked “why cant the engineers move their own boards…?”
Your company and mine seem to be very different. We have agile coaches, but they mostly organise cooperation and shoulder check our stakeholders if they try to scope creep some bullshit in.
We also have agile coaches but the way my team uses jira is not at all how its supposed to be used. They are basically forcing it on us and people arent thrilled so the agile coaches are trying to mold it to what they want but they dont want it. Its a whole thing. Im also not a scrum master, Im an engineer pretending to be a scrum master as well as doing my other work and our agile coaches are…clueless for lack of a better word. Jira works great for our other teams. Just not the team Im on.
Yeah, that sucks. Let’s hope for better times my friend
Hey thanks I appreciate it. Like I said, just waiting for them to find a real scrum master for my team then I get to do my actual job but at least its pushing me into more of a “people skill” position. Trying to silver lining it haha
The temporary construct is the most durable of them all 😔
The dirty secret is there are no SCRUM masters.
There are engineers with SCRUM training. There are project managers with SCRUM training. There are product owners with SCRUM training.
The organization believes in SCRUM master as a discipline. Physics does not.
I’m not sure if I’m being sarcastic or not. Let’s call it 80/20.
checking in from the 45 minute “stand up” in which 10 people have their cameras on but only 3 people speak. So we all know we’re just working with the window as close to the camera as possible so it looks like we’re listening
One of the teams in my pod are SO BUSY right now and I know they dont want to be in a meeting every day and no one talks and I have to roll through this daily script and I am met with deafening silence and its crushing. I want to tell my boss “dude this isnt benefitting anyone” but its what the company wants. And everyone suffers for it.
no one talks
met with deafening silence
This reminds me of children who will get their toothbrush wet, put a little paste on their tongue so it smells like mint, run the water for 2 minutes, but not actually brush their teeth. You know, because they don’t want to, and/or they don’t understand the point.
They just know that the parents say they need to do this thing, and they’d rather be off playing. You’re standing there for two minutes holding a wet toothbrush and staring at yourself in the mirror. Why not just brush your teeth?
I get it, they’re very busy. They’re already gonna be on the call for 15 minutes. Just participate ya know. Why choose to make that 15 minutes a complete waste? I expect the above from a child, not people with jobs in tech =/
Scrum master = project manager.
Definitely not, Scrummasters should not be connected to the project at all. Their job goes directly against it, a PM is a stakeholder who will ask for everything to be done immediately, and needs to get stuff done. A Scrummaster should be neutral, and should uphold the process and defend the dev team.
Common scenario:
- PM: “I need this task done immediately”
- Scrummaster: “This task does not have any definition, and the team is already working on things. Once you have requirements we can discuss options on prioritization for next sprint”
That right there highlights where a scrummaster should be working. Most companies do treat them as neutered dogs though, and don’t give them the power. True scrummasters have the ability to push back on PMs and defend their teams, keeping developers out of it so they can stay heads down. (Less useless meetings)
A project manager should never be a stakeholder. A project manager should be managing expectations and pushing back against scope creep and ridiculous demands for immediate results as part of managing the project based on available resources and the estimates of the project team compared to overall progress. They will also address situations where different interacting parts need to be timed correctly, but that would also be the same responsibility of a scrum master, because they manage the project when using agile terms.
Most places treat project managers as neutered middle men who are implementing the will of the stakeholders, which is why so many end up being the terrible type that you are stereotyping project managers to be. Those same organizations will do the same thing to the scrum master or whatever name they give to the person who is supposed to be managing the project. You know, a project manager.
Probably right, in my experience you’re describing a Product Owner, someone who is neutral on the business side who takes care of prioritization in a netural way vs a Project Manager, who does have requests, asks, and demands of the dev team
That sounds awful, I feel for you.
I earned certification in the early days. “Scrum Master” was supposed to be a team member who took on the role of interacting with external stakeholders, and help the team organize the work.
The scrum master protects the team from interruptions and un-scheduled work and facilitates planning meetings.
More recent iterations minimized the Scrum Master as a first class role. Scrum Manager sounds like a new role the process.
I did a search, came up with this gem.
All the other search results did not have “scrum manager”, and the end of the video indicates this is not an official role in Scrum, but a term used for managers who are all in on the values of the scrum process.
Yup. The hard reality is corporate america doesn’t like the role because they literally are meant to disrupt and defend the team, to push back on business and show them when things aren’t realistic. So instead of making realistic asks for dev teams, they neutered the scrummaster and removed the position in most cases
Having worked in a lot of scrum teams in positions ranging from Jr Dev to CTO, I have become a huge proponent of scrum masters.
- The scrum setup is that way for a reason. The Stake Holders speak for the company, the devs speak for the infrastructure, the Scrum Master speaks for the process, and the PO is also there. And none do each others speaking jobs well. The process of scrum will tend to drift back toward dev burnout without a good SM.
- Devs shouldn’t be spending their time managing tickets, we should be developing. Backlog grooming, sprint ready ticket reviews, fighting with POs, stake holders, and Support, and fretting about velocity should be left to the scrum master.
- I will never again act as scrum master if I can help it.
And in my experience a SM becomes a full time position at about 15 devs.
Exactly right, scrummasters should be outside of the business and developer chain so they can uphold the process first and foremost. One of the phrases I hate the most is “we’re in crunch time, we don’t have time for process.” No, that’s when you need process the most! It doesn’t matter if it’s crunch time or whatever, PMs and business sometimes needs a reality check on what is possible and what isn’t, and developers need someone in their corner that isn’t also their manager.
From all of the replies it was to me that a Scrum Master can be very useful in specific projects that involve interplay between many departments. But in reality it seems like it’s a way for companies to avoid creating clear job requirements.
Def a way underrated comment.
- I will never again act as scrum master if I can help it.
Is why I joke that there are no SCRUM masters. Anecdotally, most of those I’ve met who were great at SCRUM mastering noped out of it within a year. It’s like physics abhors a great SCRUM master.
I’m currently assigning all of those responsibilities to the development manager and to the development team leads. That’s at least working without causing me to lose people.
Wait, are you talking about a scrum master under a different name or an actual position above that?
Honestly, I just heard of the turn “scrum” the other day on an application, and after some looking into what that is, I came to the conclusion that it’s the corporate version of a Liberal Arts degree. Not completely useless, but almost.
I’m sont have any influence on that applicant, btw, so I’m not influencing someone’s life based on my half assed googling.
Well, from experience I can say that scrum and a (good!) Scrum master can really turn things the right way.
Even something as simple as being the impartial moderator can be invaluable, given the borderline-autists many developers are (won’t even exclude myself there). A pointless 30min meeting can become a valuable sync up.
Apart from that a (again, good!) Scrum master can organize a lot of stuff away from the developer. The job literally means removing impediments and I’ve had the luck to work with one SM, who really took that seriously.
It’s not a management position, btw. At least it’s not supposed to be. It’s supposed to be on the same level as the devs. Unfortunately (and that’s the part where you are right), this position and scrum in general were churned through the corporate buzzword grinder so often, that it’s almost meaningless now and often enough just means pointless meetings and pointless metrics (ironically measured in “story points”).
depends how big the project is. large projects benefit from it being broken down into multiple smaller projects and communicated from week to week to coordinate. but smaller projects, it’s just a giant waste of time.
Yeah, I’m sure that position is actually useful when used for its intended purpose.
I am about 12 years into using Agile at my work place and I am about a decade in to being dumbfounded at the fucky implementations I read about in this type of post and it’s comments.
We are never asked to turn our cameras on during any of our agile related meetings. In any meetings really. Some people do it, some people don’t, I don’t think I’ve ever had someone ask me to turn my camera on at work.
How do you even set a color for a meeting? Is that an outlook thing? Are you scheduling meetings in JIRA? I honestly don’t even understand how one uses a color for a meeting. I would love an explanation of this :D
I’ve never once used a sticker, virtual or not, to tell others how I feel (at work). I’ll assume this is a retrospective thing. We mention anything that happened in the last sprint where we think we as a team need to do one of:
- Start doing X
- Keep doing X
- Stop doing X
Then the team has a quick anonymous vote and if we have a majority we either start, stop, or continue doing X.
e.g. “The slack workflow we implemented in our public channel last week was used 15 times. We should definitely keep prioritizing moving FAQ type items to slack workflows”
Quoting from some of the comments
Its literally hand holding and baby sitting.
That’s about your team and/or your teams leadership, not scrum.
checking in from the 45 minute “stand up” in which 10 people have their cameras on but only 3 people speak.
This is about your scrum masters inability to keep the meeting focused. We just do a straight up rotation, alphabetical by first name. Any time we are in danger of devolving into dev/engineering discussion our scrum master interjects and the conversation is saved for after standup or a meeting is setup depending on the topic. More often than not we give our updates and then say something like “JoBob I’ll need some time from you sometime today to discuss how to integrate with the thingamajig” or “After standup I’d like to talk to the team about XYZ”. We sometimes certainly have 3 people start trying to engineer a solution when someone says “I couldn’t figure out how to schoop the woop, so I’m still working on that.” but again our scrum master will say “Oh, JoBob is the schoop the woop SME, why don’t we chat it out after stand up”.
I hate that paragraph but I can’t find a good place to break it up, sorry.
Most of the complaints I see (overall, not just in this post/comments) come down to really basic shit:
- Your scrum master is fucking terrible at their job
- Your team actually does behave like a group of toddlers
- Your manager is actually a micromanager and this is just another micromanaging tool to them
- You’re bending your team/process to fit agile, and not bending agile to fit your team/process
I want to give two examples addressing my last list item.
First: We do not have stand ups scheduled 5 days a week. We found a cadence that makes sense for our teams work pace and our sprint duration.
Second: There’s such a thing as tasks that take less time/effort than writing the associated JIRA story would take. My team has agreed to just not bother with a story in these cases. It fits our workflow better and as a group of adult human beings we accept that it’s a waste of time/effort to write four paragraphs and a customer value statement for what essentially comes down to “type the number 70 into a form on a website and hit submit”.
Again as adult humans we also try to be aware of and avoid abuse of this mentality, and make sure we aren’t just doing mental gymnastics to avoid writing a story for something. When someone says “eeehhhh maybe we should throw a story on the backlog about that”, we just suck it up and do it.
This shit is so easy, and so helpful, it’s crazy to me how ridiculous y’all make the process.
edit: I will add that if you Masto-stalk me you’ll definitely find me bitching about long stand ups. FWIW that’s almost invariably when the scrum master is out and management has decided to run the meetings because none of the team felt like stepping up and doing it for a few days. i.e. it’s our own fault when it happens to us.
as a scrummaster who pleads incessently with management to let me actually run scrum correctly, this hits home, and it makes me sad. I could chat for hours with you about how stupid people ruin the Agile process
Really appreciate your based and realistic comment, thank you! Sound like a cool place to work at and shows, it can work out good.
I think the tool is very powerful and a benefit for all, but only when used right. Actually I find myself or at least my thoughts in almost all of your points about basic shit.
Edit: either I fckd up or the app but my reply about the cult thing was not meant to be a reply to your description and sharing
It IS a great place to work, and I absolutely hate that 20 years ago I post under this handle on stuff like “Ubersite” about how “We should stop saying ‘sucks’ for negative things. How do we expect to get blowjobs if we keep saying bad things ‘suck dick’”. Like I just can’t tie that to my employer as much as I’d like to hype them up to dev/engineers online :p
I’m sure the internet super sleuths can figure it out, but I can’t imagine why they would bother :p
You didn’t mess it up, it wasn’t posted as a reply to me, I just saw it in other parts of the comments :)
We had daily 45min+ stand-up at my old place, averaged 10 minutes per person. That team just reaaally loved meeting. Code was in de facto maintenance mode, even though there was years-long backlog and a shit tons of reasons to rework on the code base. It is like they hated coding, manager was old and he enforced coding standard like it was the early 00s, no OOP, no abstraction, bo new language features. Anyway, I disgress.
I raised the issue with the 15-25 hours of meeting per week and how little was being done, which I swear, they said was because we did not do enough “admin” and scrum work, and doubled down on the process. We were now expected to take 30min per day to write down how we spent our time to present to the team each retro.
Job was technically easy, because, well, we did very little technical stuff. I always had hated useless meetings, but I always managed to have some input on how to spend my time in othrr jobs. Someday I felt like crying in the morning before opening the mandatory webcam, thinking about the next hour of meeting, and I quit right then, I never joined another call and I kepty resignation to emails.
Good job getting the fuck out, that place sounds full to the brim with batshit insane management.
I lost a pretty substantial amount in stock options, this is why I stuck around. I was afraid to regret this decision my whole life. Well, years later I can tell you best fucking decision of the decade. I can make the money back, maybe, but the small chips of soul I lost in that environment will never grow back.
That’s about your team and/or your teams leadership, not scrum.
While true, that cuts both ways, a successful team is not successful because of ‘scrum’, it’s successful because it finds a methodology that works for them, which can be in terms of scrum, but even if no one was chanting Agile buzzwords, that team would still self organize in a similar way, just without the precise buzzwords.
What’s obnoxious is that a lot of folks, with a vested interest in, say, consulting, will give credit to “Agile” for teams succeeding and then simultaneously call all failures that ostensibly use Agile but fail “not true Agile”. It can be harmless enough when self-organizing, but then it doesn’t really matter if it is “big-A Agile” or not. People hung up on the “big-A Agile” may be expecting to cash in with consultancy money, or use it as a club to assert their authority by their self-proclaimed alignment to ‘Agile’. They are advocating for Agile, therefore if you challenge anything about their direction, they will invoke the magic Agile word to silence criticism about their methods. Once an organization has “acheived Agile”, ironically they frequently close the door on any consideration of methodology reform. “We are running Agile now, whatever you may think we are doing wrong the industry agrees with us because the industry uses Agile, so stop complaining”.
So Agile may be technically workable, but the frustration is that it is vague enough to allow anyone to do almost anything and still ‘fairly’ claim Agile, but as a brand word it confers unreasonable authority for certain folks. As the most prominent brand word in the world of project management, it is further correlated with the ‘default’ asserted methodology of any crappy group looking toward consultancy/self-help to fix their bad team situation with a bandaid of methodology.
They are advocating for agile, therefore if you challenge anything about their direction, they will invoke the magic Agile word to silence criticism about their methods.
It should be seen as a method that can be adjusted to the team, but this attitude blocks adjustments and improvements even before they start. Its even worse, people will just do anything “Scrum” tells them and reflecting, especially learning from the previous lessons, gets silently lost since the impression overcomes, that it is not allowed. From management side this is fully approved, I mean these people are expensive Scrum Masters, so they know what they do.
As you mentioned the team is the source of success, not the method itself. The “Don’t” stated previously is on point there:
You’re bending your team/process to fit agile, and not bending agile to fit your team/process
You’re bending your team/process to fit agile, and not bending agile to fit your team/process
Yeah, this one is tricky.
If a methodology is supposed to help, but you don’t change your processes in any way, then it seems odd to assert that you are “adopting” a methodology.
In fact, I would say that the typical dysfunctional Agile shop basically “bends agile” to fit their process, meaning they undertake a superficial exercise to map a problematic process to Agile terms and declare victory. Sometimes taking the time to actually make the process worse in a way they wanted to, under the smoke screen of “Agile transition”. For example, in my company customers are generally using our projects together, so we had basically a set cadence of release dates. All projects were only allowed to target designated release days (March 1st, June 1st, etc.) A project, if it made sense could skip a release window, but the projects wouldn’t just release 2 weeks differently than all the related projects. Project owners declared this “not Agile” and said everyone just release whenever, much to the complaints to customers that now have a barrage of updates that are in no way synced up, with QA that tried to use the projects as the customer would abolished, so until the customer there’s no one using the “current” editions of the projects together in one place. Agile is perfectly happy with a prescribed cadence (in fact I would say usually I hear the mantra that you try to fit your work to the schedule, rather than letting the work mess up the schedule), but development managers didn’t like the way the release schedule tied their hands so they blamed Agile for a really bad quality move.
I’m all about processes that fit your team, I just think fixation on Agile branding does more harm than good.
Good points.
One of my measures of an agile team is simply asking if they’re agile.
I’ve never had an agile team say “yes, we’re agile”.
Best answer I’ve had was. “we do these standard agile things, we cheat in these ways that work for us, and we’re currently adopting this process that we think we’ll help”.
Worst answer was “Yes. We’re all SCRUM certified.”
My intension was to make a harmless little fun about scrum masters who extensively use colors and communicate like they have a conversation with children.
Man if I had taken the fucking time to check which community this was post to, I could have saved myself a lot of typing since I wouldn’t have bothered with the comment section :D Good post tho!
I like some of the concepts of agile and scrum. Two week sprints rather than multi-year projects. Faster turn around on bugs. Having a prioritized backlog so we know what we are doing next. Small standups to get ahead of blockers. Spending less time documenting everything and more time developing. You don’t need a PM or scrum master in those things. A good team lead can do it. If the PM needs an update, they can look at the board.
A lot of the crap that gets add in to it is so freaking useless. There is an AVP at my company that keeps pushing everyone to sign and share team agreements so “there can accountability.” It’s so cringy. If someone is getting stuff done, do you really think having them sign something saying they will do it is going to help? If someone is getting stuff done, then it isn’t going to change anything. It’s infantalizing. So much of it is micromanagement and lack of team trust.
The last place i worked at they started pushing the same type of cringe. What made it worse was the PM/BA wasnt actually writing stories. One sprint I had 4 stories with just titles and “TBD” on the description. His boss was mad that my productivity was low when i couldnt do the work they couldn’t describe.
Good job not doing a murder! I don’t know if I could keep my cool at whomever allowed “TBD” to get into an active sprint.
How can you provide acceptable results if there is no acceptance criteria defined? Was “literally reads minds” on your job posting?!
The problem was that my boss was a title hopper and needed to fill his old position and he did it with yes men who wouldn’t stand up for anything. Meant that these yes men were also not the greatest at doing the rest of the job either.
They were expecting me to just do Hero Engineering by not objecting, put in more time and fill on the gap when theu couldn’t do their job. Was the first time in 20 years i ever was reprimanded, been praised at everything else I’ve done. So i knew at that point this was just a toxic place to work.
Sounds infuriating as hell. Props for your use of the past tense :D
Yeah, I’ve also found that having a great team lead and manager has been better than relying on a dedicated SCRUM master. (Beacuse my favorite SCRUM masters always take a promotion within a year.)
I do require my team to commit to and help me occasionally update a shared values document. I hate teams that don’t have one. Teams have so many unspoken agreements that are genuinely easy to just write down.
That said, I say screw “accountability”. I have the biggest paycheck on the team, so I can afford to keep the accountability to myself. My team has my back because I find them good pay and reasonable hours, not because of our of values document.
Of course. Management has to be able to understand them 😉
As manager, I have to say that is uncalled for. As a developer, I will say you are 100% accurate.
See, that’s the thing. You’ve also been in the dev role and not just a manager or only mostly a manager. Good manager have background in or at least understanding of the thing they’re managing.
And this may answers the question, who thought that developers shouldn’t talk about technical stuff in all of this process. Feels like enthusiasts meet up to talk about all but the common things.
One of the best managers I ever had would give his Python team guidance using Cobol terminology. Once I translated the Cobol into Python, his advice was invariably exactly right.
I love scrum. It’s an interesting implementation of the theory behind agile development that has been extended to the point that it’s like watching a ritual.
Every company has its own interpretation of scrum and the rules and roles that come with it.
Once per day, everyone stands up and gathers with kindred spirits to hold the daily stand up. This is almost always done standing because the scriptures say so.
The product owner pretends to be as external as possible to provide the right perspective despite just being someone within the team, like one of those fancily dressed up people in the rituals surrounding the UK elections.
The scrum master is like the shaman for the scrum rituals, spending days on complicated processes that don’t seem to add anything. They’re not the project manager, so they can only guide the rituals and gatherings and not the major forces behind life/projects.
As with many religious experiences, reflection is a critical part, and several different types of reflections are held to give everyone a chance to bring their lessons learnt to the community. After solemn reflection, the shaman will guide everyone towards a plan of development for the coming time.
The community works together on a colorful artwork called the “scrum board” on which bright, colourful shapes are placed. Some of those shapes and colours have meaning, but that depends on one’s community and its interpretation of the scripture. This artwork is worshipped as the guiding star by the community, and tarnishing it is met with severe consequences.
There are, of course, different churches of scrum. Some swear by paper plan poker, others have switched to digital. The exact interpretation of the scrum poker scripture can differ from office to office, but everyone agrees on the intent. Some companies have replaced the scrum poker ritual with alternative rituals.
In the end, for many companies scrum ends up being waterfall development with rituals. It’s a bit like atheist catholics, who have stopped believing in god but still go to church for the rituals and the sense of community.
Scrum is not the only religion. There are many others, each with their own rituals, religious figures, myth, and scripture.
My intension was to make a harmless little fun about scrum masters who extensively use colors and communicate like they have a conversation with children. But holly F this escalated quickly and just sounds creepy. Like a cult where non-believers are considered evil or unholy. Do these people still live in a reality where they go to work to earn money in first line? Are they hostile to people thinking different? Sorry, but this really creeps me out.
It’s literally just describing scrum and agile processes as if they were reporting on a cult/religion and its rituals. The bit at the end about it still being waterfall development with rituals actually got me pretty good lol
Only through true faith in scrum shall our software be finished and our income be guaranteed! The holy signs, only visible to the scrum manager and his close disciples, hidden deep within the sacred burn-down chart shall predict the future! We must put our faith in them, for only they can tell us if our release schedule harvest will bring us the sweet nector of short testing phases, or the hardships of many bugfix releases.
Expelled shall be the unbelievers whose heretic notions of waterfall design taunt the mighty scrum shamans! Those who do not follow the ways of scrum and refuse to partake in expanding our blessed JIRA board will be of no use to us righteous developers!
Now chant with us, followers of our sacred ideology, for we must never forget our essential guiding principles!
Initiate, plan, implement, review, release! Initiate, plan, implement, review, release! Initiate, plan, implement, review, release! Initiate, plan, implement, review, release! Initiate, plan, implement, review, release! Initiate, plan, implement, review, release! Initiate, plan, implement, review, release! Initiate, plan, implement, review, release!
Any common behaviour of any group of people tends to sound like a cult if you look at it from a distance and sprinkle a bit of religious wording in between. It’s a fun creative writing exercise. If you leave out the cult angle, it can actually be a good philosophical mechanism to think about how peculiar our “normal” behaviour is. Every culture has their own little unspoken rituals, expectations, and assumptions. https://en.wikipedia.org/wiki/Nacirema is the high-effort take on this, documenting American life from the perspective of an outside explorer as if Americans are some kind of uncontacted tribe.
Scrum is one of those processes people have come up with for very good reasons to solve real problems, but have been ossified by documentation, books, and business processes, turning it into something that’s half “good business practices that solve our work flow in a meaningful way” and half “we do this because it’s part of the steps we’ve been taught in college/during my scrum certification and because it’s The Rules”.
Oh God, you’re good…
You’re right, many things are just done, because “we always did like this” or its simple the only thing learned about scrum but never reflected or compared with the actual reality.
Simplicity is literally part of the point? Who wants to look at a flow chart when it just needs to be a few lists of tasks? The general design is still heavily inspired by physical cards or sticky notes, but it’s always been just a list of lists.
Funny how many people are joking around those weird activities for some of the meetings like stickers, 2 truths 1 lie, etc etc etc. And we still do it.
According cameras - it’s easier, but in my team we never forced anyone.
I don’t remember the source, could have been anything from Stand Up Comedy to someone I know IRL, but I feel like they really cracked the “2 truths 1 lie” code.
- My name is Korthrun.
- I use Lemmy.
- I truly believe that this is a high value exercise that we should continue on with.
deleted by creator
Yay, it’s Story Time! There will be milk and cookies, right?
Right?
Down with sprints! Down with weekly retros! Down with scrum masters! Down with burn down charts! Just give me a feature to work on and a tool to track tickets. Everything else can fuck off.
Scrummaster here. Interesting enough, Agile was built to be completely developer driven, to reduce meetings and stress on developers and reduce waste time. Instead we have what I have coined “corporate agile”. Agile has been bastardized and ruined by corporations to sneak in their bullshit.
For example, the most basic rule of Agile is that it should be Team driven. This means:
- The team should drive how many meetings happen and when they happen. (You always have a planning and daily standup, but length, time of day, how they run, should all be developer chosen)
- The team should decide kanban/sprints/sprint length, wip length, everything. They should decide what process works best for them, with hints and guidance from the scrummaster
- The team should decide what points mean and how they represent work items. Points should never be linked directly to time or be a limitation (i.e. you should never point something as ‘4’ hours, because now you have business looking at that like it’s some expectation, and all developers know that that doesn’t work.
Instead I’ve seen
- Director/senior business people demand extra meetings, followups, random bullshit meetings that are not relevant to the developers and really should have just a PO.
- Company wide mandates on sprint length, expected capacity per sprint, meetings, times, “one size fits all” when in reality no team is the same
- Points that are treated as punishments. “You said this would get done in 26 hours”. Code doesn’t work that way, and all it does is teach developers to lie.
So, I’m very burnt out as a scrummaster. We get no power, and us who truly do believe in true agile are shot down continuously because people who don’t understand developers or development want us to micromanage, and I hate micromanaging my teams. If they let me actually do my job I could get them all the data they need, but they think they know agile better than I do.
Thanks for letting me rant. I’m sorry Corporate Agile has failed you
Agreed in spirit, but this is the Internet, so here’s my unrequested take:
As a manager, if there’s only one part of the development process I’ll keep, it’s the retro. The retro is the critical bit that gives me insights to help get the rest unstuck.
Sprints have one and only one true purpose, I use them to tell stakeholders how long to fuck off and leave the dev team alone for, in a minimum of two week increments. I don’t think my team actually gives a rip what sprint we’re in.
I don’t do burn charts. I’ve never seen the point. I’m pretty good at telling stakeholders “it’s done when it’s done” and that sentence takes way less time than making a chart that says the same thing.
I do track total tickets closed because a big jump up or down in that number is a a leading sign of oncoming burnout.
I’ve appreciated great SCRUM masters, but I’ve never managed to keep that role filled long term.
Agile is definitely not for everyone and every team. This is quite the irony because it was meant to be completely flexible and beside retros, all this businsss jargon was not made up by the creators of agile.
In some positions I only wished to be left alone with the relevant developers and make progress. Ultimately I get intertwined in a billion different metting to “loop me in”, years later after leaving one of those companies, I like to think of the hundred of wasted meeting hours for stuff I never had to act on in the company.
So when I started in the current startup I am in, we did the anarchy approach of just give a feature to work on and a tool to track tickets for 3 years. Eventually as team leader we migrated to scrum development. And as the team has expanded I’ve actually gotten stricter about it.
The rituals of scrum seem pointless when you start out and with a team of less than 4 people but at 4+ people it’s important just to keep track of what on earth is happening in the team. Like end of sprint allows us to work out if things are vaguely on track. If they are not we can identify where the weaknesses are. Someone took on a task estimated at 8 story points and it took 2 weeks to do, need to find out what the issue is (usually because either because there is a knowledge gap in that aspect of the system or because the task just simply hasn’t been defined clearly enough and needs the product owner to give more details).
I never thought I’d be that guy who defends the scrum process but 5 years of being a team lead changes you.
Though because this system was one that evolved naturally as we grew and realised what we were doing as a company wasn’t working we largely avoided the corporate bullshittery version of scrum. We don’t have a scrum master, I’m the guy who is like “oi I need you in this meeting” to the product owners.
deleted by creator
