Agile Methodology stormed into the world in the 00s and is today the dominant development methodology, according to all studies I've seen on the topic.
Agile does increase the agility of development organizations, however, it does so by increasing the frequency of releases. That's because Agile Methodology makes developers drive up the number of releases by promoting dramatically increased throughput of dev teams. The increase in releases that need to be deployed creates a Dev-Ops problem as higher frequency releases encounter operational limitations moving to production.
So, Development got "the Agile manifesto" while Operations got . . . a manifest application release problem. There was no "Agile for Ops." Hence the need for "DevOps" and the problem of "DevOps gap."
While DevOps looks new to some, the gap isn't new at all. DevOps as a term was coined by Patrick Debois in late 2009, and the term emerged as an organically growing trend in 2010 -- I'd call spontaneous meet-ups occurring around the world and a new Wikipedia entry as solid signs -- and now here as a mainstream industry topic in 2011.
I suspect newness can mislead some people. They might think because a term for something is new, it must refer to something new. It doesn't. The DevOps gap is probably as old as software development itself and goes back at least as far as Brooks' decades-old book, The Mythical Man-Month. Brooks likened the movement of developer code into operational deployment as "the transom effect" because application code was usually "tossed over the transom" from Dev to Ops. With Agile and Cloud, that transom grows into the Grand Canyon. Where it once was an aggravation, it is now acknowledged as a major source of real business pain.
It's generally stated in places like Wikipedia that bridging the DevOps gap requires cultural change (recognizing the larger business level issues caused by the gap in meeting customer expectations and timeliness), staff skill mix (building cross-functional skills in the IT and Dev teams, where Developers learn about infrastructure and Sysadmins learn their way around the code), and new tooling.
Management and cultural change take time and sensitivity, but tooling, designed for the job and done right, can have an immediate effect. The tooling for DevOps has to do a number of things to bridge that DevOps gap:
1. The tooling must provide improvement in speed and efficiency of application release and make things predictable.
2. It must transform team interactions, remove the "transom effect" of blindsides, abrupt work activities, and bottlenecks, and
3. it must connect with what is already in place and working.
So, in general, bridging the DevOps gap requires three things: planning, collaboration, and automation support.
For planning, it must provide a common window for release planning that is accessible to all interested or involved parties, preferably in a schedule and calendar form (with deliverable dates and schedules). This supports faster speeds and efficiency.
For collaboration, it must provide team-based release coordination around an application-centric framework so that teams and team members can see where and when steps are sequenced and who owns what. Ownership by role and responsibility needs to be clear, so that hand-offs are coordinated, approvals steps are known, and required activities allocated and measurable.
For automation support, it must provide a clear, concise abstraction layer over existing automation tools and the scripts that are already in operation (no rip and replace of anything already in place). It should also provide ways to measure existing tooling, so that metrics can be established for productivity improvements.