| Absolutely none of this matters to agile vs. waterfall. You can accomplish this with agile development: 1. People meet at the beginning of the project and say "heres what we think our washing machine needs" 2. They create a backlog based on those features 3. They start working and implement some features. 4. They find out they don't actually need the washing machine to wink and smile and say its done in a fancy british accent. It was a silly idea marketing came up with that adds no value. They drop that feature from the backlog. 5. They find out making the machine text you when your laundry is done is a desirable feature, they add it to the backlog. 6. Management says the competitor is launching a month earlier than us so we need to accelerate the time table. Engineering gives them the hard news that they need to sacrifice some features. They look at what they have left to do and prioritize the important items and drop the feature for the washer tie-dying your clothes if you want from the backlog. 6. Project enters qa, all tests are passing but testers found a bug. They write a test to confirm and reproduce the bug, they squash it and update the build. 7. Software is working, launch happens, everyone celebrates. Nothing here says the software has to change anymore; its done, its shipped, its good to go, and done using scrum/agile. |
The definition of "agile" is what actually happens in reality: You depend on an API from Google, and they, thanks to their so "agile" team, constantly drop or add features every few weeks, constantly move everything around, and then drop support for the API a few months later completely.
And they argue that it’s "necessary to have moving open standards for everything to be able to react to change".
That’s pretty "agile". Change! Change! Change! Who cares about consistency?