Bingo of crappy IT processes
Bingo of crappy IT processes
82 comments
-
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.
-
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.
-
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
-
-
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.
-
It's me, I do it. But only when I need something to do to stay awake in hour five of today's meetings to address the "quick turnaround" patch that I finished coding three weeks ago, but now they want a label to change and no one on the six teams that have somehow become involved seems to know who owns the package that the field the label represents belongs to, but they're absolutely certain we need to programmatically retrieve the text in case the package owner changes it at some point, and someone remembers that the original developer wrote code to get the label text 16 years ago, but it was removed from the program two years before the project started using source control, and they have an old installer around here somewhere that we can decompile or trace with Wireshark to get the right RPC name (sharing their screen while they have a rummage for it, natch), and someone else volunteers that they might know how to get a version of the server application from around that time since the client and server versions have to match, but it's technically the intellectual property of a different subcontractor who was just a guy in Alaska who passed away five years ago, but they're sure they can convince his estate to burn it to a disk and mail it to me if they can just find the contact information...
-
Move slow and break things
-
-
-
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.
-
-
-
Bikeshed? That's a new one for me.
-
Bikeshedding is when instead of making important, compex decisions that have consequences for being wrong, someone focuses on the simple, low impact, minimally important part of a project that has no consequences if its fucked up.
I think the term comes from construction projects where instead of finalizing the design of a complex building, the execs spend the entire time talking about bike parking on site. What color to have the roof, how many bikes it should hold, etc.
Bikeshedding is about offloading responsibility while still feigning involvement. You, the owner, avoid the whole part of your job youre paid for, i.e "making the hard decisions" and through misdirection and inaction, make someone else do it. That way you can blame them later if things go wrong, or take credit for their work if they go right.
-
Ooh, yeah, seen that one before. Thanks for the explanation!
-
-
I learned it maybe this week and I’m now upset that I can’t remember from where.
Edit: I have bikeshedded my way into finding where I heard it instead of doing something else. It’s this Zack Freedman video, and here’s a transcript screenshot.
-
-
”All features are xy problems”
”PM adds new features to the sprint faster than they’re solved”
”Each release require two weeks of testing”
”Each release introduces new bugs for customers despite the two weeks of testing”
-
We have the one hour daily meetings we call “standup” 🙄
-
Right? Minute 55-60 is the 15th minute. Fuck that. If it takes that long then the team is too big for agile or the scrum master had lost control.
-
-
Special prize for blackout?
A pizza party from 12-12:30, perhaps?
-
12:15. And you bring your own pizza. Best we can do because budgets been tight after we spent 7 million dollars on the new 3rd party software system. It's turnkey and will solve all our issues right out of the box though.
-
turnkey /tûrn′kē″/ noun
- The keeper of the keys in a prison; a jailer.
- A person who has charge of the keys of a prison, for opening and fastening the doors; a warder.
- An instrument with a hinged claw, -- used for extracting teeth with a twist.
Sounds about right.
-
-
-
“Shift left” by doing all the work yourself
Plan, design, code, test, debug, deploy, handle incidents, it’s all your job!
-
I would share this with my dev team
But the teams "scrum guide" and "product owner support" are on the chat and it would get my ass fired
-
I prefer the inclusive term of "Scrum Dumpster". It really works.
-
-
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.
-
-
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).
-
Couldn't even make the effort to figure out how many rows and columns a bingo card has...
-
They have been omitted and registered as technical debt but they went ahead with the release anyway since the CFO's assistant only needs about half these anyway. For the coming three sprints, we will hire an external dev to finalize the card while it is in production. Any other developments on this will go to the backlog until the release is done.
-
This is why I will never use my coding skills for profit, my head...
-
-
N * N
-
No.
-
-
-
Just another thing the Brits get wrong. want to lecture me on color vs colour now?
-
-
-
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.
-
-
-
"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?"
-
If story points are now hours, I hope you're fine with me putting a 40 on that ticket.
-
Storypoints are such an artificial concept it doesn't even make sense. Same thing with estimation though. Most numbers are "I pulled it out me arse" unless the task is a one line change. And even then, shit breaks and it becomes useless, so the one line change is estimated to be a day anyway
-
The idea with story points is you assign them consistently, so the team's velocity is meaningful.
One team might deliver 30 points in a sprint while another delivers 25 and they deliver the same amount of work
Of course management want to be able to use story points for tracking, they want to compare teams using them, so you end up with formulas for how many points to assign
Of course if they score you on points, they get more points, not more work and story points become useless
-
Somewhat agree, but since Scrum is supposed to be bent to the team's needs, it might differ from team to team, but it's fine as long as those numbers are consistently used in one team.
-
-
-
4 hour planning
I've seen projects where this was comically too high. But a lot more where it was horrifyingly agonizingly too low.
-
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.
-
When I started working for my current company there were really few meetings and I didn't know that it was possible. Everywhere I worked we had all the Scrum meetings and tech discussions meetings. At that time it was relatively a small company but not that small.
Now the company is getting bigger and some persons try to bring all the scrum shit. Even for small features, we do meetings to discuss them and last for hours. Some meetings have a big agenda that we always only tackle half of it. Sometimes we decide to do something with big impact and then someone suggests to include a person from another that doesn't even know our scope. And then we get "maybe we shouldn't do this as it will maybe have some negative impacts", "maybe we should add an exception" without even giving data to support their claim.
-
Unpaid overtime = work is just not going to be done.
-
That's what I do at work, even though I'm salary.
Management decided to hire a new guy and then have a round of layoffs within 6 months, effectively canning someone to replace him. Since then, we've had multiple times where we have hundreds of tickets sitting unassigned because there's more work than people. So shit sits and falls through the cracks until someone has time or something is on fire.
It fucking sucks, but eventually the bean counters will see that we actually needed that extra body....
-
We did have well over 100 tickets in the queue, now they split the support team into multiple sub support teams and each sub team has fewer tickets in their own queue. The total number is still massive but compartmentalising the problem makes most of it go away! I can filter it down to such a degree my queue is almost single figures by just ignoring everything else because that is someone elses problem.
Also my sub team doesn't have anyone to cover 1st line on some products so I am covering 1st line there as well as 2nd line. Upside is my stats look brilliant now that I am doing all the password reset tickets.
-
-
-
Going against the current for a couple of things, I guess, but there are two points there that I actually like, but probably not in the way they are usually implemented.
- 4 hours planning is bad if it's 4 hours sprint plannig. Then somebody should be sacrificed for the greater good, but for the love of god, can somebody take their time to plan features and architecture carefully before dumping stories for development? Smaller group and whole long term system overview. Let them spend 4 hours to make something coherent and elimitate tech-debt creation.
- 1 point = 1 hour is fine if you don't think that it's set in stone, but it allows for very easy sprint planning. If your ballpark estimate for the sprint is more than 20 hours/developer for the week, you are overplanning. Normalize creating tasks for thinking how to solve a fucking problem instead of saying it's complex.
-
I feel this. No one actually architect’s anymore. They just shit out their first thought and call it a day
-
"Its not in the budget to apply security patches this quarter"
-
Does 5 time trackers count as 5 points ?
-
Story points = hours
-
4x4 bingo?
-
Bing (or I guess to keep up with the song, _ingo)
-
-
Guess i got a blackout bingo on this one. Oof.
-
Nah, time tracking is often needed for tax purposes: companies can write off R&D expenses
-
It all depends on how time tracking is implemented.
Tell me I have to account for my time in 15-30 min increments? Fine, I can put it into a spreadsheet and track it.
Tell me I have to track real time spent? Get entirely fucked, and I hope you're ok with spending time fixing my time punches because I absolutely am going to forget to open or close a time entry because I'm working on 3-4 tasks at any given time.
I've done both, and while I won't intentionally sabotage the latter, my rampant ADHD and terrible memory have got my back on that one.
-
Yeah but that can be done after you're finished, definitely shouldn't be part of planning!
-
-
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%.
-
-
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
-
-
-
Do people not know how bingo cards work anymore?
82 comments