6 ms·
> Those four sentences are now an unchallenged way to better develop software in general Pure garbage. Those 4 "values" are incredibly destructive and have le
by g051051 5y ago
> Those four sentences are now an unchallenged way to better develop software in general
Pure garbage. Those 4 "values" are incredibly destructive and have led to far more problems than they ever potentially might have solved. You'll get plenty of challenge here, I'll wager.
> after over 20 years they proved their value empirically - but why is it that they make so much sense?
They don't. They certainly haven't proved their value empirically. For every "agile" success, there are countless failures, because "agile" isn't a magic bullet.
- indymike 5y ago> Pure garbage. Those 4 "values" are incredibly destructive and have led to far more problems than they ever potentially might have solved. - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan I'm not sure which of these four you believe has led to far more problems that they potentially may have solved. Maybe the contract negotiation part. In my experience the core values of agile were fine. Where agile often went off the rails is when people implemented agile in a way that contradicts the four values. Definitely not pure garbage. > You'll get plenty of challenge here, I'll wager. Please don't speak for me, thank you. I've done well with agile, and continue to do so.
- krona 5y ago> Where agile often went off the rails is when people implemented agile in a way that contradicts the four values I can't remember a discussion about Agile in which the No true Scotsman fallacy wasn't mentioned at least once.
- g051051 5y agoI've yet to meet an "agile" proponent that didn't act like a religious zealot.
- jdlshore 5y ago> No true Scotsman, or appeal to purity, is an informal fallacy in which one attempts to protect their universal generalization from a falsifying counterexample by excluding the counterexample improperly. (Wikipedia) Please explain how the statement you quoted relates to the One True Scotsman fallacy. “It doesn’t work because you’re doing it wrong” is not an example of the fallacy. (For example: “A: Light bulbs suck because they don’t light up when you smash them into your head. B: That’s not how lightbulbs work. A: No True Scotsman!” Yeah, no.)
- g051051 5y ago> Where agile often went off the rails is when people implemented agile in a way that contradicts the four values "If your attempt at agile goes off the rails, you probably implemented it in a way that contradicts the four values".
- solarengineer 5y ago"If you understand and apply these four values, you have a higher chance at delivery high-quality software reliably and on time"
- g051051 5y agoThat's a very reasonable statement, and is much easier to debate. In my experience, it's been the opposite...attempting to apply those four "value" results in more problems than it ever solves, because those four "values" are prioritizing the wrong things.
- jboy55 5y ago"If your attempt at agile resulted in a system that wasn't agile, then you probably implemented in a way that wasn't agile"
- deleted 5y ago[deleted]
- g051051 5y ago> In my experience the core values of agile were fine. Where agile often went off the rails is when people implemented agile in a way that contradicts the four values. Definitely not pure garbage. In my experience, "agile" went off the rails the day it was conceived. I've yet to see a legitimate implementation of "agile" that wasn't a cheat in some way. Specifically, any organization I've encountered that claimed to be successful as an "agile" organization wasn't actually being "agile"...they were saying they were "agile", but would abandon it where it conflicted with actually getting work done. > Please don't speak for me, thank you. I've done well with agile, and continue to do so. How could anything I wrote be construed as "speaking for you"? Pretty egotistical on your part to assume I was. Based on past "agile" posts, I expect that there will be considerable pushback on what OP presents as empirically proven truth.
- jboy55 5y ago>.they were saying they were "agile", but would abandon it where it conflicted with actually getting work done. Abandoning your process to get stuff done is within the manifesto. However, what I don't ever get about Agile naysayers is any process that would fix their issues with the organizations they encounter. No sociopathic, micromanaging organization will ever enact a process that makes being sociopathic and micromanaging to their engineers harder. The problem is those organizations, not the processes or frameworks. It makes as much sense as me saying every company I've worked for that made us use Python had an asshole as the CTO. Therefore, python causes asshole CTOs.
- g051051 5y agoBut why does it seem to be the case for every organization? Not just ones I personally worked for, but I get the same reports from peers all over the US, in very different businesses.
- jboy55 5y agoIts not. I have worked at a bunch. But let me repeat, it's not the process, its the managers that enact the process. Shitty management is everywhere, even within the same company, you can have some managers understand and push to build great software and never look at stats, where other managers just want commits per engineer to be higher. If you ask them, they will say they are being 'fair' and 'objective'. So, some managers are only interested in making sure engineers aren't slacking off, they'll measure any way they can. LOC, Commits, Story points, it doesn't matter what, they want the measure, they want to be able to put you on a pip if that metric goes too low.
- watwut 5y agoAgile never valued individuals. It does kinda values interactions, because it turns literally everything into formalized negotiation between multiple people. Which leads to social issues, but who cares, because agile dont actually value people. > Working software over comprehensive documentation We have no idea what our software should do nor whether it works. There is no place where you can learn how it works. It theoretically makes it easier to pretend it "works", because no one can tell whether it works. Practically, it never really works. > Customer collaboration over contract negotiation You mean constant negotiation all the time.
- g051051 5y ago100% agreement on all points.
- codr7 5y agoNothing is, but this is simply common sense. But anything threatening to rock the boat will be embraced and corrupted until it's worse than what came before, hence Scrum etc.