4 ms·

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they

by Flankk 5y ago

Waterfall was never that bad anyway. Agile doesn't magically make people more productive. It only solves the problem of overrunning deadlines by pretending they're not important. If anything it puts needless pressure on devs who ideally should be free to think of solutions at depth. Sprints only make sense in that a team should be hustling in the early days. As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity.

moritonal 5y ago
Agile (if the culture incentivises honestly) does have the benefit of feedback. Rather than a black-box which "could" be done in a month, you can instead see that the team on-average under-estimates by 10 days, has x stories left, so it'll likely be done in 2-3 months at this rate. The downsides are that it opens up the team to feature-creep, introduced a pile of weird buzzwords, and can be massively wasteful if the team doesn't want it and it's forced on them.
- lelanthran 5y ago
  > Agile (if the culture incentivises honestly) does have the benefit of feedback. Doesn't Waterfall incorporate feedback? In my memory and experience, it does. My memory of learning Waterfall back in the early 90s is a bit hazy, but I distinctly remember that one of the advantages touted was that mistakes earlier in the process of developing software are cheaper to fix than mistakes later in the process (no matter what the process is). Finding an error when drawing up the requirements is orders of magnitudes cheaper to fix than finding an error after piloting at the client. As I remember it, Waterfall was taught (to me) as a way to avoid developing the wrong product, or a product that does not meet the requirements of the end-user (sound familiar?) My SDLC textbooks from back then were filled with different ways to elicit requirements, because fixing broken requirements after the product was developed was (and probably still is) bloody expensive. In the same way, fixing bugs during a test phase is a lot cheaper than after a deployment phase (hence various types of testing were introduced by the textbook). Fixing bugs during a pilot phase is a lot cheaper than after a full deployment, hence piloting was in the textbook as well. Agile aims to deliver features one sprint at a time. Waterfall aims to deliver the specified system as a whole or not at all. Which one works better is probably contextual, but I cannot see either one being unconditionally better than the other.
  - DnDGrognard 5y ago
    Exactly each waterfall phase has its own iteration loop
  - db48x 5y ago
    Yes, though as originally documented the Waterfall process didn’t have much to say about iteration. It was simply left to the reader to realize that they would be releasing version 2.0 of their software a year or two later, and that they could incorporate feedback from the users of version 1.0. Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too.
    - lelanthran 5y ago
      > Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete. > Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too. To be sure, CI/CD pipelines make the fixing of bugs in the code cheap enough to simply deploy when you can. However, bugs in the specification aren't going to be cheaply fixed after deployment, and these are much more common[1] and hard to get correct than any other type of bug. [1] I.e. the code does exactly what the programmer intended it to, but what the programmer intended it to do is different to what was needed.
mytailorisrich 5y ago
I don't think it's any issue of individual raw productivity. It's about not wasting that work by focussing on building exactly what the customer wants as fast as possible. With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. This means a longer lead time to working software and to any sort of feedback, and usually a waste of time in the docs/specs phase. Even trying to write a whole perfect spec before doing any coding prevents you from benefiting from the practical feedback that comes from actually doing. For some types of software this works mostly fine, but others not so much. Hence why most methodologies since then have feedback loops and try to make then small. IMHO sprints are not to pressure (though the name may not be well chosen in that respect) but to enforce small-ish iterations rather than spending 6 months developing something in isolation.
- lelanthran 5y ago
  > With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. (see my reply above, for some context and why I might be wrong :-). My recollection of Waterfall is that there is always an "acceptance" phase at the end of every "fall"[1] - IOW, there is a sign-off by the stakeholders that what's in the phase is correct. So your requirements are engraved in stone, your test protocol is engraved in stone, and your UAT is engraved in stone, and your "pilot performance acceptance" is engraved in stone. If it turns out there is an error in any one of the phases above then that error, and that error alone, is signed off on and goes through all the phases (or "falls"?) again. Since this is more expensive the further in the falls the error is, there is pressure to get as much sign-off as possible for any issue before that issue proceeds to the next phase. [1] I like the word "fall" to describe each phase of waterfall :-) I'm going to start using it more often and see if it catches on.
