The basic school of thought, I don't think I am mistaken in saying, is that agile principles of the sorts that have been adopted successfully in the software development community can also be applied, with some modification, to IT operations management.
Agile Operations basically stops there (and grows out of more diverse roots, besides). The focus is on identifying agile practices and principles that can be applied to operations, irrespective of where the software and hardware involved is coming from or how it is developed. I see Agile Operations as being IT-centric, largely ignoring the question of cooperating with development, and including approaches to deployment only as ancillary aspects of the overall challenge of running an agile IT department.
I think of DevOps as primarily addressing the concerns and difficulties of developers, and particularly of those in larger organizations with considerable custom internal software, who have become frustrated at the inability of operations to keep up with the faster pace and somewhat increased requirements for communication that their agile development practices demand. That's obviously the motivation offered by many proponents. More rare are those who disconnect the two and describe it only as the application of agile development principles to operations. There are certainly ops folks who are a part of the movement, but on the whole most of them seem to also have a foot in the development world; not surprisingly, many seem to be involved with website operations, an area that has always suffered from the friction between the dev and ops worlds. If a "webmaster," that poor, abandoned title describing a role that nonetheless has never really disappeared, is not an amalgamation of the developer and the administrator, then I don't know what is. DevOps is a natural evolution for anyone in such a position.
The DevOpsday website reinforces this perspective, inviting "developer(s) with a interest for system administration, or a sysadmin(s) interested in development..." to participate, leaving out sysadmins who really just want to run their own systems more efficiently.
Personally, I don't find any real issues with this overlap. Not all that DevOps can offer will apply to IT department operations in environments where interaction with developers is not a regular feature... and I think this is an increasing number of departments as SaaS and cloud-based, targeted services become more viable options for off-the-shelf procurement of software and services. At the meta-level of IT management, if you are going to be true to the principle of Simplicity, then your first choice for solutions is probably going to be fast, easily adopted off-the-shelf products of that sort rather than specifically (and often expensively!) custom developed software. In smaller IT shops, which is most of them, in-house development has never been a significant or reliable resource and outsourced development has often been untenable and interactions with outside developers not necessarily amenable to agile practices. None of that prevents any sysadmin or IT manager from taking from DevOps what works for them, and such an approach has much to recommend it since many of the more practical agile solutions for ops are coming from DevOps practitioners right now.
James Turnbull's recent treatise "What Devops means to me" is an excellent a representation of what DevOps is about and what issues it seeks to address as you will hope to find on the net.
(Aside: I find it interesting that the four quadrants Turnbull identifies as representing DevOps are roughly congruent to the four principles of Agile Operations; both include Simplicity and Process, and I find his Relationships roughly analogous to People, and Continuous Improvement to Communication)
DevOps seeks to address the epic and historic gulf between developers, many of whom have been moving toward agile methodologies for some time now, and operations staff, a more conservative bunch who are often caught out and feeling put upon by the rapid changes introduced by agile development. The realization that changing the development side of the equation without addressing the equally important deployment side (the realm of operations) was only changing where the roadblocks were at in between coders and customers led devs to gently lead ops in a similar direction. But as Turnbull says,
DevOps is also more than just software deployment – it’s a whole new way of thinking about cooperation and coordination between the people who make the software and the people who run it. Areas like automation, monitoring, capacity planning & performance, backup & recovery, security, networking and provisioning can all benefit from using a DevOps model to enhance the nature and quality of interactions between development and operations teams.
In other words, it started to become obvious that not only could the deployment of software benefit from a continuation of agile practices after the development cycle, but that ongoing operations could as well. This is where Agile Operations picks up on the thread.
In my mind, Agile Operations deals almost wholly with the people who run the software and not at all with those who make it. In environments where it is possible to cooperate and coordinate with developers, then of course doing so is an excellent idea. But many IT departments don't have, and never will have, that option; their developers are, for all practical purposes, Microsoft, and have you ever tried to cooperate and coordinate with Microsoft? Agile Operations recognizes that most IT departments have little say in the development side of the equation, and that the focus of their operations is not only independent of the development cycle, but in fact attempts to consciously isolate its effects on operations.
AO also looks at more than simply transferring Agile Development (AD) principles to operations; the principles are more deeply rooted and come as much from lean manufacturing concepts as AD concepts (although those are, in and of themselves, closely related). This level of focus is more relevant to the holistic management of the IT department, taking in procurement, support, and service in addition to the still important, but less central, issue of development integration and deployment.
I think both approaches are valid and valuable, and I'll certainly be following, commenting on, and participating in DevOps discussions, but I'll also continue to keep Agile Operations distinct from DevOps, and oriented primarily at the IT support and service management organizations.