There's truth to that. But you also need to keep in mind that in the tech industry buzzwords are so often deeply abused. A major problem is that often technical management is not actually deeply technical, and they latch onto things that sound technical. In tech, this is wildly common and often results in disaster. I tend to agree more with @TenKHoursDev - instead of looking at the buzzwords, try to understand the underlying process and the goals. Then evaluate what's valuable and what isn't. Keep in mind that you don't have a lot of experience in software development, so a lot of your assumptions about how it normally works may be off center. For example, most of the time developers rage against changing specification. Waterfall was a method wherein the work essentially followed the spec for months at a time without evaluation. Agile processes were embraced largely because they allowed for smaller re-evaluations (weekly, as opposed to monthly). By organizing it like this, developers are more willing to adjust to changes in the specification and feedback can be integrated during the development process. A lot of the agile process should be understood with that goal in mind. Chances are, you don't have much experience with these sorts of issues, so the gains you would see here may not be what you would expect.