6 ms·

This is the same extreme reaction people had previously to waterfall. Any methodology fails if it gets applied blindly and wrongly. You have to be willing to ad

This is the same extreme reaction people had previously to waterfall. Any methodology fails if it gets applied blindly and wrongly. You have to be willing to adapt it to your specific environment until it works for you. It would be a huge mistake to go back to waterfall just because people perverted Agile into a micromanagement method. The same people who can't make Agile work will also fail (and have failed for a long time) with waterfall or any other method because they refuse to adapt to reality and instead want work instructions they can follow without any thought. The same thing goes on with OOP. It started out as a good addition to other programming styles, got turned into a religion ("you can't do this. It's not OOP.") and now into a pariah (FP is next to go through this cycle). In the end stupid people will mess up anything they touch and good people will adapt things until they work.

monocasa 9y ago
> This is the same extreme reaction people had previously to waterfall I mean... there's no correct application of waterfall. The whole waterfall process comes from a paper as an example of how not to run an engineering project.
- maxxxxx 9y ago
  I have seen projects where there was a very good specification upfront and the developers pretty much just had to work through it. This is not always possible and requires a very good understanding of the problem but it can work really well.
  - jaggederest 9y ago
    It comes down essentially to that understanding. For well-understood problems waterfall might even be the best possible method. It's only for not well understood problems that it fails so completely. In software, in my opinion, fewer problems are well understood at the moment, and so we tend to avoid waterfall. However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems. The same is true for many other real life "waterfall" processes, like buildings, or bridges.
    - keithnz 9y ago
      actually buildings and bridges aren't really waterfall the way they are designed. They have similar issues with changing requirements, new insights etc as the project progresses. The actual construction is not really the equivalent of writing code in this world.
      - monocasa 9y ago
        And even during construction, you find new issues that you have to work around on any non trivial project. Source: was a commercial interiors contractor before I was a software engineer.
    - msla 9y ago
      > In software, in my opinion, fewer problems are well understood at the moment, and so we tend to avoid waterfall. Or if the problem is that well-understood, there's an off-the-shelf solution so good nobody seriously thinks about re-implementing it. > However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems. Exactly. That's barely software development. That's using fully-commoditized components in well-understood fashions to achieve a well-understood goal. You could script that. I'm sure some places have.
  - monocasa 9y ago
    Just because you either lucked out, or didn't have the testing to find what actually broke, doesn't make waterfall a good model. The most well defined piece of software I know of, sel4, had a full machine checkable formal proof up front, and they still ran into issues during implementation that required them to go back and modify the spec.
    - maxxxxx 9y ago
      You have a very extreme definition of waterfall. Waterfall doesn't mean that the spec is absolutely immutable. You will always find things to change in any effort of some complexity.
      - monocasa 9y ago
        Yes it does, that's why it's called waterfall. Water doesn't flow back up the waterfall.
        maxxxxx 9y ago
        Do you take other words that literally too? Maybe they should have named waterfall "oioioihopjl" to avoid conflicts with other definitions?
        monocasa 9y ago
        It's literally named waterfall in order to reference the idea that each step becomes immutable as it's being passed to the next step. This isn't some unfortunate consequence of an overstretched metaphor; it's literally the core concept. It's not my fault that it appears you've been using the term wrong. Waterfall with feedback ceases to be waterfall.
        zeveb 9y ago
        Waterfall was a strawman, used in a paper as an ideally-bad project management strategy. The name was chosen on purpose to describe its fatal flaw. Our industry being rather foolish, people read the paper and thought, 'hey, this sounds like a good idea!'
