I've done a number of projects in both "waterfall"[0] and Agile. On the "waterfall" projects, we wrote lots of documentation. LOTS. Business cases for every ma

I've done a number of projects in both "waterfall"[0] and Agile. On the "waterfall" projects, we wrote lots of documentation. LOTS. Business cases for every major feature. Requirements documents with serial numbered acceptance criteria. Design documents explaining exactly how we were going to implement the requirements, with every REQ bullet needing to be accounted for explicitly. Test plans showing how each DES bullet was implemented correctly and how it proved the REQ was satisfied. And it all had to be correct and fresh. We weren't allowed to have anything disagree or slip in or drop out. If it wasn't in the REQs, it didn't go into the software. That meant if we discovered constraints that necessitated a change in design, we had to change the requirements. If you had to change requirements, it meant you had to reevaluate the business case. And that meant we were prototyping while we were writing the documentation. The documentation wasn't done until the software was about 80% complete. By that time, we were mostly just working the test plans and resolving defect tickets to get to 100%. Some of the best, longest lasting software I've ever written. All of the "Agile" projects I've been on are what I call BTSOOP development: "By The Seat Of Our Pants". There was no attention paid to documentation at all. It was hell getting PMs to write any tickets, let alone ones that were in scope. And of the tickets that were there, most of the devs ignored them, even if the PM didn't. Some people would mark tickets done that they just didn't want to do, hoping the PM would just blanket-accept tickets at the end of the Sprint. Which he most frequently did. The difference wasn't actually process. It was accountability for failing to adhere to the designated process. The Agile shops all had corporate policy on how projects would be ran, and nobody was ever taken to task for it. The "waterfall" shops didn't lack continuous integration and improvement or responsiveness to change, we just wouldn't sign off on a particular document until we knew it represented the final product, with linear dependencies on when different levels of assets could be approved (not when they could be worked on). [0] our product manager called it "the NASA way", and we fairly closely followed their documentation standards, if not their engineering ones, but we were all pretty junior at the time. IDK why I was made senior other than being the best programmer there, which at the time wasn't saying much.