13 ms·

Understanding the reasoning behind the four agile values

56 points by rchaves 5y ago

necovek 5y ago
While I like the basic premise of embracing the uncertainty, I disagree that "nature" (evolutionary model) is the approach to follow: while it has produced marvelous results, "experiments" took way too long to learn from if they were progress/success or not. I think we should embrace experimentation, but we should improve on natural processes because we are smart, sentient beings, and there are things we can predict and measure much faster, and thus pivot much faster too (as an example, all genetic diseases that are commonly terminal after the early reproductive age in humans are likely to be carried on into descendants because, well, reproduction has already happened — it would take many generations for "nature" to weed out those diseases, but luckily, we've got medicine that helps us not even having to weed them all out, and does stop some altogether).
- cuillevel3 5y ago
  > Responding to change over following a plan Agile manifesto: "That is, while there is value in the items on the right, we value the items on the left more."
  - necovek 5y ago
    Whether nature follows a plan is up for debate. I am personally in the camp that it doesn't, but I understand if someone isn't. I am guessing that was not your point though, but that you simply missed that I was only complaining about strictly adhering to "natural" process which the OP seems to hold in very high regard (rightfully so, but they fail to mention that we can and should improve on them, which was the point I was making).
    - rchaves 5y ago
      I 100% agree, it was not my intention on the post that “nature” is the approach to follow completly, we don’t want to take million years randomly guessing for sure, just borrow a part of what nature does, which is facing the real world, letting some parts die and move on. I agree with your completion to the point
dang 5y ago
I edited the title because agile is one of those words that cause commenters to immediately react reflexively (yay agile or boo agile...but mostly boo) and this is a more thoughtful article that deserves better. (Side note - when we do this, we try always to use representative language from the article itself)
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 ago
      I'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.)
mobjack 5y ago
My issue is that much of Agile in practice ignores the first value and puts process over people. This is especially true with Scrum.
- DarknessFalls 5y ago
  Well how many points would you assign to that story?
  - mobjack 5y ago
    What is the definition of done?
    - g051051 5y ago
      We can discuss all that at the retro.
      - qqtt 5y ago
        Bring those action items to the grooming session.
        dopidopHN 5y ago
        I was told to use planning rather than grooming because it could offend our British partners. I suppose it’s because of a reference to sexual grooming ? Is that a English word only? Or maybe dog grooming is a touchy subject in the US. I have no idea, culture evade me often here. I sure did bring those items in grooming, it was promptly dismiss because too broad for the scope of the sprint at hand. and kept for retro, where it could be properly buried for 4-6 weeks while someone take it as a action item of the retro. The thing is : I kinda like Agile and Scrum. But it can become very circular if Product owner are not keeping everyone feets close to the fire.
        jordanbeiber 5y ago
throwaway984393 5y ago
Why the Four Agile Values don't work: 1. Nobody applies rigor to anything complicated anymore. The only way you can produce anything that works without rigor is to only produce very small things that you can prove work. So you can produce a lot of very small work and say "I'm developing so fast!", and meanwhile all the components connected together can be a tire fire. Short-term wins and long-term pain. This applies to a lot of the Agile process, but also the avoidance of processes and tools. Processes and tools can help or hurt, depending on how you use them. Even Agile is a process. 2. Working "software" is completely meaningless. What is actually valuable is a working solution to a user problem. I can make a program that very reliably spins in a loop forever, doing nothing. Who the fuck wants that? Not a user. And a large system, which is what a lot of software today is written for, cannot be connected together, operated, troubleshooted, etc without documentation. Nobody's going to be able to run your software or fix it when it breaks if they have no documentation, because they didn't write your software, so they have no fucking idea what to do with it. So we end up with a lot of unmaintainable widgets that don't solve user problems. 3. No software developer actually collaborates with a customer, because software developers have never cared about a customer. They care about their precious code, their algorithms, their design, their bugs, their tests. They don't care if the customer hates the software. I have literally never heard a developer utter the words "so how does the customer like the software?" This whole rule of customer collaboration is just an excuse not to have to think about a contract. 4. 'Responding to change' pretty much just means 'push out shit software and wait for bug reports'. For the first year of operation, Agile software is garbage. Because there was no coherent plan, it doesn't work for the customer, it isn't maintainable, and the other parts of a complex system that it operates as a part of will constantly break in weird ways. We don't need to make a plan, so we don't need to figure out how this thing is supposed to work, so in 6 months when we finally get around to a customer use case, we'll realize this architecture never would have worked within the constraints they're running it in. Software development is not 'too damn complex'. Software developers are just lazy. We know that, because developers brag about being lazy all the time (I do too). They have these huge egos, and they believe that they're intelligent or talented because they can design an efficient algorithm or create 'beautiful code'. But the end result of all that code is what matters, not the code itself. Agile is simply a 180-degree reaction to decades of work in developing processes that result in reliable solutions. The processes got complicated, so the software developers said, "fuck it, i'm just going to wing it". And as a result, most modern software is less reliable and more complicated than decades-old systems that are both simpler and solve more problems.
bitwize 5y ago
The one true takeaway of agile is measurement, metrics, and accountability. Your boss was sold on agile on the premise that it lets him keep continuous, precise tabs on you and the entire team, to ensure that y'all are hitting the OKRs for this quarter and so that when something goes wrong, the guilty party and what they did can be identified; or when the schedule slips, the laggard can be identified. This is the reason why shops are so gung ho about agile development. And this, I am forced to conclude, is agile. A game of Mornington Crescent in which the shop pretends to care about the stuff in the left column when the actual goal is to create a work environment so precisely measured, controlled, and optimized it makes Fred Taylor cum in his grave.
- dirkt 5y ago
  > Your boss was sold on agile on the premise that it lets him keep continuous, precise tabs on you and the entire team, to ensure that y'all are hitting the OKRs for this quarter and so that when something goes wrong, the guilty party and what they did can be identified; or when the schedule slips, the laggard can be identified. Which is exactly what agile NOT is, according to the core values...
erikerikson 5y ago
Agile, in a nutshell, says "let's stop being counterproductive (and miserable), it's better for everyone (except maybe sadists and masochists)". Most of us really want to get things done and sometimes it devolves into self serving tripe but I've been forced to spend 50% of a project planning and then get ridden and harried because that vicious choice that no engineer wanted (but each was forced to do) puts off delivery.
- g051051 5y ago
  > Agile, in a nutshell, says "let's stop being counterproductive (and miserable), it's better for everyone (except maybe sadists and masochists)". Where does "agile" say any of that?
  - erikerikson 5y ago
    You're right that agile is more positively stated and this declaration violates the more productive tone of the manifesto [0]. > Agile processes promote sustainable development Did I take license? I did. Yet, I was present for some of the unpleasant and ineffective abuses and waste that "agile" was a counteraction to. Although the same types of leaders continue to act against my interpretation's goal, the industry is broadly improved (though physics continues to allow for localized terribleness). There are those who act as though talent retention isn't an important factor in delivery but they can't talk to us because they're busy trying to mend their velocity. [0] https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html
deviation 5y ago
Great article. In my experience using agile, I haven't observed any failures- just failures from teams implementing it incorrectly. There are many billion dollar consulting companies that have completely committed to agile and are flourishing. If it were as garbage as many people in this thread are saying, I feel like we would see more concrete evidence of it. Source: Worked in agile teams on-and-off for ~5 years now, not at my current company.
- riffraff 5y ago
  my experience matches yours, but there's something to be scrutinized if a lot of people do something wrong. We can't keep telling people "you're holding it wrong". For agile, I believe what needs to be stressed is always: adapt the process to your team. A lot of the frustration is not with the agile manifesto, but with some externally enforced scrum/whatever.
jaybrendansmith 5y ago
Such negativity. It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. A total nightmare. Scrum and agile are absolutely wonderful in comparison. Yes, it provides for measurement and close management oversight, but it also does not impose impossible schedules with locked requirements. Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach. But where agile really shines is when the problem is poorly understood and the solution not well defined. In these cases agile can provide for project successes that would have led to certain failure in a waterfall world. It's likely not an overstatement that agile and iterative development has been the recipe behind web 2.0 and so much else in recent years.
- clumsysmurf 5y ago
  Projects were doing iterative development in the 50s, way before scrum or agile. “All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities.” — Weinberg G. M. (Project Mercury) I think many of the agile principles remain largely unpalatable to your typical command & control org structure. One of the main premises of Agile, is letting people closest to the work decide how they want to work. Instead, in many companies, the org co-opted the meaning of Agile for its own agenda. The PMO got what it wanted, putting heavily gated process on top of Scrum. Why Scrum? Because its push, of course (instead of pull). At the moment, my org is adopting SAFe, and PI planning, which has devolved into quarter long waterfalls for projects. We just use Scrum as 2 week waterfalls in the quarter waterfall.
- rramadass 5y ago
  Oh, Jeez; not this again. See Barry Boehm's https://en.wikipedia.org/wiki/Spiral_model https://en.wikipedia.org/wiki/Spiral_model for what has already been done correctly.
- watwut 5y ago
  I lived before agile came around. And bad the old days of waterfall are to large extend carricature. Maybe it existed in the horrible form agile advocates pretend, but I have no seen that. And for me, work was in fact more motivating before agile. Agile turned the work I really liked a lot into something you do for money. Agile at it best is tolerable. > Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach. It does not. It is micromanagement ritualized and it somehow leaves both customer and workers unhappy.
rramadass 5y ago
I wholeheartedly agree with trying to learn lessons from Taleb's writings and applying it to Software Project/Risk Management. OTOH, trying to interpret Agile/Scrum methodology in terms of the above is nothing more than Putting Lipstick on a Pig i.e. a valueless/useless endeavour.
- rchaves 5y ago
  If nothing, it was valuable for me already. My goal was not to preach agile (much less scrum), but to actually try to find a common rationale behind the good and bad experiences that people do feel they had coming from agile. And for me (maybe for other devs too), finding an explanation that makes sense, a more general theory, is very rewarding in itself, it allows contradictory ideas to fit together in my head
  - rramadass 5y ago
    If you are trying to figure out and model something in your mind, then i am fully there with you. The problem is your marrying it to Agile and its Manifesto. They are a bunch of platitudes, there is no exact definition far less a process/methodology, it can mean anything, everything and nothing in a given context and thus have nothing concrete to recommend themselves. As you can see in this thread, the words Agile/Scrum invoke rather strong feelings amongst the HN crowd and hence your message has gotten lost. Instead, if you were to do a article on what/how you feel Taleb's ideas can be applied to Software Project/Risk Management, that would be an interesting and welcome read.
rchaves 5y ago
My first experience with agile was not with Scrum but XP, and it was a very good one. There are so many people here conflating Agile with Scrum, and I shouldn’t be surprised I guess, but my goal was not to invoke the “No true Scotsman fallacy”, I don’t care about pointing who is agile and who is not, or what names you use for what, but I do care about the principles behind it, they can give us very good ideas on how to balance certainty vs uncertainty, upfront design vs feedback cycles, in whatever environment you are. Some environments you will need to balance more to one side, some more to the other.
- cudgy 5y ago
  What did you get out of XP? Didn’t XP promote pair programming? Personally hate the idea of pair programming and would never work for a company that requires it.
  - rchaves 5y ago
    Do you hate the idea of pair programming or the actual act? Have you tried it? It was indeed weird at first but then I had lots of fun from pairing, I really miss it since the whole corona started
cudgy 5y ago
Now that agile has been preached for over a decade, has software actually gotten “better” for end users? So much focus seems to be on anti-patterns like mining users of their information or minimizing costs by outsourcing development to cheap, unskilled contractor mills and churning out widgets to meet the mad march toward unicorn status along with all the other identical unicorny startups. The agile crowd talks about pleasing and providing the customers with a product that meets their needs, but is that what we are doing and has agile made this worse, not better?

56 points by rchaves 5y ago

While I like the basic premise of embracing the uncertainty, I disagree that "nature" (evolutionary model) is the approach to follow: while it has produced marvelous results, "experiments" took way too long to learn from if they were progress/success or not. I think we should embrace experimentation, but we should improve on natural processes because we are smart, sentient beings, and there are things we can predict and measure much faster, and thus pivot much faster too (as an example, all genetic diseases that are commonly terminal after the early reproductive age in humans are likely to be carried on into descendants because, well, reproduction has already happened — it would take many generations for "nature" to weed out those diseases, but luckily, we've got medicine that helps us not even having to weed them all out, and does stop some altogether).

cuillevel3 5y ago
> Responding to change over following a plan Agile manifesto: "That is, while there is value in the items on the right, we value the items on the left more."
- necovek 5y ago
  Whether nature follows a plan is up for debate. I am personally in the camp that it doesn't, but I understand if someone isn't. I am guessing that was not your point though, but that you simply missed that I was only complaining about strictly adhering to "natural" process which the OP seems to hold in very high regard (rightfully so, but they fail to mention that we can and should improve on them, which was the point I was making).
  - rchaves 5y ago
    I 100% agree, it was not my intention on the post that “nature” is the approach to follow completly, we don’t want to take million years randomly guessing for sure, just borrow a part of what nature does, which is facing the real world, letting some parts die and move on. I agree with your completion to the point

dang 5y ago

I edited the title because agile is one of those words that cause commenters to immediately react reflexively (yay agile or boo agile...but mostly boo) and this is a more thoughtful article that deserves better. (Side note - when we do this, we try always to use representative language from the article itself)

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 ago
    I'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.)

mobjack 5y ago

My issue is that much of Agile in practice ignores the first value and puts process over people. This is especially true with Scrum.

DarknessFalls 5y ago
Well how many points would you assign to that story?
- mobjack 5y ago
  What is the definition of done?
  - g051051 5y ago
    We can discuss all that at the retro.
    - qqtt 5y ago
      Bring those action items to the grooming session.
      - dopidopHN 5y ago
        I was told to use planning rather than grooming because it could offend our British partners. I suppose it’s because of a reference to sexual grooming ? Is that a English word only? Or maybe dog grooming is a touchy subject in the US. I have no idea, culture evade me often here. I sure did bring those items in grooming, it was promptly dismiss because too broad for the scope of the sprint at hand. and kept for retro, where it could be properly buried for 4-6 weeks while someone take it as a action item of the retro. The thing is : I kinda like Agile and Scrum. But it can become very circular if Product owner are not keeping everyone feets close to the fire.
        jordanbeiber 5y ago

throwaway984393 5y ago

Why the Four Agile Values don't work: 1. Nobody applies rigor to anything complicated anymore. The only way you can produce anything that works without rigor is to only produce very small things that you can prove work. So you can produce a lot of very small work and say "I'm developing so fast!", and meanwhile all the components connected together can be a tire fire. Short-term wins and long-term pain. This applies to a lot of the Agile process, but also the avoidance of processes and tools. Processes and tools can help or hurt, depending on how you use them. Even Agile is a process. 2. Working "software" is completely meaningless. What is actually valuable is a working solution to a user problem. I can make a program that very reliably spins in a loop forever, doing nothing. Who the fuck wants that? Not a user. And a large system, which is what a lot of software today is written for, cannot be connected together, operated, troubleshooted, etc without documentation. Nobody's going to be able to run your software or fix it when it breaks if they have no documentation, because they didn't write your software, so they have no fucking idea what to do with it. So we end up with a lot of unmaintainable widgets that don't solve user problems. 3. No software developer actually collaborates with a customer, because software developers have never cared about a customer. They care about their precious code, their algorithms, their design, their bugs, their tests. They don't care if the customer hates the software. I have literally never heard a developer utter the words "so how does the customer like the software?" This whole rule of customer collaboration is just an excuse not to have to think about a contract. 4. 'Responding to change' pretty much just means 'push out shit software and wait for bug reports'. For the first year of operation, Agile software is garbage. Because there was no coherent plan, it doesn't work for the customer, it isn't maintainable, and the other parts of a complex system that it operates as a part of will constantly break in weird ways. We don't need to make a plan, so we don't need to figure out how this thing is supposed to work, so in 6 months when we finally get around to a customer use case, we'll realize this architecture never would have worked within the constraints they're running it in. Software development is not 'too damn complex'. Software developers are just lazy. We know that, because developers brag about being lazy all the time (I do too). They have these huge egos, and they believe that they're intelligent or talented because they can design an efficient algorithm or create 'beautiful code'. But the end result of all that code is what matters, not the code itself. Agile is simply a 180-degree reaction to decades of work in developing processes that result in reliable solutions. The processes got complicated, so the software developers said, "fuck it, i'm just going to wing it". And as a result, most modern software is less reliable and more complicated than decades-old systems that are both simpler and solve more problems.

bitwize 5y ago

The one true takeaway of agile is measurement, metrics, and accountability. Your boss was sold on agile on the premise that it lets him keep continuous, precise tabs on you and the entire team, to ensure that y'all are hitting the OKRs for this quarter and so that when something goes wrong, the guilty party and what they did can be identified; or when the schedule slips, the laggard can be identified. This is the reason why shops are so gung ho about agile development. And this, I am forced to conclude, is agile. A game of Mornington Crescent in which the shop pretends to care about the stuff in the left column when the actual goal is to create a work environment so precisely measured, controlled, and optimized it makes Fred Taylor cum in his grave.

dirkt 5y ago
> Your boss was sold on agile on the premise that it lets him keep continuous, precise tabs on you and the entire team, to ensure that y'all are hitting the OKRs for this quarter and so that when something goes wrong, the guilty party and what they did can be identified; or when the schedule slips, the laggard can be identified. Which is exactly what agile NOT is, according to the core values...

erikerikson 5y ago

Agile, in a nutshell, says "let's stop being counterproductive (and miserable), it's better for everyone (except maybe sadists and masochists)". Most of us really want to get things done and sometimes it devolves into self serving tripe but I've been forced to spend 50% of a project planning and then get ridden and harried because that vicious choice that no engineer wanted (but each was forced to do) puts off delivery.

g051051 5y ago
> Agile, in a nutshell, says "let's stop being counterproductive (and miserable), it's better for everyone (except maybe sadists and masochists)". Where does "agile" say any of that?
- erikerikson 5y ago
  You're right that agile is more positively stated and this declaration violates the more productive tone of the manifesto [0]. > Agile processes promote sustainable development Did I take license? I did. Yet, I was present for some of the unpleasant and ineffective abuses and waste that "agile" was a counteraction to. Although the same types of leaders continue to act against my interpretation's goal, the industry is broadly improved (though physics continues to allow for localized terribleness). There are those who act as though talent retention isn't an important factor in delivery but they can't talk to us because they're busy trying to mend their velocity. [0] https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html

deviation 5y ago

Great article. In my experience using agile, I haven't observed any failures- just failures from teams implementing it incorrectly. There are many billion dollar consulting companies that have completely committed to agile and are flourishing. If it were as garbage as many people in this thread are saying, I feel like we would see more concrete evidence of it. Source: Worked in agile teams on-and-off for ~5 years now, not at my current company.

riffraff 5y ago
my experience matches yours, but there's something to be scrutinized if a lot of people do something wrong. We can't keep telling people "you're holding it wrong". For agile, I believe what needs to be stressed is always: adapt the process to your team. A lot of the frustration is not with the agile manifesto, but with some externally enforced scrum/whatever.

jaybrendansmith 5y ago

Such negativity. It seems many on this thread did not live through the bad old days of waterfall and .mil standard development. A total nightmare. Scrum and agile are absolutely wonderful in comparison. Yes, it provides for measurement and close management oversight, but it also does not impose impossible schedules with locked requirements. Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach. But where agile really shines is when the problem is poorly understood and the solution not well defined. In these cases agile can provide for project successes that would have led to certain failure in a waterfall world. It's likely not an overstatement that agile and iterative development has been the recipe behind web 2.0 and so much else in recent years.

clumsysmurf 5y ago
Projects were doing iterative development in the 50s, way before scrum or agile. “All of us, as far as I can remember, thought waterfalling of a huge project was rather stupid, or at least ignorant of the realities.” — Weinberg G. M. (Project Mercury) I think many of the agile principles remain largely unpalatable to your typical command & control org structure. One of the main premises of Agile, is letting people closest to the work decide how they want to work. Instead, in many companies, the org co-opted the meaning of Agile for its own agenda. The PMO got what it wanted, putting heavily gated process on top of Scrum. Why Scrum? Because its push, of course (instead of pull). At the moment, my org is adopting SAFe, and PI planning, which has devolved into quarter long waterfalls for projects. We just use Scrum as 2 week waterfalls in the quarter waterfall.
rramadass 5y ago
Oh, Jeez; not this again. See Barry Boehm's https://en.wikipedia.org/wiki/Spiral_model https://en.wikipedia.org/wiki/Spiral_model for what has already been done correctly.
watwut 5y ago
I lived before agile came around. And bad the old days of waterfall are to large extend carricature. Maybe it existed in the horrible form agile advocates pretend, but I have no seen that. And for me, work was in fact more motivating before agile. Agile turned the work I really liked a lot into something you do for money. Agile at it best is tolerable. > Sometimes a problem and the solution are well-understood, and in these cases scrum works as a decent project management approach. It does not. It is micromanagement ritualized and it somehow leaves both customer and workers unhappy.

rramadass 5y ago

I wholeheartedly agree with trying to learn lessons from Taleb's writings and applying it to Software Project/Risk Management. OTOH, trying to interpret Agile/Scrum methodology in terms of the above is nothing more than Putting Lipstick on a Pig i.e. a valueless/useless endeavour.

rchaves 5y ago
If nothing, it was valuable for me already. My goal was not to preach agile (much less scrum), but to actually try to find a common rationale behind the good and bad experiences that people do feel they had coming from agile. And for me (maybe for other devs too), finding an explanation that makes sense, a more general theory, is very rewarding in itself, it allows contradictory ideas to fit together in my head
- rramadass 5y ago
  If you are trying to figure out and model something in your mind, then i am fully there with you. The problem is your marrying it to Agile and its Manifesto. They are a bunch of platitudes, there is no exact definition far less a process/methodology, it can mean anything, everything and nothing in a given context and thus have nothing concrete to recommend themselves. As you can see in this thread, the words Agile/Scrum invoke rather strong feelings amongst the HN crowd and hence your message has gotten lost. Instead, if you were to do a article on what/how you feel Taleb's ideas can be applied to Software Project/Risk Management, that would be an interesting and welcome read.

rchaves 5y ago

My first experience with agile was not with Scrum but XP, and it was a very good one. There are so many people here conflating Agile with Scrum, and I shouldn’t be surprised I guess, but my goal was not to invoke the “No true Scotsman fallacy”, I don’t care about pointing who is agile and who is not, or what names you use for what, but I do care about the principles behind it, they can give us very good ideas on how to balance certainty vs uncertainty, upfront design vs feedback cycles, in whatever environment you are. Some environments you will need to balance more to one side, some more to the other.

cudgy 5y ago
What did you get out of XP? Didn’t XP promote pair programming? Personally hate the idea of pair programming and would never work for a company that requires it.
- rchaves 5y ago
  Do you hate the idea of pair programming or the actual act? Have you tried it? It was indeed weird at first but then I had lots of fun from pairing, I really miss it since the whole corona started

cudgy 5y ago

Now that agile has been preached for over a decade, has software actually gotten “better” for end users? So much focus seems to be on anti-patterns like mining users of their information or minimizing costs by outsourcing development to cheap, unskilled contractor mills and churning out widgets to meet the mad march toward unicorn status along with all the other identical unicorny startups. The agile crowd talks about pleasing and providing the customers with a product that meets their needs, but is that what we are doing and has agile made this worse, not better?