3 ms·

> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way. Not really. I’ve worked on waterfall projects and they gen

> Waterfall specifies fixed time and scope, with the inevitable result that quality has to give way. Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically

marginalia_nu 3y ago
I think often the supposed failings of waterfall is actually the failings of large scale software development, which crop up even with agile methods (especially with stuff like SAFe). My experience with small-scale waterfall is one of getting essentially a spreadsheet of requirements, implementing to spec, fixing a small number of bugs during QA, and then going into production on time and with exceptional quality. There's a project I did that went from zero lines of code to production in two months, that had literally bugs discovered in a decade of operation. Made entirely possible through waterfall-style development. If you know exactly what to build, development goes fast. There is not a chance in the world that would have happened if we'd been discovering new requirements along the way. That said, it also puts a lot more demand on well thought out requirements. The people who put together the specs were world class, smart, professional and solid engineers. Extremely particular where it mattered yet with very little bike shedding. My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.
- midoridensha 3y ago
  >My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts. I think that's why Agile was invented: for situations where requirements are not fixed. If you have fixed requirements, I don't see why you'd need Agile development in the first place, though some parts of it might be useful for just keeping everyone on track. In a recent job, we used Scrum and it generally worked well, but we didn't have the luxury of fixed requirements. The customer needed new features on a regular basis (features which they could not have foreseen the need for beforehand), and we'd regularly give them deliveries of the version of the product we had, which they'd immediately put into use. A waterfall model would never have worked there.
- EliRivers 3y ago
  I've had similar experiences with waterfall; projects running on time, over multiple years, on which the end users never reported so much as a single bug. As you say, it demands really good requirements, which can only come from high-quality customers. Most customers are not high quality. They are low quality. They are bad. They don't know what they want and don't know how to express themselves. As you suggest, a really good requirements person can tease these details out of them, but in my experience a great many companies don't even realise how bad and incompetent a lot of their own customers are.
Gareth321 3y ago
> Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected delivery. The requirements documents become bloated wish lists. Prioritisation is impossible because no one will accept cutting even the really fluffy stuff. Waterfall requires dedicated project managers who spend their whole day arguing with everyone. I admit that the quality is often higher, but that should be expected when it takes three times longer to deliver. Scrum/Agile forces teams to focus on the core value proposition, and not all the nice-to-haves. You believe this is only an issue with incompetent management, but if so, I've never seen what you consider to be competent management. I think the better solution here is not to buy into any framework as though it's a religion. Waterfall dominated projects for decades, and it has lots of issues. Agile is dominating current ways of work, and it has lots of issues. We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture.
- jon-wood 3y ago
  > We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture. Now where have I heard that before? Ahh yes, at this little website: https://agilemanifesto.org/ https://agilemanifesto.org/ My pet hate is that Scrum has somehow been dubbed as Agile, when a rigid system of meetings and planning techniques is the antithesis of agile development, which was conceived of to push back on exactly that.
  - Gareth321 3y ago
    Great point. We should do a better job of delineating scrum from agile.
_heimdall 3y ago
I've only ever seen waterfall work with a large enough team and we'll understood problem space. That said, the two teams I was on where both of those existed it was much more productive that even the best run scrum teams I've been on.

marginalia_nu 3y ago

I think often the supposed failings of waterfall is actually the failings of large scale software development, which crop up even with agile methods (especially with stuff like SAFe). My experience with small-scale waterfall is one of getting essentially a spreadsheet of requirements, implementing to spec, fixing a small number of bugs during QA, and then going into production on time and with exceptional quality. There's a project I did that went from zero lines of code to production in two months, that had literally bugs discovered in a decade of operation. Made entirely possible through waterfall-style development. If you know exactly what to build, development goes fast. There is not a chance in the world that would have happened if we'd been discovering new requirements along the way. That said, it also puts a lot more demand on well thought out requirements. The people who put together the specs were world class, smart, professional and solid engineers. Extremely particular where it mattered yet with very little bike shedding. My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts.

midoridensha 3y ago
>My experience is that developing against fixed requirements is fast and produces exceptionally high quality code. So many bugs and so much technical debt is from having to rewrite the same thing over and over because the requirements aren't set when development starts. I think that's why Agile was invented: for situations where requirements are not fixed. If you have fixed requirements, I don't see why you'd need Agile development in the first place, though some parts of it might be useful for just keeping everyone on track. In a recent job, we used Scrum and it generally worked well, but we didn't have the luxury of fixed requirements. The customer needed new features on a regular basis (features which they could not have foreseen the need for beforehand), and we'd regularly give them deliveries of the version of the product we had, which they'd immediately put into use. A waterfall model would never have worked there.
EliRivers 3y ago
I've had similar experiences with waterfall; projects running on time, over multiple years, on which the end users never reported so much as a single bug. As you say, it demands really good requirements, which can only come from high-quality customers. Most customers are not high quality. They are low quality. They are bad. They don't know what they want and don't know how to express themselves. As you suggest, a really good requirements person can tease these details out of them, but in my experience a great many companies don't even realise how bad and incompetent a lot of their own customers are.

Gareth321 3y ago

> Not really. I’ve worked on waterfall projects and they generally produced much much better quality than any scrum team I’ve been on ever. The dirty little secret is it’s faster too but if you have incompetent management/engineers the risk of not shipping anything at all goes up dramatically This is WILDLY different to my experiences. Waterfall projects always drag out months and even years past their expected delivery. The requirements documents become bloated wish lists. Prioritisation is impossible because no one will accept cutting even the really fluffy stuff. Waterfall requires dedicated project managers who spend their whole day arguing with everyone. I admit that the quality is often higher, but that should be expected when it takes three times longer to deliver. Scrum/Agile forces teams to focus on the core value proposition, and not all the nice-to-haves. You believe this is only an issue with incompetent management, but if so, I've never seen what you consider to be competent management. I think the better solution here is not to buy into any framework as though it's a religion. Waterfall dominated projects for decades, and it has lots of issues. Agile is dominating current ways of work, and it has lots of issues. We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture.

jon-wood 3y ago
> We should be using the right tool for the job, and even then, only the parts which make sense for our product and team and culture. Now where have I heard that before? Ahh yes, at this little website: https://agilemanifesto.org/ https://agilemanifesto.org/ My pet hate is that Scrum has somehow been dubbed as Agile, when a rigid system of meetings and planning techniques is the antithesis of agile development, which was conceived of to push back on exactly that.
- Gareth321 3y ago
  Great point. We should do a better job of delineating scrum from agile.

_heimdall 3y ago

I've only ever seen waterfall work with a large enough team and we'll understood problem space. That said, the two teams I was on where both of those existed it was much more productive that even the best run scrum teams I've been on.