The agile approach to software development has been winning enterprise converts since a group of 17 programmers laid out the core principles in the Agile Manifesto in 2001. The incremental sprints to deliver working software and frequent interactions with business stakeholders that agile requires are widely cheered for keeping software projects focused on practical goals. But there's a growing movement to improve agile by making developers accountable for how well their software actually runs in full-blown production mode.

This improvement effort goes by many names: continuous integration, continuous delivery, deployment pipelining, or just plain "dev ops." It seeks to add the IT operations team as a more important stakeholder in the agile process. Instead of developers being congratulated solely for finishing code that meets the business users' requirements on time and on budget, they would also be held more responsible for how easily it deploys, how few bugs turn up in production, and how well it runs.

It's undoubtedly a tall order.

Continuous integration has long been a goal of deep thinkers who contemplate the software development process--partly because it's so seldom achieved. In a world where developers typically produce code then toss it over the wall to the operations team, dev ops proposes to bring the two teams together. However, in some ways, agile's great success has become a barrier to bringing development and ops together; the agile approach's need for frequent releases is at odds with operations' desire for stable IT systems.

By "operations" we mean the systems and database administrators and other IT infrastructure specialists who keep systems online and serving the business. They often have expertise in how particular applications run and when they're likely to get overloaded. They know how to configure a new application for deployment, stage it ...