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 in a pre-production environment, then blend it into all the other operating systems without causing a hiccup in the data center. They are also the people who get called on the carpet when hiccups do occur.
Agile advocates consider it essential for agile teams to release code for business stakeholder review early and often. Agile teams also want to update production systems in short and frequent cycles. But operations teams instinctively oppose frequent cycles because that model threatens stability. They'd like update cycles once or twice a year, or at most once per quarter. They have a wealth of all-nighters in the data center and other bitter experience that tells them system failures often follow software updates.
"Developers have no experience in operations--it's a huge problem," says developer Jez Humble, co-author with David Farley of Continuous Delivery (Addison-Wesley, 2010). Humble is also a consultant with ThoughtWorks Studios, an agile development consulting firm.
There are other tensions between development and operations. Software often is developed in one environment, then run in another. Developers tend to develop in the environment for which their tools are made, which oftens means Windows. Testing done in the development environment often misses bugs that show up in production. Agile tends to focus on testing to confirm that the desired business functionality has been produced but can overlook difficult-to-test attributes, such as scalability, reliability, and ability to sustain peak load performance--attributes prized in operations.
Thus agile development, which has been so successful at connecting the once isolated developer to his business user, has tended to alienate the operations team. Dev ops is trying to extend the gains made with meeting business users' needs to operations' needs.
Our report on a more agile approach to implementing business intelligence is free with registration.
This report includes examines BI as a classic waterfall project and how agile could work better, including:
- Why trying to perfect requirements, data model, and reports along the way is impractical
- The five critical factors for applying agile techniques to BI