Thread 106945186

Is scrum a cargo cult? What's the purpose? Jeet accomodation?

>>106945186 (OP)
justify work by doing nothing

>>106945186 (OP)
It works better than most alternatives

>>106945754
Is this the "culture" we are talking about?

>>106945186 (OP)
i could do more than all of them combined

it sucks being paid $0/h

>>106945186 (OP)
Depending on who you talk to, agile is supposed to be lean manufacturing for software. In practice it's about hyping up your employees to grind out 60 and 80 hour workweeks for whatever the latest 'sprint' is, and to shove barely functional products out the door. The goal becomes shoving updates out to convince clients to give you more money. It's effective at that.

Most agile evangelists will dance around topics like creating documentation. They'll say that documentation is wasted time, and that you just need to hire competent people to work on your projects. They also say that management oversight is bad and agile teams should self direct. Testing is time you could be spending developing new features, so better cut it. While those are true statements in theory, they immediately fall apart as soon as you start trying to scale, have to onboard new people, deal with people that can't communicate telepathically with each other or a variety of other issues.

Proper lean principles account for this. Yeah, time spent writing tests and validating code is "waste" in the literal sense of the word, but it's also essential to avoid pushing buggy slop out the door. I guess a counterargument for this is that software industry seems far more accepting of nonfunctional products than the hardware world, and lean also tends to gravitate towards the minimum viable product, but there's a pretty stark difference. I'd never trust a company that advertises an agile development process to make the backend code for something plugging into a database. Not unless I was OK with substantial downtime while doing a rollback or a restoration from backup. Manufacturing does have the benefit of being able to perform random samplings for inspection and rely on probabilities to detect problems. Software doesn't work that way because something as simple as failing to initialize a variable can cause data corruption in random things completely unrelated to that bug.

SCRUM and all its offshoots were designed to let non-technical people take over technical fields.

>>106945845
continued.

I've never witnessed a single talk given by an agile evangelist where they explain how to handle things like employees stealing shit. Lean manufacturing principles involve developing processes to mitigate threats like that, while agile just goes "hire good people hurrr" without any methodological criteria or explanation for how you do that.

TL;DR yeah. It is a cult. It doesn't provide a methodology for creating a process of continuous improvement, but instead expects blind adherence to what is effectively religious scripture, with the goal of shoving slop out the door as fast as possible.

>>106945856

Erik Meijer presentation wasn't enough of a clue?

https://www.youtube.com/watch?v=2u0sNRO-QKQ

>>106945186 (OP)
>first job in a startupish place without scrum (or any defined methodology)
>spec changes every week, priorities change every day, have a dozen git stashes for each ADHD demand from managers that i end up having to shelve
>change jobs to a place with scrum
>spend the sprints working on what i actually expected to work on at the beginning of each sprint
Guess which one i prefer.
I don't have to seethe about the scrum master's fake job either because SMs in our workplace have to also be POs or something similarly useful

>>106945186 (OP)
To give browns and women a place in söyciety by talking about work instead of working.

>>106945186 (OP)
Stupid
Childish
Hip
Nonsense

>>106945889
>45 minutes of complaining about agile.

Honestly, one of the few things I hate more than talks by agile evangelists is talks by people that hate agile. I skimmed through this talk and I broadly agree with most of the points I hit in the skim, but the guy comes across as yet another insufferable person looking to sell consulting services.

Maybe I'm just too jaded.

>>106945186 (OP)
Since the dawn of the human species, perhaps even before that, we have always engaged in group rituals. The actual content or purpose of the rituals doesn't matter. It's merely the fact of doing something as a group that satisfies a need of human psychology.

Modern white-collar labor is far too complicated to be managed by humans alone, so the vast majority is handled by software. But because humans are still technically necessary to use the software, coordination between the humans has to be maintained.

Thus it's like a giant never-ending group project. Which means the group has to perform rituals to maintain its cohesion and morale, otherwise the group naturally atomizes as individuals seek higher efficiency by monopolizing tasks. Group rituals halt that process by enforcing the idea that every person has an equal part to play, even though they certainly don't. In reality, the natural tendency of a group project is for the work to be centralized under one or a few specialized individuals while the rest are "extras". But this always leads the group organization to collapse, which is fatal for large or drawn-out projects.

