You must log in or register to comment.
Guess i got a blackout bingo on this one. Oof.
"Put all your changes on 3 separate sharepoint calendars a minimum of 2 weeks in advance. Also do the normal approval garbage in ServiceNow and attend a 2 hour CAB for final approval. If you didn’t select the right dropdown menu option in the ticket details, you’ll have to start this whole process over.
Also, why does it take you guys so long to get stuff done?"
Let’s not forget “We need this right away!” then it takes weeks to deploy because the people who requested it weren’t actually ready for it yet (if they don’t change their mind and decide they don’t actually want it at all).
It’s actually not a crime to mercy kill and dispose of the body of anyone who says “Well, it’s a simple task. Are you having difficulty?”.
It’s an obscure and weirdly specific law.
(This is a joke, of course.)
I have spent the past 20 years cultivating a variety of tones in which to utter my standard reply to such nonsense:
“Cool. You do it then.”
That’s a great way to handle it.
I like to pass them the ticket and schedule the next open hour on their calendar for them to teach me how to do it, if they’re a developer. Sometimes they do, because I was genuinely missing something easy. Usually they get to awkwardly discuss why they don’t have it done yet, either.
When the person isn’t even a developer, I’ll explain the usual process between developers, and give them a chance to beg their way out of it.
If they don’t beg off, I schedule them anyway and see if they can actually at least “rubber duck” me through the problem. (Sometimes it even works.)
I’ve had a couple peers discover (or rekindle) their love for development this way. Most just make up a reason not to make the meeting, though.
One of these is wage theft. Don’t enable that shit.
Yup. Not getting paid? Don’t work.
Forced to? We have a word for someone who is forced to work for no compensation… The word is slipping my mind, but I’m pretty sure the USA fought a civil war about it.
The “Story Points = Hours” hits so goddamn hard. Like, tell me you don’t fucking understand scrum without telling me you don’t understand scrum.
We had a nice, effective production process on my team until a middle manager assigned to communicate with us started in with the whole “We can’t spare this many points” bullshit.
Does 5 time trackers count as 5 points ?
“Its not in the budget to apply security patches this quarter”
Story points = hours
So what’s the actual error margin for estimating feature implementation time? It’s going to be nearly the whole thing, right?
The estimate is not a promise, it’s a guess. I prefer to estimate in sprints because that’s about the resolution we can have confidence in, but management want hours so my process is to estimate the number of hours in a sprint (73.5 for us) plus one sprint
200% overruns are common, especially when requirements change significantly
Wildly depends on the complexity of the feature. If it only takes 4 hours to implement, you might have good enough of an idea what needs to be done that you can estimate it with 1-hour-precision. That is, if you’re only doing things that you’ve done in a similar form before.
If the feature takes two weeks to implement, there’s so many steps involved in accomplishing that, that there’s a high chance for one of the steps to explode in complexity. Then you might be working on it for six weeks.
But yeah, I also double any estimate that I’m feeling, because reality shows that that ends up being more accurate, since I likely won’t have all complexity in mind, so in some sense my baseline assumed error is already 100%.
Hmm, so kinda O(n1.5) scaling? (Of the ratio between definitely required time and possibly required time, anyway, since a -110% error wouldn’t make sense)
Really not sure an estimate for algorithmic complexity is the right way to specify this. 😅
But if your supposed input unit is days, then I guess, yeah, that kind of works out.
All-day “Sprint Grooming” meeting
Might as well put the whole Agile/Scrum crap on there while you’re at it…
Disagree. My company does it well and I think it helps productivity across the board. My last job called our process agile and it was really just water-scrum-fall. Which was horrible and we devs were all miserable.
My experience with it was not like that… resources were thin but decision makers were poor at managing and simply wanted to take in the buzz to make it seem like they were doing better than they actually were. They could’ve made another Office Space movie about us. Needless to say, it’s no surprising the CTO left and later on the top division chief left… all the while, management kept putting pressure on making sure we fulfilled the caveats of agile/scrum even though we didn’t have the bandwidth to do all of it. Documentation is important, sure, but when management makes everything a P1 just cuz they failed to see things though… well, don’t find the time to put everything down in the kanban… yada yada yada. No thanks
But, is that a problem with Agile or with your company? That’s my point.
God, as a true scrummaster - one who believes in actual scrum - where the devs make the rules - not management… this hurts. This hurts so goddamn much.
- 4 hour planning? PMs shit the bed.
- Story points = hours? Micromanagement
- Estimate with that much accuracy? Micromanagement who are also terrible with managing their own schedules.
- It’s a simple task. - How would any business person know how long or expensive a dev task is.
And on and on, and of course you all know this. The term “Agile” has been so bastardized from it’s conception by management who think it’s a micromanagement tool. It’s quite literally the opposite. It’s mean to put the power in the hands of the developers - so they can be efficient and keep management out of their way. Management just couldn’t handle handing over a tiny bit of power though. Have to break the fundamental pillars of agile, like dictating what a point is, or how long things should take. Ugh.
I remember when I first read about AGILE. I was like “this is pretty cool - but there’s no way corporations will actually adopt this methodology without completely turning it into just a set of new names for the same shit they’ve always done.” Naturally, that’s exactly what happened.
I’ve had about three companies do agile correctly. They were either less than 10 people total or did not care at all. Any company with middle management dipped their toes in, I think because they need to prove their existence
My job uses Safe. It’s the bastardized scrum you speak of.
Are points the complexity, effort or time? Yes. No. No. Maybe. Yes. Who knows?
They also sum our teams capacity as if we are interchangeable cogs doing the 1 same simple task.
We have endless meetings. Daily 1hrs. Follow up to the follow up. Meeting to plan meetings. (I wish I was joking on this next on) Planning meetings to plan for the upcoming planning meetings.
It’s chaos.
It’s hell.
I get 5% as much actual work done as I used to. Not even joking. It’s bad.
Im not in the industry and the answer to my question might be part of the problem: have you tried to say something? / what was the outcome of you criticising the whole planning and meeting mentality?
Not the person you’re answering but usually these are not a root problem but only a symptom. The answer will range from being told that you are the problem to “let’s schedule a meeting to discuss that”.
The mentality usually stems from higher up, and you don’t really get to speak to people originating policy.
Yeah, if middle management micromanages you, that’s likely because their boss makes them answer some uncomfortable questions, if anything goes wrong.
Except traditional management is about removing as much power from the people that actually do the work as possible, so that’s why this bingo even exists.
who are these time wasters that just put bugs in their code. I mean come on.
PO: “Why does it seem like it takes a really long time to develop new features?”
Dev: “I’m glad you asked! We’ve got this piece of code (points at smoldering pile of spaghetti) that literally has to be changed every time we do anything. The person who wrote it has been gone for like four years. No one knows how it works and it’s central to the entire application. I would estimate that this easily doubles the time it takes to work each ticket. I’ve created a set of stories to rewrite this code. We just need your approval to bring it into an upcoming sprint.”
PO: “Can’t… Hear… Breaking… Up… Bad connection…”
Dev: “Uhhh… This isn’t a Teams meeting. You’re sitting in the room with us right now.”
PO: …
Dev: “We know you’re still here even if you’re not moving.”
PO: …
The person who wrote it has been gone for like four years
Four years? You gotta pump those numbers up. Those are rookie numbers.
I recently learned that a web app I wrote in 1999 (for Internet Explorer lol) is still in use by the company I wrote it for. And this app was basically a graphical front end sitting on top of a mainframe application that dated to the 1970s, so my app’s continued existence means that mainframe POS is still running, too. My app was written in Classic ASP and Visual Basic 6 - I truly pity whatever poor bastard has to keep supporting that shit. They probably have one ancient PC in a closet somewhere acting as the server for it.
