Implementing Agile Operations in your IT department

I've discussed (briefly) the concept of "Agile Operations" before, but I'm going to expand on it as a part of this series.

To recap, agile operations borrows from a number of the key concepts originated by the agile development movement. The core concept (mine, not theirs, which they argue over like Talmudic scholars... I'll admit to inspiration only so as not to provoke any baseless debates over what Agile is or is not) is that in complex systems, outcomes cannot always be accurately predicted and so service deployments should be made in incremental, but rapid, steps, with a focus on troubleshooting and resolution of the inevitable issues to the customer rather than a slavish but pointless devotion to their elimination in the planning phases.

I think there are strong arguments for this if you look at the rate of project failures in our industry. We very rarely get things right out of the gate, whether it's hardware-related, software-related, or systemic. The software guys realized this long ago, and that's where you get Agile from; the IT side of the house has been slower to catch on, which is why you still have so many costly mega-projects that fall by the wayside. I won't proclaim the victory of Agile Development in the software world just yet, but I will observe that its influences do seem to have lead to a smoother, more predictable process; I am sure exceptions exist, but off the top of my head I can't think of any seriously delayed or vaporware projects in recent history coming out of shops using Agile practices. My assertion is that we can do much the same thing that the software side of the business does: start simple, assume adjustments will have to be made, construct the minimum necessary structure in the most flexible manner possible to allow those adjustments to happen quickly and cheaply.

There are five guidelines I've identified so far for running your IT operations on and Agile basis (I'm still working on these; feedback is appreciated):

• To borrow a phrase, let architecture emerge. Establish guidance and sketch out plans, but do not attempt to set your infrastructure overmuch in stone before you need it. Instead, be prepared to implement small, simple, redundant blocks rapidly and according to demand.


• If they don't ask for it, don't do it. Base as much of your project inventory and operating processes as possible off of actual end-user demands. Listen to those requests and don't go out of your way to anticipate them.


• When they do request it, make them own it. Bring the requesting departments into your planning and deployment processes at every step. Business and IT are partners, and not the sort of partners where business decides it wants a soda and hey, IT, run down to the store and get that for me, would you? Business alignment requires participation on both sides and it must be ongoing


• Deliver rapid iterations, even if they are incomplete. You'll have to develop modular approaches to make this work, and it will force you to establish functionality and real business value at every step... no risk of building a monolithic system over 12 months only to find that no one wants to use it


• Standardize in small elements. Give yourself simple, stable, well-known building blocks which can be reused in multiple venues, even if they are not best of breed for a particular project. Flexibility is more important than performance

If some of this is sounding not completely outlandish to you, it's because of concepts like SOA, SaaS, business alignment, and the like... they've been permeating the collective IT intelligence of late, and many of the arguments used to support them help buttress this concept as well. Just in time allocation with SaaS, reusable and open services from SOAs... these are the tools with which Agile Operations are built.

The advantages to this approach are numerous. It places your priorities and those of your staff in the right place, every time; in the past, IT staff sometimes became so enamored of their plans and systems that they had difficulty letting them go or adapting them when ground conditions changed for the business (this is where much of the hollering over IT/business alignment problems in fact originated). It allows, when pursued properly, for a more efficient allocation of resources; you're not spending time and money on planning or preparation which might be useful, you're spending it on immediate issues which are immediately relevant. Further, the resources you do commit do not risk being orphaned or wasted (broadly; some small wastage is inevitable when your planning horizon is so short. The advantage is that you do not risk wasting very large expenditures) when demands change, and you are better able to meet changing demands efficiently. Results are offered quickly and obviously to other parts of the business, and done so with more, and more immediate, input from them... shared ownership of systems (and their resultant problems) is a wonderful thing for the embattled CIO. You'll also reduce pie-in-the-sky business proposals from departments which have not previously had to live with the consequences.

None of this is to suggest you abandon planning or traditional process development entirely. You still have to ensure security and stability, and not all of that can be done on-the-fly. Indeed, many of the complaints which have been prompted by Agile in the development world have been the result of an excessive abandonment of conventional wisdom. You still need disaster planning and backups, support processes and infrastructure planning. But you probably don't need them to the degree you have become accustomed to.

Why adopt this concept now, in the middle of a recession? It might--might!--help you trim your budget slightly, which is something that is certainly being called for. More importantly, however, it will allow you to more flexibly scale your budget to what is available, without suffering the corresponding breakdown in service which many of you surely dread. And it can give the rest of the business the impression that you are, in fact, doing more for them, simply by dint of improving your responsiveness.

Equally important, the recession gives you cover. You will probably have license, from both executives and staff, to make broad, sweeping changes in your operations. Indeed, you may even have a mandate to do so. By adopting this methodology, you can do it while marching to your own agenda. You don't have to be one of those CIOs who has been backed into a corner and forced to make unpalatable adjustments in fear and consternation. Make the plan your own; impress your CEO by being more aggressive than he is asking. And get what you want out of it at the end of the process, not just the ghostly shadow of a stripped department you no longer want.