3 ms·

You're just applying the concept at the wrong scale. Honestly I hate the term agile, it should really be "open communication", and it can apply on even a daily

You're just applying the concept at the wrong scale. Honestly I hate the term agile, it should really be "open communication", and it can apply on even a daily timeline Waterfall "style" is a directive comes from on high to get every service running on the new cloud provider, and 2 years later those on high find out we're still 2 years away from completion and along the way we spent months working on tiny aspects of it because the directive couldn't capture every nuance. Agile "style" is where you get to return feedback to "on high" before that point. If there's a service that represents 5% of our revenue but required 30% of the effort, you get a chance to push back and talk to stakeholders before committing that. - It's really the idea of "further unraveling uncertainty as you go along instead of assuming you accounted for all of it at the start" that makes agile useful, and that can work on any project of any scale. No matter how rigid the parameters of a project, at some level there's uncertainty (otherwise you'd have perfect estimates and nothing would ever be late). So better that "on high" learns more details about that uncertainty as you go along, and you get input on how to handle that uncertainty... than in a giant "we're flailing" moment later down the line. I think people focus too much on the whole "no committing to deadlines" idea, when that is not at all central to the value proposition, and honestly feels like a feel good platitude that doesn't actually work when it meets reality regardless of how small you are

ppeetteerr 4y ago
If you’ve worked in software for longer than a single project, you already know that software is impossible to precisely estimate and no two projects are alike. Anyone who claims that waterfall requires perfect estimates is using the term incorrectly. _All_ software projects include an element of discovery as new details are discovered, technical challenges are encountered, etc. To think otherwise is naive. Waterfall in software means there are fixed timelines and a fixed starting scope to work against. This helps align the efforts of multiple teams that have their own deliverables and timelines. As a project progresses, the timelines and scope are reassessed. This is true of any methodology. Full agility is when you can pivot quickly to new opportunities. This flexibility requires a small scale. Most larger companies have too much going on to allow for something like this yet they also allow for agility. For instance, a security incident is not going to be neglected because of an ongoing project. Waterfall in software is not what the author makes it out to be.
- BoorishBears 4y ago
  No one said anything about waterfall requiring perfect estimates? No one proposed or implied that any software doesn't have an element of discovery? Obviously there's wiggle room for all of these terms but you're defining waterfall so loosely that you didn't describe waterfall at all (nothing about fixed starting scope and fixed timelines requires waterfall...) Then on the flip side you're defining agile so precisely that almost no one can meet it. I mean what is "full agility"? It feels like you invented a term for a theoretical "perfect" implementation of agility, but my entire point is that you don't need to go off the deep end with the concept of agile to reap the benefits. - Waterfall and agile mentalities don't need to be mutually exclusive, which is exactly what the article is about. I lead projects on self-driving cars. When the NHTSA has hard requirements we don't get to go back and ask them to reconsider, but that doesn't mean that within implementing long-tail features we can't be have an agile process for making sure the teams implementing parts of those features aren't blindly banging away with no iteration on their approach. Waterfall and agile should just be means to an end. The weird want some people have for one to be the "valid" approach has never made sense to me.
  - ppeetteerr 4y ago
    Totally agree with your last paragraph
  - watwut 4y ago
    > No one said anything about waterfall requiring perfect estimates? That is literally how definition of waterfall starts. Unless you use waterfall as "the mythical thing I project all my grievances at".
    - BoorishBears 4y ago
      I figure it's implied "no one in this conversation", since outside of this conversation agile and waterfall have both been described in every possible way. Waterfall "as it should be" was presented as a flawed model: In reality there is no competent team, using waterfall or otherwise, that relies perfect estimates and I wouldn't insult anyone by claiming they're doing so.

ppeetteerr 4y ago

If you’ve worked in software for longer than a single project, you already know that software is impossible to precisely estimate and no two projects are alike. Anyone who claims that waterfall requires perfect estimates is using the term incorrectly. _All_ software projects include an element of discovery as new details are discovered, technical challenges are encountered, etc. To think otherwise is naive. Waterfall in software means there are fixed timelines and a fixed starting scope to work against. This helps align the efforts of multiple teams that have their own deliverables and timelines. As a project progresses, the timelines and scope are reassessed. This is true of any methodology. Full agility is when you can pivot quickly to new opportunities. This flexibility requires a small scale. Most larger companies have too much going on to allow for something like this yet they also allow for agility. For instance, a security incident is not going to be neglected because of an ongoing project. Waterfall in software is not what the author makes it out to be.

BoorishBears 4y ago
No one said anything about waterfall requiring perfect estimates? No one proposed or implied that any software doesn't have an element of discovery? Obviously there's wiggle room for all of these terms but you're defining waterfall so loosely that you didn't describe waterfall at all (nothing about fixed starting scope and fixed timelines requires waterfall...) Then on the flip side you're defining agile so precisely that almost no one can meet it. I mean what is "full agility"? It feels like you invented a term for a theoretical "perfect" implementation of agility, but my entire point is that you don't need to go off the deep end with the concept of agile to reap the benefits. - Waterfall and agile mentalities don't need to be mutually exclusive, which is exactly what the article is about. I lead projects on self-driving cars. When the NHTSA has hard requirements we don't get to go back and ask them to reconsider, but that doesn't mean that within implementing long-tail features we can't be have an agile process for making sure the teams implementing parts of those features aren't blindly banging away with no iteration on their approach. Waterfall and agile should just be means to an end. The weird want some people have for one to be the "valid" approach has never made sense to me.
- ppeetteerr 4y ago
  Totally agree with your last paragraph
- watwut 4y ago
  > No one said anything about waterfall requiring perfect estimates? That is literally how definition of waterfall starts. Unless you use waterfall as "the mythical thing I project all my grievances at".
  - BoorishBears 4y ago
    I figure it's implied "no one in this conversation", since outside of this conversation agile and waterfall have both been described in every possible way. Waterfall "as it should be" was presented as a flawed model: In reality there is no competent team, using waterfall or otherwise, that relies perfect estimates and I wouldn't insult anyone by claiming they're doing so.