If you ever find yourself asking "why are we having this meeting?" it's because human groups don't function without participation rituals. If you cut the rituals out you may see a boost in efficiency for a time, but eventually the monopolization of tasks leads to cratering efficiency and complete lack of organization or direction. Look at open-source or hobby projects for examples of this, they're often led by self-centered egomaniacs whose only consistent standard is whatever they personally like. Unfortunately those are the only two states of mankind, "selfish ape" and "monkey doing a rain dance". The latter can actually complete large projects sometimes.

>>106945186 (OP)
Developing software involves a lot of uncertainty. How long something is going to take to finish is tantamount to "how long is a piece of string". The people who came up with the original agile principles were trying to come up with a framework that tried to reduce the uncertainty and also added complexity that often comes with people adding process in an attempt to reduce that uncertainty. Professionals know to do manage that, how to balance getting the work done vs cutting corners to meet a deadline.

Scrum was a deliberate attempt to subvert the corporate world and inject some of the ideas behind 'the agile manifesto' to reduce uncertainty and unnecessary process for software development. But it ultimately failed in its goals. At best, it's just a raindance for better outcomes by people who have no idea how to develop software in the first place. At worst, the corporate bureaucracy and managerial machine has ultimately assimilated and subverted it to suit their own ends.

It's taken on a cult mentality now. Any valid criticism of how someone is doing scrum or any of these corporate "agile" variants like "SaFE" can be claimed as "not true agile", which is just the No True Scotsman fallacy. There is no reasoning with these people, livelihoods, budgets, and office politics mean that they can never understand why what they're doing is wasteful and a bad way to do things.

These days its main purpose is to serve as an accountability sink. I've yet to meet anyone who actually really knew their shit that took it seriously. There are countless examples (like Whatsapp) where they openly talked about how dumb or outright crazy "agile" is and how how they never used it but those counter examples don't matter to people who need to justify their own existence and engage in a sunk cost fallacy.

these 3 people do 99% of the work btw

Why there are no pictures of jeets doing scrum?

> This was a lightbulb moment for me to understand why people in India passionately love scrum. Thanks to scrum they can work in their very own comfort zone!

https://www.cio.com/article/251027/why-india-loves-scrum.html

>>106945186 (OP)
humiliation ritual

