A major motivation of agile is the ability to respond to change in requirements occurring during the time between project initiation and 1.0 release.
This kind of change is, experience has shown, a major source of the "requirements problem" which was noted as far back as the 1970s.
Waterfall methods (except, perhaps, the small unit of work iterated waterfall approach that is sometimes seen as a way of being agile and often criticized by practitioners of, particularly, Scrum as not-agile) aren't equipped to deal with this kind of change.
But Agile isn't a set of methods, it's an approach to selecting methods. So, it's possible -- though perhaps unlikely -- that for certain teams in certain circumstances Waterfall is more Agile than, say, Scrum or XP.
This kind of change is, experience has shown, a major source of the "requirements problem" which was noted as far back as the 1970s.
Waterfall methods (except, perhaps, the small unit of work iterated waterfall approach that is sometimes seen as a way of being agile and often criticized by practitioners of, particularly, Scrum as not-agile) aren't equipped to deal with this kind of change.
But Agile isn't a set of methods, it's an approach to selecting methods. So, it's possible -- though perhaps unlikely -- that for certain teams in certain circumstances Waterfall is more Agile than, say, Scrum or XP.