Agile operations

Sure, you've heard of Agile Development, but how about Agile Operations?

I just made that up, actually (the second one) but it seems a fair description of what ASU CTO Adrian Sannier is attempting with the university's new ERP system roll-out according to this Wall Street Journal article.

Reaction so far has been mixed. Chris Murphy at Information Week asks if Sannier is a prophet or a crackpot but I get the sense it's a rhetorical question (especially when he follows it by asking if Sannier would still have a job if he were at your company). Oracle thinks it's brilliant, but then, they had a hand in it. As for me, I have seen some merits in this approach for a while now. I think there is some advantage to making incremental but rapid deployments in some operations, devoting resources to rapid troubleshooting and resolution--a process which is nearly always successful--rather than to predictive failure modeling--a process which almost universally is not.

Sannier's own blog has an interesting series of posts on the implementation itself, and much of the logic behind it, but doesn't specifically address these issues.

Personally I think singling out the agile approach as the culprit here is a bit extreme--we hear these same sorts of anecdotal stories all the time about failed IT projects (for Krigsman's article on this particular project failure, see here--I would have expected that he, at least, have a little more sympathy in the matter), many or most of them managed with traditional tried and true (ha!) test-as-you-go waterfall methodologies. Why you would single out a different management approach as the primary cause of this failure is beyond me; at least the guy has the sack to try something different. As a commenter on Murphy's blog says:

System replacement is extremely difficult. All of the system replacement projects I have worked on that were successful were incremental to some degree. The primary problem being that you not only have to replace system functionality that was there on day zero of the replacement project, you have to also incorporate all of the changes that occur to the business and underlying system while the project is in progress. This means the faster you can deploy, the less additional scope you take on during the project.

Personally I think much of the ire that Sannier's approach has drawn stems from the un-apt comparison of his approach to Google's "perpetual beta" model of software roll-out, but I think there are important difference between a beta and an agilely deployed system. Or maybe not; I suppose it depends on your definition.

I think the real issue, if you want to take something broad and meaningful away from the whole controversy, is about summed up in this quote at the end of the Journal article:

"Everyone knows there'll be problems when you institute new computer systems," says Toni Genalo, who directs data collection for the psychology department. "We were prepared for that. Just not at this level."

If you really want to address these sorts of problems, think about why it is that "Everyone knows there'll be problems when you institute new computer systems." It seems that has become so accepted that we have stopped asking what it is about these projects that have traditionally made it so, and instead (and in doing so, to steal a quote from Krigsman, who stole it from someone else, "Rearranging the deck chairs") started nit-picking which approach to failure has been taken.