Agile Development - (is basically satan)

[Sneaky lurker]

you can ignore everything related to agile/scrum. everything about story points/velocity, sprints, sprint demos etc. is entirely nonsense. it's just an excuse to trap you in endless meetings about bullshit. at best you will have people dedicated to filling out the paperwork pretending that you're doing scrum to hide you from the rest of the organization (we call this kanban.) at worst you will have management whip a bunch of devs into producing potemkin village software and endless upon endless unimpressive demo.

my advice

• 

 

[herefortheactualthreads]

i wanna see the picture uncensored out of morbid curiosity. looks spooky and funny at the same time.

 

[Sneaky lurker]

i wanna see the picture uncensored out of morbid curiosity. looks spooky and funny at the same time.

 

[Ralph Epperson]

 

[Eternal Gopnik]

Agile is like communism. It "sounds good in theory", as long as you're willing to avoid actually thinking about it for even five seconds, and then some asshole implements it and suddenly there are a hundred million dead and no toilet paper. And then some fucking faggot comes along and goes "but but but that wasn't real agile!"

 

[DickMain]

Maybe I've been a simple forklift serf for too long, but reading about what this Agile shit is has me knowing less than before I asked. Everything I find to explain it is a soup of buzzwords.

 

[HairyBadger]

Agile development is the equivalent of "do it now" coupled with DEI incompetence trannies.

It doesn't work.

 

[Haramburger]

Maybe I've been a simple forklift serf for too long, but reading about what this Agile shit is has me knowing less than before I asked. Everything I find to explain it is a soup of buzzwords.

Coding & Development used to be "We're gonna plan for all these things/features/updates to go all at once (because the small handful of people who own/run your servers & environments only want the absolute bare minimum changes in one lump) in 4/6/8 weeks" to "we're gonna try to push as much through in 2 week windows, quadruple the meetings talking about why things aren't working or late, and pay for a bunch of corporate software that makes pie charts and graphs showing how much progress we do or don't make so we can loop leadership into more meetings justifying our existence"

It's kind of like how we used to shittalk cubicles & cubicle culture, but now everything is open office with no walls and it's immeasurably worse and we didn't know how good we had it with cubicles.

 

[DickMain]

we call this kanban

Had a job not long ago doing machine work on rifle barrels, and it was the first time I had ever heard of this dumbass program. We were made to fill out multiple cards a month which went right into the bin, but were still checked to make sure you weren't repeating the same corpospeak BS each time lol. Company before that, bought and liquidated by private equity imagine that, pushed that 6S system on us as well claiming that because it was JapCrap it would somehow stop our company from dying.

All I ever saw when these systems were introduced (in blue collar manufacturing fields!!) were waves of middle managers hired off the street (who knew nothing of what we did) to replace the production managers the investment firm fired. Anytime I'm doing assembly or labor and I hear we'll be implementing some shiny new workflow that brings me off production and into meetings I know that business will be dead within the year.

 

[dreamworks face]

i think the worst meetings were the "grooming" meetings (planning, not molesting children).

you would sit in a room and they would take user stories and you would have to estimate how long the user story would take to do. but you're not supposed to respond in "days", you're supposed to reply in "story points." the way this is done is through "planning poker" - everyone would be given decks of cards. the special property of these cards is that they would all have Fibonacci numbers on them (e.g. 1, 2, 3, 5, 8, 13). when deciding how long a user story is supposed to take, everyone was supposed to pick a card representing how "complex" they think the user story is. the person with the highest number wins, and that story number point number is used for the sprint. eventually using the cards becomes cumbersome, so you would just say numbers - man oh man do scrum masters sperg out if you say 4, you should try it.

anyway, what is supposed to happen is that you start by estimating that way, and then you get a feel for the "velocity" of the team - meaning story points / sprint. then in the future, you can figure out how the capacity of the team and how many user stories could be scheduled.

however, since every team has a different velocity and different meaning of what a story point is, that means that all this estimating is context free. like as a naive outsider, the reason i would estimate something is so i could figure out how long it is going to take to do, and when it is going to be ready. the reality in software is that we don't know, and that making guesses is useless. but rather than being like "fuck it, it'll be done when it's done" you end up going through a bunch of rituals to make it appear as though planning and estimation is happening even though the numbers are pulled out of someone's ass.

if this shit sounds batshit insane, that's because it is. in reality people start calling story points days and going through the motions with these meetings even though calling story points days subverts the lunatic intent of the planning altogether, and it's easier than arguing with the zealots.

 

[Tin Foil Hatter]

How much does the agile framework contribute to the current enshitification we are experiencing as a society?

 

[Harvey Danger]

pushed that 6S system on us as well claiming that because it was JapCrap it would somehow stop our company from dying.

Kanban originated in manufacturing, and it was one of the ways they became hyper-efficient in the 1980s to compete with the West. It came over to the US through car manufacturing. At least at the start, it was a great way to keep track of just-in-time inventory and factories... but just like Agile, it gets shoehorned into places it doesn't help. And of course managers will add management bloat on top of anything.

but you're not supposed to respond in "days", you're supposed to reply in "story points." the way this is done is through "planning poker"

This is a classic example of a terrible big system that started with a small good idea. In theory, giving an hours/days estimate will never be exact; software dev is just too complex for pinpoint accuracy. So you're supposed to measure in abstract points that compare relative levels of effort, not total effort. A 3 pt story is just slightly bigger than a 2 pt story, a 13 pt story takes nearly three times as long as a 5 pt story, etc. The Fibonacci numbering intentionally forces uneven comparisons, so you can never say 13 is exactly 3x5, etc. It's almost a vibes-based management style for schedules.

