People who talk about requirements "gathering" often fail to talk about requirements "changing" continuously. At my last job this was endemic, every VP and abov

People who talk about requirements "gathering" often fail to talk about requirements "changing" continuously. At my last job this was endemic, every VP and above wanted to be seen as contributing, so things changed on a daily basis in arbitrary ways, making development a minefield of eternal changes. Even waterfall would have been easier (where nothing is allowed to change), despite us doing "scrum" change was not tied to sprints but the hour hands of a clock. We still shipped things, but everything took forever and the end result was often a user unfriendly mess that cost way too much money and left everyone frazzled. Having requirements at the start of a project that rarely changed was a pipe dream. I also once worked at a place where a large project had a ship date before the requirements document ship date. Of course when it was done it did not match what was written down, and also wound up not matching the (internal) customers needs either, so it had to started over.