- gaius 9y ago
  I mean... there's no correct application of waterfall. The whole waterfall process comes from a paper as an example of how not to run an engineering project That is a very strange thing to say considering that the method comes from "real" branches of engineering (mech, civil, electrical, etc) and you can simply look around you at your built environment to know that it has delivered an awful lot of real, actual stuff. They didn't agile up the building you're sitting in or the roads that lead to it or power station that makes it work or any of the things in it.
  - gowld 9y ago
    > They didn't agile up the building you're sitting in Do you know where I'm sitting? https://en.wikipedia.org/wiki/How_Buildings_Learn https://en.wikipedia.org/wiki/How_Buildings_Learn
  - richliss 9y ago
    It's not a very strange thing to say at all - It's the truth. The Waterfall software method is a result of a misunderstanding by the DoD. Waterfall as far as software is concerned has its origins in a paper from Winston W. Royce and not an unguided adoption of mech/civil/electrical engineering principles: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...
  - monocasa 9y ago
    Have you worked in those fields? I worked as a commercial interiors contractor, then worked in embedded systems doing (among other things) board design and layout. These fields have plenty of iteration that has to occur. Pretty much no one ships a rev A board, chip, or bridge (the bridges get built out in solidworks).
clairity 9y ago
agile is a culture as much as it is a project management methodology, so it only works when the culture is compatible. one former employer purportedly did agile but it was a top-down autocracy, which is completely incompatible with agile. (i was ostensibly a product owner, but the CEO set our development priorities with only superficial consideration for customer feedback.) you cannot both dictate and empower at the same time, and empowerment (via agile) is typically the loser in that fight. that's how i see agile "failing" most often, before it even has a chance.
- squiggleblaz 9y ago
  The perfect development system will be immune to failure before it's had a chance. There is no perfect, but one that is fragile to external business realities is probably worse than one that is resilient to it. (In my company, the problem with agile was that the sales people would insist on always adding some extra tool for a fixed price. We had no choice but to abandon agile.)
  - clairity 9y ago
    i don’t know what such a resilient methodology might be, because we’re talking about human systems where the participants continuously adapt to emerging conditions. agile seeks to benefit from the intrinsic motivation of each team member to create something beyond any single member’s capabilities in exchange for empowerment. when a manager doesn’t understand this principle, that leads to failure (as in your case as well). i don’t know of any systems that can self-correct for this kind of external mis-judgement.
    - maxxxxx 9y ago
      That's the holy grail of management: To create systems that are immune to mismanagement. The Agile Manifesto tried to make clear that such systems don't exist but instead it got made into another system that's supposed to be immune from clueless people.
  - dragonwriter 9y ago

monocasa 9y ago

> This is the same extreme reaction people had previously to waterfall I mean... there's no correct application of waterfall. The whole waterfall process comes from a paper as an example of how not to run an engineering project.

maxxxxx 9y ago
I have seen projects where there was a very good specification upfront and the developers pretty much just had to work through it. This is not always possible and requires a very good understanding of the problem but it can work really well.
- jaggederest 9y ago
  It comes down essentially to that understanding. For well-understood problems waterfall might even be the best possible method. It's only for not well understood problems that it fails so completely. In software, in my opinion, fewer problems are well understood at the moment, and so we tend to avoid waterfall. However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems. The same is true for many other real life "waterfall" processes, like buildings, or bridges.
  - keithnz 9y ago
    actually buildings and bridges aren't really waterfall the way they are designed. They have similar issues with changing requirements, new insights etc as the project progresses. The actual construction is not really the equivalent of writing code in this world.
    - monocasa 9y ago
      And even during construction, you find new issues that you have to work around on any non trivial project. Source: was a commercial interiors contractor before I was a software engineer.
  - msla 9y ago
    > In software, in my opinion, fewer problems are well understood at the moment, and so we tend to avoid waterfall. Or if the problem is that well-understood, there's an off-the-shelf solution so good nobody seriously thinks about re-implementing it. > However, if someone wanted me to set up a webserver to serve static files that don't change? I'm 99% sure I could set up nginx on a virtual machine "fully waterfall" and have no problems. Exactly. That's barely software development. That's using fully-commoditized components in well-understood fashions to achieve a well-understood goal. You could script that. I'm sure some places have.