mr_toad 5y ago
> Waterfall was never that bad anyway. If you’ve never seen a project that wasted its entire time in the scoping and planning phase (and not produce anything), then you’ve never seen how bad waterfall can get.
- avian 5y ago
  Just to make a counter point, if you never spent your days in planning poker meetings, endlessly discussing hundreds of tiny scraps of yellow paper stuck to a white board (and never produce anything), you've never seen how bad Scrum can get.
drran 5y ago
Water is a good, predictable process. It's just result bad. If the result is not important, then use waterfall.
- jollybean 5y ago
  "Water is a good, predictable process" No, Waterfall is bad precisely because of the inherent unpredictability of a given project. Never in all of history was a large software project speced out and built on time. Software lives in a dynamic environment, so the process has to be mutable. Maybe the answer is not 'Agile', but it's definitely 'agility'. If we set longer term term, rounded goals, but with smaller iterations, then there's a possibility, but not a big Waterfall.
  - drran 5y ago
    SCRUM is just a bunch of small Waterfalls. In SCRUM, we have 2-week sprints. It's not important when one of the sprints will fail, because we will adjust following one. Moreover, we plan for first 2 sprints to fail anyway. Why we should use something else, more complex, instead of Waterfall, for a single sprint? Waterfall is good enough and predictable enough for a 2-week sprint. Yes, the result of a single waterfall will be bad, we plan for that, but accumulation of knowledge will lead us to success.
