At a simple level, yes. Simply performing a Waterfall every two weeks does not make you agile, but it is iterative (which is half of agile).
The waterfall model defines phases - requirements, architecture, design, implementation, verification (testing), validation (acceptance testing), and release. In any iterative methodology, you go through each of these phases within every iteration. There might be overlap between them, but you elicit and capture requirements, adopt the architecture and design of the system to allow for implementation, develop the new features or fix the defects, test the new modules, and then present it to the customer for acceptance testing and deployment.
However, there's a lot more to agile than just being iterative and incremental. The tenants of agile are captured in the Manifesto for Agile Software Development. There are four key points made in the Manifesto:
Individuals and interactions over processes and tools
You involve individual people frequently. Many implementations are centered around self-organizing and self-directing teams. Nearly all have frequent interactions with the customer or someone who has voice of the customer. Rather than having a formal set of procedures to follow and tools to use, you let the people working on the project drive how the project gets done to let it get done in the best possible manner.
Working software over comprehensive documentation
In a software project, the primary goal is the delivery of software. However, in some projects, there is wasteful production of documents that add no value. Scott Ambler wrote a good article on Agile/Lean Documentation. It's not about not producing documentation, but about choosing documentation that adds value to your team, future developers, the customer, or the user. Rather than producing documentation that doesn't add value, your software engineers are instead producing software and associated tests.
Customer collaboration over contract negotiation
Rather than defining the terms and timetables and costs up front, it becomes a continuous effort with the customer. For example, you might capture your requirements in the form of user stories and assign them points. After a few iterations, you settle on a velocity (points/iteration) and can determine how many features your team can implement in an iteration. As your customer provides feedback on which features add the most value, they can decide when the project is done at any point. Any number of things can happen with frequent delivery and customer interaction - the requirements have been satisfied and the project concludes into maintenance and eventually end-of-life, the customer finds out that they don't need everything they thought so decides to end the project, the project is failing and the customer sees this early and can cancel it...the list goes on.
Responding to change over following a plan
You don't have a big design or ultimate plan up front and have to perform rework whenever that design or plan has to change. You continually estimate and revise estimates based on the information that you have. You choose your metrics carefully to provide insight into the health of the project and when to make internal changes. You frequently add, remove, and reprioritize requirements with the customer. Ultimately, you understand that change is the only constant.
Being agile means focusing on people and meeting their needs by delivering high-quality, value-adding software quickly. As the needs of the customer change, you adapt to those needs to focus on adding value. There are specific implementations of agile methodologies, but they are all centered on people, timely delivery of working software, and adapting to a rapidly changing environment.