5 ms·

As someone from the hardware world, I feel like very few of the agile evangelists have actually worked on a waterfall project. Everything they say about waterfa

As someone from the hardware world, I feel like very few of the agile evangelists have actually worked on a waterfall project. Everything they say about waterfall seems to come from hearing polemical takes on it. I have never been part of a waterfall project where the team didn't adapt partway through the project as requirements or understanding about the project shifted.

anon23anon 4y ago
I feel like when Agile first came out the local agile guru was basically an older programmer w/ a ton of years and wisdom under their belt who knew first hand why doing things a particular way was best. It's since becamse a 2 week course for anyone to enter the tech field. Feel the same way about the influx of cybersecurity experts. Those used to be really good devs who also knew a lot about security, now, don't even get me started.
- hgsgm 4y ago
  Agile was atarred5 by people doing small business consulting projects for clients, like "make me a website".
  - ElfinTrousers 4y ago
    It was started by people doing a giant business consulting project, for Chrysler. The Agile Manifesto came out of (some of? all of? I forget) the signatories' experiences working on the Chrysler Comprehensive Compensation System, using the Extreme Programming methodology. How well did that work out? From the Wikipedia article: "The one-year delivery target was nearly achieved..." "A few months after this first launch, the project's customer representative—a key role in the Extreme Programming methodology—quit due to burnout and stress, and couldn't be replaced." "The plan was to roll out the system to different payroll 'populations' in stages, but C3 never managed to make another release despite two more years' development." "Frank Gerhardt, a manager at the company, announced to the XP conference in 2000 that DaimlerChrysler had de facto banned XP after shutting down C3..."
    - lmm 4y ago
      I've seen it argued that it failed a lot more quickly and cheaply than most comparable projects at comparable companies.
      - ElfinTrousers 4y ago
        The key word there is still "failed".
    - MiyamotoAkira 4y ago
      Some writing from Martin Fowler about the project: https://www.martinfowler.com/bliki/C3.html https://www.martinfowler.com/bliki/C3.html
      - ElfinTrousers 4y ago
        Would that be the same Martin Fowler who largely made his reputation on the basis of Agile, and thus has a major incentive to make it look good?
Jtsummers 4y ago
If you incorporated feedback along the way, then you did not do Waterfall. Which is good, because Waterfall is insane and brainless. I've witnessed a 10-figure Waterfall mistake (I was brought in near the tail end, it was years late, over budget, and delivered the wrong thing). If they'd incorporated feedback along the way they wouldn't have fucked up so badly.
- oscillonoscope 4y ago
  This is what I mean by only listening to polemical takes on waterfall. Do you think that anyone advocating for waterfall would actually claim that you never incorporate feedback? That's why you have prototype phases
  - Jtsummers 4y ago
    Yes. I've witnessed it several times. Some people are truly moronic. But there's no point in arguing for Waterfall if you actually use your brain and don't do Waterfall. EDIT: You didn't do Waterfall, just to be clear. You used prototypes and feedback along the way which Waterfall explicitly excludes. So why do you insist you participated in Waterfall projects?
    - oscillonoscope 4y ago
      Because any neutral description of a waterfall process[1] would describe most projects I've been part of [1] https://en.wikipedia.org/wiki/Phase-gate_process https://en.wikipedia.org/wiki/Phase-gate_process
  - egorfine 4y ago
    > claim that you never incorporate feedback I'd say this is the case more often than not. In order to advocate for Waterfall instead of any Agile methodology during the last decade or so one has to be overwhelmingly blindfolded by the religion. And these kind of folk tend to be quite strict in their faith. As in: "we had enough time to discuss things and think it through and now it's time to stick to the decisions we made". And yes, I have witnesses just that quite a few times. I know a software company that strictly uses classic Waterfall even to this day. A minor feature that should typically iterate in production for like 3 or 4 times and be done takes them about a year to implement and still never deliver what the customer wanted. And I'm not exaggerating. (The company prints free money from another line of business).
EarthIsHome 4y ago
In my previous job, they began using scrum agile to develop hardware. I don't know if it ever worked because I left. But when I was there, it was more stressful than before agile scrum.
- oscillonoscope 4y ago
  I've been through a couple attempted transitions to agile for hardware. There are some agile elements that I think could work in hardware development but the people pushing the changes have always been too stubborn to recognize when SW agile methods just don't make sense for HW.
