Due to the vagaries of copyright and the terms of my employment, you'll have to read the full text of this article at my other blog. Please due, I spent ever so much time polishing it up for you.

For a taste, though, I'll quote myself selectively here under terms of fair use:

...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.

My contention in the article is that the IT side of the shop can use some of the core Agile principles to bring efficiency to our operations and increase business alignment and customer support in the bargain. There are five basic aspects to this:

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

I believe that IT departments small and large can take advantage, under the cover of pressures introduced by the recession, to implement this concept to their ultimate advantage, improving their relevance to the business and operating on a leaner basis at the same time.

But you'll have to check out the rest of the article to see the full argument.

Up next: revamping your support model in hard times.