>>106945186 (OP)
Prime example of it being a cargo cult: me and a few colleagues split off from the software engineering team to go do data science, which is an entirely different discipline that does not fit the scrum process at all. Yet the guys in charge still try to force scrum upon us (spoiler: it's a disaster)

>>106946008
That first job sounds like a complete shitshow. If they had called themselves agile or scrum and engaged in standups or various other buzzword activities would you have a different outlook on them?

Probably not right? An unmitigated shitshow is a shitshow no matter what label you slap on it. There are plenty of places that call themselves agile that are exactly like your first job. The behavioral culture of an employer is far more important than whatever clownfuck label they assign to themselves.

>>106945856
>employees stealing shit
Whats this about?

>>106945186 (OP)
Don't you ever use "jeet" word.

>>106946075
Quality post

>>106946075
>Look at open-source or hobby projects for examples of this
we are talking about corporate world, genius

>>106946171
In manufacturing you frequently have high value tools and/or are working with semi precious metals and alloys. If you're working with brass or aluminum, the metal chips are worth actual money as scrap. Not crazy amounts, but enough that collecting them and sending them to be reprocessed adds a fair bit to your margins. Lean manufacturing processes will actually track how much of this stuff is going out and log it over time. This can be an early warning for defects in production, or a symptom of a machine that's having some kind of problem with some subsystem. It can also be a theft indicator.

It goes so far beyond that though because stealing valuable scrap actually makes sense. People will steal anything. They'll steal PPE. They'll steal paint. They'll steal fucking toilet paper. I've literally marched someone off the property because he stole a lightbulb. Guy was making 185ish k a year after incentives and he stole about 50 dollars in random crap that we caught in reviewing a month's worth of camera footage. Police reports were filed and he was told that he had to pay back the last year of bonuses, which was around 35k, or he'd be charged.

Some people want the thrill. Some people want to get one over on their boss, and some do it because it lets them feel like they're better than you. The last type will literally double down if you call them on it, and they may get violent.

Agile's response to this is literally just "hire good people, give them a budget, and let them self direct." Just do the magic thing and it'll work.
https://www.youtube.com/watch?v=vSnCeJEka_s&t=695s
This is from one of the more popular talks on agile and he directly states that you should not log expenses at a corporate level. OK, what do you do about the team that decides to hire a bunch of strippers and catering with their budget? There is zero protection from malicious employee theft because there is no expense logging because "that's waste."

>>106946685
As a side note on that talk, I've always found it hilarious how he uses Spotify as an example of agile scaling. Spotify hasn't used the "Spotify model" in years. He also says that a project with 500 people on it could be done by 5. Sure that might be true, if they're 500 agile developers, because flat management hiveminds don't scale.

Anyways, back to theft.

Ever wonder why many IT departments have a policy that requires them to physically destroy any equipment that they're retiring? It's because some fuckhead figured he could steal a year old workstation laptop with a discrete GPU, a projector, or something of that nature and got caught doing it because he was some combination of too retarded and to greedy. So now the company has an employee waste time drilling holes into monitors because they want to disincentivize theft. Agile tries to throw away oversight, so how does it catch employees that are having equipment "stolen." or those that are deliberately wasting money buying hardware they won't use so they can retire it and steel it.

Any company that claims to be agile is either violating fundamental agile principles, or they are putting themselves at enormous risk. You don't need to be a rocket surgeon to realize that none of them are the distilled "pure" form of agile that the consultants give sales pitches for. Nor do you need to be particularly smart to realize that all the statements they make are constructed in a way where when it doesn't work they can just go "oh you didn't do it hard enough. You never obtained true agility, so of course it didn't work. Pay me more money and I'll help you reach it."

It's like communism. In theory collective stuff sounds great. In reality it's a shitshow because a large enough percentage of the population are shitheads or so retarded they cannot function without someone assigning them tasks.

It promises a universally applicable good management style, which is very appealing to struggling organizations.
Imagine you are an executive at a struggling organization/department, and one of your issues is poor management. Which is more appealing?
>admit that your subordinates are incompetent and/or incompatible and replace or retrain your management, your software developers, or both
>claim that you just need this simple new management style and everything will be hunky-dory

>>106945186 (OP)
>purpose
humiliation ritual. reinforces submission to higher powers. bow before the scrumlords. submit your status reports to senior leaders. follow the codes of conducts

how else are you going to introduce good-for-nothing women into cosy tech jobs

>Is scrum a cargo cult?
Yes

>>106946086
Nah. It's the dude on the left with the laptop.

>>106946685
Right. I forgot that embeds don't work with timestamps. The timestamp is 11:35.

>>106945845
agile systems were designed for products that are already live. for that they sometimes work OK and keeps things regularly updated. but teams that try to use it when developing new products are retarded.

>>106945851
this. as well as "design thinking" process which then let non-design people inject themselves in design teams.

>>106945851
>non-technical
does this include a junior jeet with a fake diploma?
are you ready to make the connection?
are you familiar with a confidence con?
we'll empower you and let you play with your bussy while we will be replacing you with jeets

in the last 25 years stock valuations of the tech companies went up x100, while geek salary went up only x2
this should give you an idea which position on the totem pole is occupied by the geeks (hint: not very high)
I know, I know, you want to eat/sleep/code.
Unfortunately this kind of lifestyle can be easily outsourced to, yeah, you guessed it, jeets.

>>106945186 (OP)
you ask a scrum master what he's doing when he's not mastering a scrum and the answers might shock you

A scrum master is just a slave master whose job it is to whip the slaves to make them go faster. Without a slave master nothing would ever get done.

>>106948893
>>106949764

>>106945186 (OP)
It's 1/3 for wrangling jeetards, 1/3 for making middle managers appear useful, and the last 1/3 is for building effort consensus and fine-tuning velocity.

>Is scrum a cargo cult?
Yes, that's exactly what it is.

>>106947317
Timestamps work if you remove the 's' from after the number of seconds. Also as an aspiring corporate thief, you've changed my mind on agile. Going to start looking for those teams so I can up my paperclip collection game.

>>106946105

>>>/wsg/6004783

https://i.4cdn.org/wsg/1760971974899035.webm

blimp

>>106945186 (OP)
>>106945845
>>106945856
>>106948893
>>106950003
I studied business management and I'm now enrolling for Scrum Master/Product Owner, what's the big deal against the methodology?
Seems like the most reasonable approach to build something, short periods of time (3-4 weeks) where you can have then client/user feedback and plan the next cycle of work. It's just as simple as that, what's the big deal to be against with?

>>106951571
Nothing I just hate those stupid games.

>>106945186 (OP)
Before scrum we had that one guy from Office Space who dealt with the customers and brought their requirements to the programmers. He was usually an older programmer himself. They would leave the programmers alone as much as possible because if you bothered them they disliked it.

Now programmers are more like cogs in a machine and the machine is made of HR ladies, as business became more and more of a Jewish daycare over time you had to justify these peoples employment somehow. Meetings and scrums and etc. are how this is done according to standards and practices. And they will happen once, twice a day. Sometimes more. After scrum is a required birthday party and celebration of some diversity holiday we just made up too!

>>106951571
Because it is fucking gay

>>106951571
Actual answer? Is great on paper but non-tech idiots easily fuck it up
>Tons of pointless meetings, or not so pointless ones but still waste time and energy because the mid-manager could had send an email instead
>Instead of having one or two bosses you end up with 5-10 of them
>Despite everyone saying that they are a team, no one does actual teamwork because everyone just focus on his own sprints
Scrum only works when the mid managers actually have a tech background, the meetings are reduced at just the minimun and neccesary and between sprints managers actually allocate some time for the actual teamwork, specially to eliminate or prevent blockers which sometimes are totally managers fault

>>106951571
The key thing to understand about lean is that it's a self correcting process. Agile fails to provide a method to enact this, and scrum enforces such rigidity that it cannot be corrected.

Your goal in lean is to reduce waste. The majority of meetings are by definition waste, but there's an analysis that needs to be done to determine which type of waste is worse. You can't just let a pack of people loose and expect that they'll produce efficient work, so you need to devote some amount of time to information gathering and analysis. That analysis isn't static. It changes with the work and the environment over time. Some projects simply aren't going to require large meetings more than once every 3 to 6 months, and some projects are going to require daily interaction because of the amount of interwoven moving parts, the scope is changing, or you have some emergency crop up that requires immediate attention and then shuffling other aspects around to keep things flowing during and after the emergency.

If you actually want to boost productivity, your job as a manager is to be involved in the day to day operations as little as possible while maintaining productivity, and to keep your employees shielded from various flavors of bullshit. By all means, tell them what you're protecting from over the coffee pot, and provide feedback for the things that they're kvetching about. Sometimes that feedback is "yeah wouldn't that be nice. Unfortunately we need X, so you doing Y won't work" Sometimes its "yeah let me go ream IT a new one because that new AD policy is fucking you over and they need to knock it the fuck off."

>>106953333
If you do that, and the actual competent employees will never willingly leave unless they get enormous pay boosts. You act like the average scrum lobotomy patient, and competent employees will fucking hate you. If you're in a position where dicking over your employees lets you hit KPIs, then it's your choice to make, but do everyone a solid and don't pretend that you're helping anyone. Competent employees are going to see right through your bullshit, and if they've got an attitude, they will find a way to fuck you specifically on their way out the door.

>>106951571
The fucker you replied to literally explained everything that is wrong with agile and you have the gall to ask "durr whats the problem tho hurr"
please don't have children

>>106953462
It seemed like buzzword salad complain to me (no offense)

I'm reading a book called Scrum and XP and I've read about the methodology outside too and it never says anything about not making any space for implementing testing, in fact it emphasizes internal quality and that in those cases you should try to reduce story scope
I mean companies probably want to push features that create value more than allocating time for quality life things and other technical stuff, but that's a communication and management issue, not about the methodology itself is it?
Also why are you being mean to me? What is your problem? Don't you ever think there's a human that reads your message??

>>106954544
>It seemed like buzzword salad complain to me (no offense)
I could make some greentext here along the lines of
>Person studying management thinks well thought out criticism backed up with proof by example is buzzwords while using buzzwords like stories
And follow it up with a snarky comment about how the jokes practically write themselves.

Instead I'll try to answer this. I'm not shitting on you here, but this kind of disconnect is exactly why people have such a hatred for agile and scrum. You say that your books say scrum says one thing, I say that the say another, and provided a video example of how those words get shifted and applied by 'esteemed' consultants in the field, then stretched to absurdities by management in reality. Lean learned decades ago that seemingly minor details like the exact way something is phrased can be critical to conveying things in a manner that prevents confusion, frustration, and ultimately waste. There are plenty of companies that flounder about with that, but actual lean companies frequently audit their own internal communication systems to clear shit like this up.

Please go watch a few agile talks given by people in the consulting sphere and think about how agile and scrum are implemented in practice as opposed to how it's laid out in imaginary scenarios in books. The evangelists literally call for oversight to be slashed because it gets in the way. They're not completely wrong. It does get in the way of small teams of competent likeminded people. It's necessary for larger teams to function though, and that's where things break down. Not everyone is competent, not everyone is trustworthy, and not everyone actually wants to work. Your job as a manager is to piece a bunch of garbage together and get it to work. Handwaving that competency requirement away with magic rituals like standups is only going to serve to irritate the fuck out of the handful of actually competent people working for you.

>>106954544
>>106955208
Nobody actually talks like the book example in your picture. A good manager is already going to be aware of the issues, and if executive leadership isn't aware of it they damn well need to be able to explain it to them in terms that they can understand. You as a manager should be telling your team "alright we need to push out a hack fix for problem X" and then following it up with "what's the best thing to cut out of the schedule and why, and is there any better way to implement this hack fix so we don't want to kill ourselves 3 months from now." Bad managers will immediately become hostile to employees that raise issues like that because they turn it into a game of personal slights when you tell them they need to prioritize stuff. They want it all at half the price, and I'd go as far as to say that the majority of MBAs think that you can just tell people to hack something together faster and have it all work out. They'll pat themselves on the back for "motivating the team" while the project rots under them, and then they'll blame anything but themselves if it crumbles under their tenure.

>>106954544
>>106955208
>>106955241
Again, if you have a fat bonus tied to your ability to shove something vaguely functional out the door, fuck it, let the project implode behind you as you collect your check and leverage it into a bigger position elsewhere. That's the modern corporate way. Just stop fucking pretending that you're doing things for the good of the project. The only thing that pisses off a competent engineer, software or otherwise, more than some faggoty pencil pusher giving them lip service while trying to sneakily fuck them in the ass, is one that actually huffs their own farts hard enough to believe the shit dribbling out of their mouth is liquid gold.

Competent people aren't hard to work with. They're harder to fool. You will not fool the handful of highly productive people working under you unless you are a truly exceptional leader, so don't bother. Commiserate with them on the stupidity of what they're doing, and let them get on with it. None of that requires standup meetings scheduled weeks out in advanced. Nor does it require any of the retarded rituals like those pictured in the OP.

blimp

>>106951571
>I studied business management and I'm now enrolling for Scrum Master/Product Owner, what's the big deal against the methodology?

You just answered it yourself.

>>106946069
he says agile is a cancer and needs to be eliminated in the first couple of minutes

>>106955208
>>106955241
>>106955286
You're a good boss.

>>106951571
The Agile Manifesto makes some reasonable points. Scrum is a poor implementation of an Agile process, is overtly infantilizing, and lacks any resilience to bad actors. Competent people feel like their time is wasted and they're talked down to every step of the way meanwhile amoral climbers have every opportunity to blame everyone but themselves and make the least socially adept people on the team look like the losers. Everyone on paper paints a rosy story but when you start looking at how people actually perform work and go about their day, how social structures in a workplace function, it becomes blatantly obvious that Scrum in particular seems almost explicitly designed to kill productivity.

i don't know how gen x/late millennials managed to ruin tech as much as they did

>>106956969
yeah but if a person that has no business idea and aligns more with the technical side takes position of say Product Owner, then it would be hard to prioritize some business value as well, I think it needs a balance of both.

>>106955208
>>106955241
>>106955286
Ok thanks for taking time to layout your thoughts, I think deep down you're still more angry with people and how they implement Agile than with the ideas themselves (because it doesn't really say how to implement them anyway).

