It seems that one of the early (and arguably immature) attractions of agile software development is that requirement gathering, discussion, decisioning & documenting was not necessary. All dev’s had to do was code, code, code! It probably didn’t help when every lame-brain idea was able to collect oodles of startup cash; it was imperative to code, code code!
As time went on and that next “great” thing became a legacy product, something inevitable occurred: team turn-over. With this, much of the institutional knowledge went out the door.
In these later years, the team has a mixture of old guard & late additions. The late additions find many perplexing practices, artifacts & technologies. The old guard has some recollection of the meaning, but not a precise or comprehensive understanding. A lot of time is spent re-discovering old decisions.
“But what about automated tests?”, you ask. Well, believe it or not, testers also leave teams. When the new testers arrive, they have no basis to form updated or new test plans, as requirements simply don’t exist. The consequence is that they too have many repeated questions, file incorrect bugs and basically have to start over.
Documentation has the same challenge; nothing to compare updates to. Again, they are in the “start-over” camp as everyone else.
Simply put (I think many understand this now), requirements are required for long-term success. A product cannot survive and thrive without the basics under control.