cube00 5y ago
> As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity. This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....". JIRA burn down charts dropped in our group chat to "remind us" to keep following the planned burn down line, looking for stories we can close out to try and sneak the chart to match the line and somehow try and catch up after they're closed. It's horrible.
- detaro 5y ago
  None of that is a requirement for agile processes. (Indeed I would argue that unless you have decided that's the best tool for your team, you're probably not being very agile. And no, when management of a big-co dictates how you work, they can call it "agile" as often as they want, it's not. Of course still extremely common, sadly)
- iamflimflam1 5y ago
  That is not agile it is SCRUM.
- littlecranky67 5y ago
  All you say is agile not implemented correctly (which is very common). I am a contractor and switch projects and development environments very often. I've seen agile working really well when it is properly implemented, and really poorly when it is wrongly implemented. The biggest problem I see that people never really get educated in agile. I see PMs/POs/Developers etc. that never had any formal training in agile/Scrumm (books, courses, experience) but rather learn-by-observation, i.e. "do what others do". And I have seen scrum master with zero expierience as a developer, just blindly trying to follow written guidelines in the books (scrum manual etc.) without being able to adopt those to a real development process. Take for example your metion of standups: They are really valuable, and are not meant to "justify" your last 24h - but some managers think that this is the case, i.e. make sure your developers are not slacking and surfing on hacker news all day. Instead, one of the purposes is to detect blockages in any way. I mean if a dev takes very long for a task without it being justified (i.e. no other developer would understand why it would take so long), it might just be due to lack of skill and the dev might need some more training or senior assistance. It could also be that the task is more difficult than originally anticipated, in which case the team should possible act on it and change the scope etc. Sometimes it could also be a very eager junior dev, who just doesn't want to admit struggling with something out of pride or even fear etc. As a developer I can totally say, it actually takes quite some guts to come out in a group of devs and freely admit: "Hey, I struggle with that task, I don't know what I am supposed to do, or am not familiar enough to debug that code, can somebody help me on this?" - but admitting that you are not perfect is something lot of people struggle, especially juniors as they think they must be capable of doing everything.
littlecranky67 5y ago
> Agile doesn't magically make people more productive AFAIK not only was that never a claim/scope of agile, but rather the opposite is deliberately accepted with agile: You accept quite some overhead during development, plan for constant refactors, shift of scope etc. The justification is, that while waterfall in theory is the most efficient and productive, in practice you very often end up with a product that doesn't fit your customers/users need. So working 2years on a product that is thrown away in the end and started over is less efficient and more expensive than working 3years on it in an agile way and getting (mostly) what you want in the end. Note that is the one of the reasonings of agile, I am not claiming that these statements and premises have actually proven true in the real world.

by Flankk 5y ago

moritonal 5y ago

Agile (if the culture incentivises honestly) does have the benefit of feedback. Rather than a black-box which "could" be done in a month, you can instead see that the team on-average under-estimates by 10 days, has x stories left, so it'll likely be done in 2-3 months at this rate. The downsides are that it opens up the team to feature-creep, introduced a pile of weird buzzwords, and can be massively wasteful if the team doesn't want it and it's forced on them.

lelanthran 5y ago
> Agile (if the culture incentivises honestly) does have the benefit of feedback. Doesn't Waterfall incorporate feedback? In my memory and experience, it does. My memory of learning Waterfall back in the early 90s is a bit hazy, but I distinctly remember that one of the advantages touted was that mistakes earlier in the process of developing software are cheaper to fix than mistakes later in the process (no matter what the process is). Finding an error when drawing up the requirements is orders of magnitudes cheaper to fix than finding an error after piloting at the client. As I remember it, Waterfall was taught (to me) as a way to avoid developing the wrong product, or a product that does not meet the requirements of the end-user (sound familiar?) My SDLC textbooks from back then were filled with different ways to elicit requirements, because fixing broken requirements after the product was developed was (and probably still is) bloody expensive. In the same way, fixing bugs during a test phase is a lot cheaper than after a deployment phase (hence various types of testing were introduced by the textbook). Fixing bugs during a pilot phase is a lot cheaper than after a full deployment, hence piloting was in the textbook as well. Agile aims to deliver features one sprint at a time. Waterfall aims to deliver the specified system as a whole or not at all. Which one works better is probably contextual, but I cannot see either one being unconditionally better than the other.
- DnDGrognard 5y ago
  Exactly each waterfall phase has its own iteration loop
- db48x 5y ago
  Yes, though as originally documented the Waterfall process didn’t have much to say about iteration. It was simply left to the reader to realize that they would be releasing version 2.0 of their software a year or two later, and that they could incorporate feedback from the users of version 1.0. Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too.
  - lelanthran 5y ago
    > Most of the data about costs is quite limited too. A lot of the numbers that people quote come from the 60s, specifically a project to develop software for a ground–to–air missile. Well that makes sense with my belief that WF aims to "deliver the system as a whole or not at all". There's no point in delivering an MVP G2A missile system that is not complete. > Certainly in that project fixing a bug after deployment would be very expensive, since it would probably require you to visit all the military bases where the missiles were deployed, disassemble them to some degree, and swap out a ROM chip. These days we can deploy a product with one command. If you find a bug tomorrow, you can fix it and run the command again. These days the only cost to fixing a bug after deployment is the revenue you lost due to the bug, and that might be minimal too. To be sure, CI/CD pipelines make the fixing of bugs in the code cheap enough to simply deploy when you can. However, bugs in the specification aren't going to be cheaply fixed after deployment, and these are much more common[1] and hard to get correct than any other type of bug. [1] I.e. the code does exactly what the programmer intended it to, but what the programmer intended it to do is different to what was needed.

mytailorisrich 5y ago

I don't think it's any issue of individual raw productivity. It's about not wasting that work by focussing on building exactly what the customer wants as fast as possible. With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. This means a longer lead time to working software and to any sort of feedback, and usually a waste of time in the docs/specs phase. Even trying to write a whole perfect spec before doing any coding prevents you from benefiting from the practical feedback that comes from actually doing. For some types of software this works mostly fine, but others not so much. Hence why most methodologies since then have feedback loops and try to make then small. IMHO sprints are not to pressure (though the name may not be well chosen in that respect) but to enforce small-ish iterations rather than spending 6 months developing something in isolation.

lelanthran 5y ago
> With pure waterfall you spend a lot of time writing and reviewing specs, then you spend a lot of time coding, then tests, then deliver. (see my reply above, for some context and why I might be wrong :-). My recollection of Waterfall is that there is always an "acceptance" phase at the end of every "fall"[1] - IOW, there is a sign-off by the stakeholders that what's in the phase is correct. So your requirements are engraved in stone, your test protocol is engraved in stone, and your UAT is engraved in stone, and your "pilot performance acceptance" is engraved in stone. If it turns out there is an error in any one of the phases above then that error, and that error alone, is signed off on and goes through all the phases (or "falls"?) again. Since this is more expensive the further in the falls the error is, there is pressure to get as much sign-off as possible for any issue before that issue proceeds to the next phase. [1] I like the word "fall" to describe each phase of waterfall :-) I'm going to start using it more often and see if it catches on.

mr_toad 5y ago

> Waterfall was never that bad anyway. If you’ve never seen a project that wasted its entire time in the scoping and planning phase (and not produce anything), then you’ve never seen how bad waterfall can get.

avian 5y ago
Just to make a counter point, if you never spent your days in planning poker meetings, endlessly discussing hundreds of tiny scraps of yellow paper stuck to a white board (and never produce anything), you've never seen how bad Scrum can get.

drran 5y ago

Water is a good, predictable process. It's just result bad. If the result is not important, then use waterfall.

jollybean 5y ago
"Water is a good, predictable process" No, Waterfall is bad precisely because of the inherent unpredictability of a given project. Never in all of history was a large software project speced out and built on time. Software lives in a dynamic environment, so the process has to be mutable. Maybe the answer is not 'Agile', but it's definitely 'agility'. If we set longer term term, rounded goals, but with smaller iterations, then there's a possibility, but not a big Waterfall.
- drran 5y ago
  SCRUM is just a bunch of small Waterfalls. In SCRUM, we have 2-week sprints. It's not important when one of the sprints will fail, because we will adjust following one. Moreover, we plan for first 2 sprints to fail anyway. Why we should use something else, more complex, instead of Waterfall, for a single sprint? Waterfall is good enough and predictable enough for a 2-week sprint. Yes, the result of a single waterfall will be bad, we plan for that, but accumulation of knowledge will lead us to success.

cube00 5y ago

> As the software matures, I don't think it's healthy to strive for squeezing your devs for every last drop of productivity. This is why I hate agile, it's incredibly stressful. Daily stand ups to justify your last 24 hours, affirmations in said stand ups which must begin with "Yesterday I committed to... and did/did not achieve this because..." followed by "By this time tomorrow I commit to delivering....". JIRA burn down charts dropped in our group chat to "remind us" to keep following the planned burn down line, looking for stories we can close out to try and sneak the chart to match the line and somehow try and catch up after they're closed. It's horrible.

detaro 5y ago
None of that is a requirement for agile processes. (Indeed I would argue that unless you have decided that's the best tool for your team, you're probably not being very agile. And no, when management of a big-co dictates how you work, they can call it "agile" as often as they want, it's not. Of course still extremely common, sadly)
iamflimflam1 5y ago
That is not agile it is SCRUM.
littlecranky67 5y ago
All you say is agile not implemented correctly (which is very common). I am a contractor and switch projects and development environments very often. I've seen agile working really well when it is properly implemented, and really poorly when it is wrongly implemented. The biggest problem I see that people never really get educated in agile. I see PMs/POs/Developers etc. that never had any formal training in agile/Scrumm (books, courses, experience) but rather learn-by-observation, i.e. "do what others do". And I have seen scrum master with zero expierience as a developer, just blindly trying to follow written guidelines in the books (scrum manual etc.) without being able to adopt those to a real development process. Take for example your metion of standups: They are really valuable, and are not meant to "justify" your last 24h - but some managers think that this is the case, i.e. make sure your developers are not slacking and surfing on hacker news all day. Instead, one of the purposes is to detect blockages in any way. I mean if a dev takes very long for a task without it being justified (i.e. no other developer would understand why it would take so long), it might just be due to lack of skill and the dev might need some more training or senior assistance. It could also be that the task is more difficult than originally anticipated, in which case the team should possible act on it and change the scope etc. Sometimes it could also be a very eager junior dev, who just doesn't want to admit struggling with something out of pride or even fear etc. As a developer I can totally say, it actually takes quite some guts to come out in a group of devs and freely admit: "Hey, I struggle with that task, I don't know what I am supposed to do, or am not familiar enough to debug that code, can somebody help me on this?" - but admitting that you are not perfect is something lot of people struggle, especially juniors as they think they must be capable of doing everything.

littlecranky67 5y ago

> Agile doesn't magically make people more productive AFAIK not only was that never a claim/scope of agile, but rather the opposite is deliberately accepted with agile: You accept quite some overhead during development, plan for constant refactors, shift of scope etc. The justification is, that while waterfall in theory is the most efficient and productive, in practice you very often end up with a product that doesn't fit your customers/users need. So working 2years on a product that is thrown away in the end and started over is less efficient and more expensive than working 3years on it in an agile way and getting (mostly) what you want in the end. Note that is the one of the reasonings of agile, I am not claiming that these statements and premises have actually proven true in the real world.