When it comes to actual implementation through Scrum:
Personally and without having worked yet, I think the overall thing doesn't sound bad, but I can see how it leads to some people getting pissed off with daily standup meetings (like actual standing up) or other rituals, but the core idea of delivering value through cycles where you can get feedback and then plan for the next while overall maintaining a big picture doesn't seem bad. The idea of sprint planning, or product backlogs, or retrospective meetings, separating functionalities in stories and breaking them down in tasks, those things don't seem like a waste of time at all and they seem useful for organizing things.
I'm not a software developer, but having coded as a hobby I know testing and internal code is important, but I think that's actually doable and compatible with the idea of a MVP. Like, yeah delivering a bare bones product sounds bad, but in software you have the luxury of actually being able to deliver updates later on the road (and your client/end user knows this) so you can start creating business value and bringing revenue earlier, which is good. What I'm saying is, don't get pissed off at the idea of MVP, but understand the business need for it.
My big takeaway from this kind of complaints is that management prioritizes business value to an extreme degree, that those who are supposed to bring some balance between the higher up (which are all for business value) and the engineer teams (which are all for code quality) probably end up taking business side and hurting the overall thing

>>106958139
>The Agile Manifesto makes some reasonable points.
Ehh.. I'd debate that. The manifesto page is literally done up the way your average Podunk church group webpge is, complete with vaguely fuzzed backgrounds, soft colors, and a site layout that was dated in 2010, and that's before you get to the part where they overlay plain black text onto an image. When I was first linked to that page I was absolutely convinced it was an elaborate shitpost. It's utterly inconceivable that that is a a real webpage made by actual developers that are genuinely trying to convince people that they are competent.

