4 ms·

Sounds like someone is working at a growing company. Agile is great when you can be agile. Not every busyness fits into that mold. Some software projects are b

Sounds like someone is working at a growing company. Agile is great when you can be agile. Not every busyness fits into that mold. Some software projects are big, regulated, public, etc. They need more structure. For instance, you don’t update the cloud provider at a 500 company with agile. It takes planning, coordination, contingency plans, and often 2-3+ year timeline. Agile is for smaller companies or smaller projects that can be broken up into sprint size pieces. Many are not.

yomkippur 4y ago
It's also produced needless stress and bullies that manage scrum. Maybe that's what you want in a business to get stuff done on time.
willsmith72 4y ago
"Agile is for smaller companies or smaller projects that can be broken up into sprint size pieces. Many are not." Just not true. I know it's hard to know if you haven't seen it but I assure you it's possible and much for effective for a large team to be truly agile
- ppeetteerr 4y ago
  Can you back that with some proof?
  - aliswe 4y ago
    i call cap too. agileis the way to go, but requires focus, lots of communication and a concrete foundation of trust. that does in fact not scale well, in that angle.
BoorishBears 4y ago
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.
deleted 4y ago
[deleted]

yomkippur 4y ago

It's also produced needless stress and bullies that manage scrum. Maybe that's what you want in a business to get stuff done on time.

willsmith72 4y ago

"Agile is for smaller companies or smaller projects that can be broken up into sprint size pieces. Many are not." Just not true. I know it's hard to know if you haven't seen it but I assure you it's possible and much for effective for a large team to be truly agile

ppeetteerr 4y ago
Can you back that with some proof?
- aliswe 4y ago
  i call cap too. agileis the way to go, but requires focus, lots of communication and a concrete foundation of trust. that does in fact not scale well, in that angle.

BoorishBears 4y ago

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.

deleted 4y ago

[deleted]