- ElfinTrousers 4y ago
  Please tell me they don't make anything life-critical.
  - deleted 4y ago
    [deleted]
spamizbad 4y ago
I cut my teeth at a waterfall shop on the software engineering side. In hindsight, what was really killing our productivity wasn't the process but a bunch of dumb politics in the org. I'm not sure Agile/Scrum could've saved them from that. With that said I totally get why designers hate Agile - it forces them to make design decisions they're not ready to make and once there's functional software in people's hands everyone groans when design suggests non-feature changes.
- kcplate 4y ago
  > wasn't the process but a bunch of dumb politics in the org. I'm not sure Agile/Scrum could've saved them from that. In my experience agile/scrum just adds to the politics within the org. It’s a bloody religion. Agile adds in agile zealots vs the infidels.
- hinkley 4y ago
  I don't know about anybody else but for me the private conversations about agile have shifted substantially over the last 20 years. Early on, and once in a great while since, the conversation is that Agile is just a flashlight, or a mirror. All of those dumb politic things get no pushback until the bitter end of the project when everyone is trying desperately to ship it before the board gets pissed off enough to start rolling heads. Then you get some death bed conversions that don't really change the fact that the real change was needed six months ago and now it's all going to be bailing wire and masking tape. The fast feedback loop makes the bullshit quite apparent early on. And if you're very careful, you can arrange for some of the features that never should have been agreed to in the first place to be at the end of the line, where you can say, "look, we can ship what we have now, which does most of what most people wanted it to do, or we can keep farting around with this for another three months". A big part of where this breaks down is that you have two groups, one of which hates to change and one of which has had to become more comfortable/resigned to it, and if you put them both in the same pressure cooker, group A is still going to evolve slower than group B, except now group B has concrete evidence about what a group of children group A is. Now both sides are looking in the mirror and neither of them like what they see. The problem with knowledge is that once you have it, it's hard to go back, even if you don't like what you know. So I'm not sure what the road out of this is, other than the ones that sort of already exist, like OSS, which creates little pockets of what should be sanity (but often are just a different flavor of crazy).
koonsolo 4y ago
Waterfall works great when you have a lot of confidence in the problem and solution. In fact waterfall is the better process in that case. But as things become more unpredictable, you need a process that can respond fast to changes.
jillesvangurp 4y ago
I've worked long enough to have seen it all. The mistake hardware people make when reasoning about software projects is that it is like hardware projects. It's why most hardware companies are pretty terrible at software. It just doesn't fit in their world. Most engineering disciplines spend a lot of time for creating designs and blue prints before proceeding with the implementation phase. The mistake is assuming that software requires that too. It requires a little bit of thinking for sure. But fundamentally, the ultimate blueprint for software is executable. Your blueprint isn't finished until it runs. The process of producing the working blueprint is the whole point of a software project. You produce an executable specification in some programming language. The process of translating that to a working system (aka. compiling) is automated and does not require any human input typically. So, you do that very often starting on day 0 of the project. Until you are satisfied with the results. And why stop there? Many software products continue after their first release. If you are building a nuclear plant (or any similarly large civil engineering project), producing the blueprints takes many years. In fact, nuclear plants are infamous for lengthy delays during that phase. Almost like a big software project. Unexpected things happen. Which then require changes to the blue prints. And until you have those, you're haggling with authorities and other stakeholders over permits, requirements, safety, and what not. It's fundamentally an iterative process that doesn't respect deadlines. Like software. Of course building the thing is also not without challenges but there's typically no room for a lot of improvisation during that phase. So, it's relatively easy and more predictable. You can't really plan a hardware projects until after you have the blueprints. Hardware is just like software in that sense. The difference is that with software you are done once you have those. Planning the deployment (or customer implementation as it is sometimes referred to) is relatively straightforward: take the thing, install it, and run it.
- oscillonoscope 4y ago
  I don't think I really agree with that characterization. To take PCB design as an example, you could just as easily say that once you have your blueprints (i.e. manufacturing files) then you're done. I see two big differences between SW/HW. The first is that software has a free and fast iteration loop whereas that same feedback loop would cost 2+ weeks and $10k on a PCB design. This makes it so that upfront design and analysis is more reasonable than try it and see. The second is that SW team structures appear to be much more coupled and interdependent. Multiple hardware designers can work for months on the same project without having to communicate much with anyone whereas this seems rare for SW teams. This causes the interdependencies between personnel to be highly predictable even if the work itself is not predictable.