- monocasa 9y ago
  Just because you either lucked out, or didn't have the testing to find what actually broke, doesn't make waterfall a good model. The most well defined piece of software I know of, sel4, had a full machine checkable formal proof up front, and they still ran into issues during implementation that required them to go back and modify the spec.
  - maxxxxx 9y ago
    You have a very extreme definition of waterfall. Waterfall doesn't mean that the spec is absolutely immutable. You will always find things to change in any effort of some complexity.
    - monocasa 9y ago
      Yes it does, that's why it's called waterfall. Water doesn't flow back up the waterfall.
      - maxxxxx 9y ago
        Do you take other words that literally too? Maybe they should have named waterfall "oioioihopjl" to avoid conflicts with other definitions?
        monocasa 9y ago
        It's literally named waterfall in order to reference the idea that each step becomes immutable as it's being passed to the next step. This isn't some unfortunate consequence of an overstretched metaphor; it's literally the core concept. It's not my fault that it appears you've been using the term wrong. Waterfall with feedback ceases to be waterfall.
        zeveb 9y ago
        Waterfall was a strawman, used in a paper as an ideally-bad project management strategy. The name was chosen on purpose to describe its fatal flaw. Our industry being rather foolish, people read the paper and thought, 'hey, this sounds like a good idea!'
gaius 9y ago
I mean... there's no correct application of waterfall. The whole waterfall process comes from a paper as an example of how not to run an engineering project That is a very strange thing to say considering that the method comes from "real" branches of engineering (mech, civil, electrical, etc) and you can simply look around you at your built environment to know that it has delivered an awful lot of real, actual stuff. They didn't agile up the building you're sitting in or the roads that lead to it or power station that makes it work or any of the things in it.
- gowld 9y ago
  > They didn't agile up the building you're sitting in Do you know where I'm sitting? https://en.wikipedia.org/wiki/How_Buildings_Learn https://en.wikipedia.org/wiki/How_Buildings_Learn
- richliss 9y ago
  It's not a very strange thing to say at all - It's the truth. The Waterfall software method is a result of a misunderstanding by the DoD. Waterfall as far as software is concerned has its origins in a paper from Winston W. Royce and not an unguided adoption of mech/civil/electrical engineering principles: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/wate...
- monocasa 9y ago
  Have you worked in those fields? I worked as a commercial interiors contractor, then worked in embedded systems doing (among other things) board design and layout. These fields have plenty of iteration that has to occur. Pretty much no one ships a rev A board, chip, or bridge (the bridges get built out in solidworks).

clairity 9y ago

agile is a culture as much as it is a project management methodology, so it only works when the culture is compatible. one former employer purportedly did agile but it was a top-down autocracy, which is completely incompatible with agile. (i was ostensibly a product owner, but the CEO set our development priorities with only superficial consideration for customer feedback.) you cannot both dictate and empower at the same time, and empowerment (via agile) is typically the loser in that fight. that's how i see agile "failing" most often, before it even has a chance.

squiggleblaz 9y ago
The perfect development system will be immune to failure before it's had a chance. There is no perfect, but one that is fragile to external business realities is probably worse than one that is resilient to it. (In my company, the problem with agile was that the sales people would insist on always adding some extra tool for a fixed price. We had no choice but to abandon agile.)
- clairity 9y ago
  i don’t know what such a resilient methodology might be, because we’re talking about human systems where the participants continuously adapt to emerging conditions. agile seeks to benefit from the intrinsic motivation of each team member to create something beyond any single member’s capabilities in exchange for empowerment. when a manager doesn’t understand this principle, that leads to failure (as in your case as well). i don’t know of any systems that can self-correct for this kind of external mis-judgement.
  - maxxxxx 9y ago
    That's the holy grail of management: To create systems that are immune to mismanagement. The Agile Manifesto tried to make clear that such systems don't exist but instead it got made into another system that's supposed to be immune from clueless people.
- dragonwriter 9y ago