They never make any clear declarative statements of methodology. It's all wishy washy scripture. The list of points is vague and subject to fuzzy interpretation so that they can always wiggle around and say that you just didn't follow the principle correctly. If you refuse to engage in vague scripture interpretation semantics and instead take things at face value, many of the points are full of contradictions.
>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
>Agile processes promote sustainable development.
Ahh yes, it's totally sustainable to exclusively communicate via face to face meetings. Any time we onboard someone new they need to spend weeks of other people's time getting brought up to speed because anything that isn't face to face is inefficient and wasteful. That /totally/ makes sense.

>>106945186 (OP)
what is the purpose of scrum when you can vibe code everything?

>>106945186 (OP)
To accommodate MBA-s (jeet predecessors).

>>106945186 (OP)
Humiliation ritual

>>106958910
It's in large part a response to how existing engineering methodologies don't apply to software because, in large part, writing software is not engineering. Engineering as a discipline exists because iterating has a high cost. Conversely, iterating on software does not have nearly so high a cost, so obviously your methodologies and cost/benefit analyses are going to be different because the realm is different. Beyond that it's all hokum but the core point that waterfall heavy process bullshit that presumes once you deliver a product to a customer you can't change it in-situ simply doesn't apply to most software.

>>106958968
A self-imposed constraint? Who would have guessed geeks had such a poor imagination.