anon23anon 4y ago

I feel like when Agile first came out the local agile guru was basically an older programmer w/ a ton of years and wisdom under their belt who knew first hand why doing things a particular way was best. It's since becamse a 2 week course for anyone to enter the tech field. Feel the same way about the influx of cybersecurity experts. Those used to be really good devs who also knew a lot about security, now, don't even get me started.

hgsgm 4y ago
Agile was atarred5 by people doing small business consulting projects for clients, like "make me a website".
- ElfinTrousers 4y ago
  It was started by people doing a giant business consulting project, for Chrysler. The Agile Manifesto came out of (some of? all of? I forget) the signatories' experiences working on the Chrysler Comprehensive Compensation System, using the Extreme Programming methodology. How well did that work out? From the Wikipedia article: "The one-year delivery target was nearly achieved..." "A few months after this first launch, the project's customer representative—a key role in the Extreme Programming methodology—quit due to burnout and stress, and couldn't be replaced." "The plan was to roll out the system to different payroll 'populations' in stages, but C3 never managed to make another release despite two more years' development." "Frank Gerhardt, a manager at the company, announced to the XP conference in 2000 that DaimlerChrysler had de facto banned XP after shutting down C3..."
  - lmm 4y ago
    I've seen it argued that it failed a lot more quickly and cheaply than most comparable projects at comparable companies.
    - ElfinTrousers 4y ago
      The key word there is still "failed".
  - MiyamotoAkira 4y ago
    Some writing from Martin Fowler about the project: https://www.martinfowler.com/bliki/C3.html https://www.martinfowler.com/bliki/C3.html
    - ElfinTrousers 4y ago
      Would that be the same Martin Fowler who largely made his reputation on the basis of Agile, and thus has a major incentive to make it look good?

Jtsummers 4y ago

If you incorporated feedback along the way, then you did not do Waterfall. Which is good, because Waterfall is insane and brainless. I've witnessed a 10-figure Waterfall mistake (I was brought in near the tail end, it was years late, over budget, and delivered the wrong thing). If they'd incorporated feedback along the way they wouldn't have fucked up so badly.

oscillonoscope 4y ago
This is what I mean by only listening to polemical takes on waterfall. Do you think that anyone advocating for waterfall would actually claim that you never incorporate feedback? That's why you have prototype phases
- Jtsummers 4y ago
  Yes. I've witnessed it several times. Some people are truly moronic. But there's no point in arguing for Waterfall if you actually use your brain and don't do Waterfall. EDIT: You didn't do Waterfall, just to be clear. You used prototypes and feedback along the way which Waterfall explicitly excludes. So why do you insist you participated in Waterfall projects?
  - oscillonoscope 4y ago
    Because any neutral description of a waterfall process[1] would describe most projects I've been part of [1] https://en.wikipedia.org/wiki/Phase-gate_process https://en.wikipedia.org/wiki/Phase-gate_process
- egorfine 4y ago
  > claim that you never incorporate feedback I'd say this is the case more often than not. In order to advocate for Waterfall instead of any Agile methodology during the last decade or so one has to be overwhelmingly blindfolded by the religion. And these kind of folk tend to be quite strict in their faith. As in: "we had enough time to discuss things and think it through and now it's time to stick to the decisions we made". And yes, I have witnesses just that quite a few times. I know a software company that strictly uses classic Waterfall even to this day. A minor feature that should typically iterate in production for like 3 or 4 times and be done takes them about a year to implement and still never deliver what the customer wanted. And I'm not exaggerating. (The company prints free money from another line of business).

EarthIsHome 4y ago

In my previous job, they began using scrum agile to develop hardware. I don't know if it ever worked because I left. But when I was there, it was more stressful than before agile scrum.

oscillonoscope 4y ago
I've been through a couple attempted transitions to agile for hardware. There are some agile elements that I think could work in hardware development but the people pushing the changes have always been too stubborn to recognize when SW agile methods just don't make sense for HW.
ElfinTrousers 4y ago
Please tell me they don't make anything life-critical.
- deleted 4y ago
  [deleted]

