Are deadlines [a]gile?...[D]eadlines are viewed to go hand in hand with [a]gile development.
Many answers here are likely to focus on the engineering aspects of the question. Instead, I will address this from a project management perspective.
A deadline implies a great deal of up-front planning which is not in line with agile principles. Instead, iterative development models rely on time-boxes, cadence, and release cycles that include just-in-time planning, but not the "big, up-front planning" that is generally associated with traditional project management deadlines.
It is still possible to do release planning with agile methodologies, but the plans are generally based on an estimate of the number of iterations required to meet a goal rather than management targets set by fiat. That isn't to say that shipping dates can't be set, or that goals can't be met, but the way that they are defined and met is quite different than in traditional project management methodologies.
Think Time-Boxes, Not Deadlines
However, every project I have ever been on has insisted on setting a deadline. Given that Agile attempts to focus on adaptive planning, flexibility and change; are deadlines Agile?
This is a common misunderstanding of the agile principles. Agile frameworks such as Scrum and Kanban are not focused on deadlines, but rather on time-boxing and a sustainable cadence of delivery.
In Scrum, for example, the Sprint is not a "deadline." It is a time-box which is filled with the amount of work the team estimates will fit within the time-box without overflowing it, and is then either "done" or "not done" when the time-box expires. Once gone, the time-box is gone forever; any work that is not done must be re-planned and re-estimated within a new, equally ephemeral time-box based on then-current (rather than historical) needs of the project.
The importance of the time-box is that it creates both a predictable cadence for stakeholders to review progress, and a sustainable pace for the team in which to deliver potentially-shippable increments of value. The work is incremental, and follows the cadence; the concept of a big, up-front deadline is therefore not in line with agile principles.
Release Planning Based on Time-Boxes
Perhaps the one area where people have the most difficulty mapping agile processes to traditional frameworks is in release planning. Release planning often involves either fixed-scope or fixed-date deliverables. In agile frameworks, release planning is usually done through an estimation process where scope is explicitly defined as a mutable variable, while release dates are estimated in iterations.
For example, a project may be committed to releasing v1.0 of a project at the end of 20 iterations; the scope of what is released may change over the life of the project (as scope, features, and priorities can change at the start of every Sprint), but the target dates for each release is fixed in the project plan. The team strives to deliver a potentially-shippable increment each Sprint, and the Definition of Done includes quality checks such as continuous integration to ensure that the project is in a releasable state at the end of each Sprint.
Occasionally, you will see agile projects where the scope is fixed, but because scope is the mutable variable in agile projects, the release date may change over time as the scope of each iteration adjusts, changes, or adapts to the evolving needs of the project. I certainly don't recommend the fixed-scope approach to agile teams, especially inexperienced teams, but there are times when it's the right approach.