You could always go with a waterfall approach, but you're going to end up with a system that meets a lot of requirements, but doesn't deliver value.
7
2
22
It's stupid to follow the waterfall process. Period. Actually I'm not sure anyone ever really recommended it.
2
I can imagine it (or something like it) might make sense for, say, a nuclear power plant control system
3
1
The original Royce paper recommended several iterations. He worked in air & space, not unlike nuclear. The paper is from 1970. It was wrongly cited as the paper that described waterfall for the first time.
4
4
Sure. I just wanted to point out that agile development’s “learning from trying out things in production” might not be the best choice for every context :)

Oct 2, 2021 · 8:13 AM UTC

4
2
Replying to @stilkov @ewolff
You can try it out, also for nuclear power plants. At least once.
1
This is obviously stupid and unfortunately with Germany's ID Wallet some seem to be stupid enough not to realize that.
1
Yes. It seems a misunderstanding: Releasing stuff that doesn’t work properly is not the same as releasing something that doesn’t have all the features
1
Working in iterations is different from Agile. Royce does not say that you will uncover new requirements. It is about building a system with fixed requirements in iterations. Same with the SAGE system in 1956. Requirement is pretty clear: destroy all USSR bombers in an attack.
1
1
Thanks. I will use this with 'someone on the Internet told me.' :) No, really. Good point and article.
2
That is actually part of the problem: Agilist fight against a strict waterfall process that in fact nobody ever recommended.
1
While that’s 100% true, I still maintain that in some contexts it’s good to gather feedback about some feature’s value in production, and in some it’s not
1