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.
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.
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.
> 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.
The waterfall is process where you start by collecting requirements, make estimation and sign contract with set deadline. The rest is development in one go, then testing and then you give result to customer. So yes, it relies on precise estimations. Whatever else you have in mind is not waterfall process. Waterfall does not prescribe how exactly you make estimation nor how do you communicate inside the team.
It has disadvantages which is why no one was using it for decades. Except as straw process to blame when other processes fail or dont prevent dysfunctions. So, management tries to implement scrum, it fails or turns into hell. Then next guy will try to implement Scrum or whatever, claiming he is bringing agile to save us from waterfall. But that is just a way to avoid saying that it was scrum that failed and repeating exact same cycle.
There is a difference between a perfect estimate and what you're describing.
Again, literally no competent stakeholder anywhere is expecting a perfect estimate.
Both agile and waterfall both aim for precise estimates.
With agile you're still aiming to have roughly correct story points, or having roughly enough work for your sprint. But you're moving the yardstick on how often you estimate and how you handle missing those estimates.
All of which is why again, I don't see the point in being so rigid in where one ends and the other begins. Waterfall has gone from a punching bag to a real process people follow by adjustment. People seem to miss that while the "OG" waterfall diagram was supposed to be flawed, even in the same document practical improvements were introduced.
> Again, literally no competent stakeholder anywhere is expecting a perfect estimate.
Incompetent stakeholders are real world phenomenon. In this sense, even stakeholders that are otherwise smart people and competent in other areas often fails in exact this way. Real world companies pay fines for being late. Real world customers without contractual guarantees end up paying more then project is worth too.
> Waterfall has gone from a punching bag to a real process people follow by adjustment.
This is the thing I disagree with strongly. Waterfall is punching bag and is not used in practice at all. It was past being used when I was young. Waterfall was also far from the only process that existed before agile came.
Iterative development process existed long before agile came to be. Agile means nothing and everything these days. Waterfall however is canvas where people project their grievances with other processes. That is why it is undefinable in these threads - it is either about communication, or people being treated bad, or about iteration or host of other practices that companies combine together.
_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.