>>106945186 (OP)
i dont show up to standups. people got used to it.

>>106958909
>Ok thanks for taking time to layout your thoughts, I think deep down you're still more angry with people and how they implement Agile than with the ideas themselves (because it doesn't really say how to implement them anyway).
You'd be wrong in that assumption. I don't really care because I'm not in software (at least not anymore). I'm in operations technology and process/quality control in manufacturing. I've seen plenty of companies completely fuck up lean in ways that have bankrupted them. Software is the only industry that seems to celebrate these kinds of fuckups as a feature. When I've managed small development teams in the past, agile was the absolute last thing on my mind.

> the core idea of delivering value through cycles where you can get feedback and then plan for the next while overall maintaining a big picture doesn't seem bad.
If you can stick with it and actually plan long term, sure, that sounds good in a general sense. As a general principle, all of your ideas rely on interacting with customers and determining what they need, and that's a problem that agile and scrum don't really address. If you're doing this without interactions, you're just churning out stuff and claiming that it adds value with no rationale supporting such a claim.

So lets address that. What's more valuable? Shoving a new feature out the door with a hacky half-assed solution for something that is closely tied to that feature, or holding that feature and implementing both of them correctly the first time around, reducing total time invested because you aren't discarding work, and therefore being able to have both features released sooner. If you're dealing with webslop, the answer is often the first one, but in many industries the answer is the second one.