spamizbad 4y ago

I cut my teeth at a waterfall shop on the software engineering side. In hindsight, what was really killing our productivity wasn't the process but a bunch of dumb politics in the org. I'm not sure Agile/Scrum could've saved them from that. With that said I totally get why designers hate Agile - it forces them to make design decisions they're not ready to make and once there's functional software in people's hands everyone groans when design suggests non-feature changes.

kcplate 4y ago
> wasn't the process but a bunch of dumb politics in the org. I'm not sure Agile/Scrum could've saved them from that. In my experience agile/scrum just adds to the politics within the org. It’s a bloody religion. Agile adds in agile zealots vs the infidels.
hinkley 4y ago
I don't know about anybody else but for me the private conversations about agile have shifted substantially over the last 20 years. Early on, and once in a great while since, the conversation is that Agile is just a flashlight, or a mirror. All of those dumb politic things get no pushback until the bitter end of the project when everyone is trying desperately to ship it before the board gets pissed off enough to start rolling heads. Then you get some death bed conversions that don't really change the fact that the real change was needed six months ago and now it's all going to be bailing wire and masking tape. The fast feedback loop makes the bullshit quite apparent early on. And if you're very careful, you can arrange for some of the features that never should have been agreed to in the first place to be at the end of the line, where you can say, "look, we can ship what we have now, which does most of what most people wanted it to do, or we can keep farting around with this for another three months". A big part of where this breaks down is that you have two groups, one of which hates to change and one of which has had to become more comfortable/resigned to it, and if you put them both in the same pressure cooker, group A is still going to evolve slower than group B, except now group B has concrete evidence about what a group of children group A is. Now both sides are looking in the mirror and neither of them like what they see. The problem with knowledge is that once you have it, it's hard to go back, even if you don't like what you know. So I'm not sure what the road out of this is, other than the ones that sort of already exist, like OSS, which creates little pockets of what should be sanity (but often are just a different flavor of crazy).

koonsolo 4y ago

Waterfall works great when you have a lot of confidence in the problem and solution. In fact waterfall is the better process in that case. But as things become more unpredictable, you need a process that can respond fast to changes.

jillesvangurp 4y ago

I've worked long enough to have seen it all. The mistake hardware people make when reasoning about software projects is that it is like hardware projects. It's why most hardware companies are pretty terrible at software. It just doesn't fit in their world. Most engineering disciplines spend a lot of time for creating designs and blue prints before proceeding with the implementation phase. The mistake is assuming that software requires that too. It requires a little bit of thinking for sure. But fundamentally, the ultimate blueprint for software is executable. Your blueprint isn't finished until it runs. The process of producing the working blueprint is the whole point of a software project. You produce an executable specification in some programming language. The process of translating that to a working system (aka. compiling) is automated and does not require any human input typically. So, you do that very often starting on day 0 of the project. Until you are satisfied with the results. And why stop there? Many software products continue after their first release. If you are building a nuclear plant (or any similarly large civil engineering project), producing the blueprints takes many years. In fact, nuclear plants are infamous for lengthy delays during that phase. Almost like a big software project. Unexpected things happen. Which then require changes to the blue prints. And until you have those, you're haggling with authorities and other stakeholders over permits, requirements, safety, and what not. It's fundamentally an iterative process that doesn't respect deadlines. Like software. Of course building the thing is also not without challenges but there's typically no room for a lot of improvisation during that phase. So, it's relatively easy and more predictable. You can't really plan a hardware projects until after you have the blueprints. Hardware is just like software in that sense. The difference is that with software you are done once you have those. Planning the deployment (or customer implementation as it is sometimes referred to) is relatively straightforward: take the thing, install it, and run it.

oscillonoscope 4y ago
I don't think I really agree with that characterization. To take PCB design as an example, you could just as easily say that once you have your blueprints (i.e. manufacturing files) then you're done. I see two big differences between SW/HW. The first is that software has a free and fast iteration loop whereas that same feedback loop would cost 2+ weeks and $10k on a PCB design. This makes it so that upfront design and analysis is more reasonable than try it and see. The second is that SW team structures appear to be much more coupled and interdependent. Multiple hardware designers can work for months on the same project without having to communicate much with anyone whereas this seems rare for SW teams. This causes the interdependencies between personnel to be highly predictable even if the work itself is not predictable.