In reality, once you quantify something, managers will get super anal about the numbers. If you delivered fewer story points this sprint, pointy haired bosses can look at a dashboard and say "HUURRRRRRRR NUMBER GO DOWN! GO DOWN IS BAD!" They will demand a steady burn rate (I will stab the next motherfucker who uses that term) instead of the natural, unsteady feature delivery inherent to projects. It gets even worse if you're being monitored directly by a paying client.

however, since every team has a different velocity and different meaning of what a story point is, that means that all this estimating is context free. like as a naive outsider, the reason i would estimate something is so i could figure out how long it is going to take to do, and when it is going to be ready. the reality in software is that we don't know, and that making guesses is useless.

Good managers realize this, and manage accordingly. Bad managers don't, and demand predictability. Agile is the compromise between the two, and like all compromises, it makes nobody happy.

Part of the problem is Agile was originally designed to not give a fuck about outside perception, it was supposed to be internal to the team. Even though an outside "product owner" exists, they are brought in and made part of the team. But if you tell external management or bean counters "fuck you, we deliver when ready", they will chimp out. Half or more of modern Agile's bullshit is a compromise with external parties who don't trust devs to deliver on time or under budget.

Which answers the question:

How much does the agile framework contribute to the current enshitification we are experiencing as a society?

Agile is a symptom of enshitification, not a cause. If your team looked more like 1970s Bell Labs, 1980s MIT, or 1990s garage startups, nobody would dare question their velocity or hobble them with meetings. Agile is a harness non-technical people put on teams they think are measurable and controllable.

Managers would love to use something more draconian and quantifiable than Agile, but it's the corporate compromise currently in place.

 

[Haramburger]

if this shit sounds literally batshit insane, that's because it is.

I'm more concerned that I didn't have alarm bells when we started planning poker last year or two. Might be because I'm used to abstractions in weird board games, and story pointing is just a little like Who's Line Is It Anyways: "where the Jira cards are made up and the story points don't matter" The real funny part is in the retros, "lets vote on the confidence that we can get this done," "why did you vote this low?" You know why, bitch.

How much does the agile framework contribute to the current enshitification we are experiencing as a society?

When you can't collect your points on your Firehouse Sub purchase because the app is down, fucked-up agile updates to the site that probably didn't need to be done in the first place is why. That's what's affected me, I dunno what other apps you might have on your phones but if an app goes down for any length of time, jeets did it and this is why.

 

[SchloppyI.T.Man]

everything about story points/velocity, sprints, sprint demos etc. is entirely nonsense. it's just an excuse to trap you in endless meetings about bullshit

jeets love agile and scrum for some reason.

It's an Izzat factory nyukka

 

[teriyakiburns]

Kanban originated in manufacturing, and it was one of the ways they became hyper-efficient in the 1980s to compete with the West. It came over to the US through car manufacturing. At least at the start, it was a great way to keep track of just-in-time inventory and factories... but just like Agile, it gets shoehorned into places it doesn't help. And of course managers will add management bloat on top of anything.

The minute it transformed from "this is how we manage inventory" to "this is how we measure performance", it was ruined completely.

 

[HairyBadger]

Kanban worked for about 5 years before it became very inefficient.

I worked kanban in Rover, how did that work out?

 

[Archie_Kimkicker]

 

[Nero Fiddled]

Kanban worked for about 5 years before it became very inefficient.

I have a really nice screwdriver.
It worked really well for about 5 years but became really inefficient when I started using it as a hammer.

Kanban has just been leveraged into business areas that don't understand its purpose or limitations.

 

[Scale Smerch]

jeets love agile and scrum for some reason. nobody knows why

It's an Izzat factory nyukka

Entirely this. When you've got stand-ups, retros, planning, and grooming/refinement sessions that's a lot of meeting time for the average Jeet to directly puff up their work and accomplishments to management. It also makes their calendars look full which they think makes them look impressive come performance review time. The story point system adds another layer given the ambiguity of point value across organizations - let alone individual teams - letting Jeets deliberately over-weigh stories in further izzat harvesting (since higher weights obviously mean more consequential work).

 

[daolao]

My company is the customer, the software being iterated is the software used by the company to conduct our business. But we develop software very badly because we're not a software company.

Between that and how all of our internal tech support was outsourced a couple of years ago so an Indian company could "do it better," I'm seeing this massive fucking iceberg. It's made of bad ideas, poor leadership and pajeets, and my big ass company is going to crash into it sometime in the next year or two.

I worked in tech support for this company for about 8 years, supporting the software they're iterating and business processes related to the software. The environment which led to this has existed for awhile but it's getting much worse. The Agile bullshit gets attention from me because over the past few years they have been hiring scrum managers to go to meetings and talk about work that other people actually do instead of fixing the existing issues with the software we rely on to stay in business.

I'm not in support or software development anymore, I'm in the business end of the company after the outsourcing. But all the software I use? That's the shit developed in house, and it's getting worse. It was already shaky before, and some of this stuff has been "in development" for five or more years, but they keep shoving features into it in the live environment. It doesn't work like it's supposed to and thanks to the outsourcing there's no longer viable support for people like me who have technical issues with any complexity. It's getting harder and harder to just do our fucking jobs and take care of the customers who are keeping the lights on.

Sounds like a perfect storm of poor software development practices and lack of support. Have you considered seeking outside expertise? For example ai consulting services https://artjoker.net/services/ai-consulting/, who offer AI consulting services? Sometimes a structured, data-driven approach can help identify inefficiencies and improve processes without constantly putting out fires. Even if your company is not a primarily software-focused organization, engaging specialized guidance can prevent repeated mistakes and help your teams focus on real business outcomes.

Outsourcing and constant feature churn without stabilizing core systems often leads to degraded reliability and growing internal frustration over time!