>>106958909
For example, infrastructure projects are very heavily slanted towards all or nothing solutions. There's no point in having a new AI image recognition system doing automated part inspections if it's less accurate than the humans were and it gets in their way. You cannot spin that as adding value until it reaches a threshold, and even then there are knock-on effects that may cause disruptions downstream because the new system has different criteria for how it fucks up than the old system did.

Of course there's also always option three. You're in a setting where the second option is better, but you can pad your company's expenses by doing the former, and maybe the people paying you won't notice. I'll again reiterate that if you've got a fat bonus tied to that kind of nonsense KPI, fuck it, go for it, but at least have the decency to not tell obvious lies about it.

I'll also note that many industries are mutually incompatible with many agile concepts due to regulatory reasons. If you push out half-assed webslop style development for a project that touches safety critical aerospace parts, the FAA is going to crawl so far up your ass you'll be able to taste the clipboard, and God himself couldn't save you if you tried that shit on a radiation sources used in the medical field, or anything else under the purview of the NRC.

>>106958909
Anyways, back to client interactions. When you get out in the real world, you'll find that a) not only are clients largely incapable of telling you what they actually want as well as being prone to bad communications b) the handful of clients that do have a clear idea in mind don't want to spend time interacting with you and just want you do do what their spec sheet calls for. Maybe you can string along the first one and upsell them on stuff, but the second one is going to get very obstinate /very/ fast once you cross a threshold that they will not tell you about beforehand because they believe that it should be obvious to anyone competent.

Those are social problems that require acute awareness to recognize, and agile/scrum do not address them in a meaningful capacity. Anything that can address those problems will typically be successful whether or not it's tied to agile or scrum. The funny thing is, Agile and scrum take it as a given that you'll be able to interact with clients and reach mutually beneficial agreements on a continuing basis. In many cases, that's simple fantasy that borders on delusion.

From my side of the equation, I've witnessed multiple companies trying to pull engineers in to talk shop about nonsensical gibberish with the spec requirements week after week, and I've seen a few of them get dropped hard enough that their grandchildren will be born with head trauma after not listening to corporate telling them very bluntly to knock it the fuck off and stop wasting our engineering team's time. We provide spec sheets for a reason. We're quite cognizant of how retarded some of our demands are, but we're trying to hedge against events that you probably won't understand, and which you truthfully do not need to. If you have an idea, sure, run it by us, but endless back and forth is not efficient.

Sometimes you'll land a client that wants something dumb and is willing to pay for it. The best you can do is, shut up, do it, and take the money.

>>106958968
> Engineering as a discipline exists because iterating has a high cost. Conversely, iterating on software does not have nearly so high a cost, so obviously your methodologies and cost/benefit analyses are going to be different because the realm is different.
As someone that's worked in both fields, I've felt that much of that is because many software companies don't really understand externalized costs. They spend a lot of time thinking about developer costs, but not much time thinking about the price their choices inflict upon their clients, and they seem to get very touchy about it when they deal with clients that understand those costs.

It's not like lean principles don't neatly adapt either. Automated testing might be a bitch to setup, but it can catch a lot of really esoteric edge cases. For the price of tens of dollars in your cloud budget, you can burn through an expansive test suite, and validate changes as not breaking things. Lean principles would arguably insist upon such testing, while agile seems to rail against it as wasteful. The only scenarios where that make any kind of sense are ones where they are conflating the reduction of development costs with providing value to a client, or ones where they're insisting on pushing out dozens or hundreds of micro patches every day. I'd argue that neither of those are good places to be.

I certainly wouldn't want something like the filesystem on my computer to be subject to such practices.