I just finished up listening to EMA's webinar
"Agile IT: A Better Approach to Application Development, Deployment, and Management" featuring Agile Manifesto co-author Ward Cunningham. Due to some technical glitches (apparently, not everyone uses a 64-bit web browser; who knew?) I was audio-only for the entire presentation and missed the slides, which I hope to receive via e-mail within a couple of days. Nonetheless the presentation was well-worth listening to, though Cunningham, the featured presenter, only figured into the last fifteen minutes or so.
Full report after the jump.
As I noted when I first signed up for the webinar, it seemed like a development-heavy perspective on Agile, and it was. Apart from a rather generic overview of the agile concept and its broad applicability (apparently, doctors, dentists, and construction workers have beaten all of us to the punch) by presenter Julie Craig, much of the information focused on software deployment and monitoring. Given that the webinar sponsor was Rails application management firm
New Relic, this wasn't a tremendous surprise. Deployment and application management are certainly areas in which IT operations can benefit from agile techniques, and they are often ripe for such process transformation as the concepts are already well-seeded through the development community. Although I am a fan of such adoption, I can't help but feel that this is a limiting prism through which to view agile IT operations. It's certainly of great concern to developers; they are unable to practice agile development to its full extent without a cooperative and flexible IT shop. I think it's something of a mistake to look at agile IT as if this piece is instead the whole of it, however. Most of the work of the IT department in most organizations is outside the realm of applications development and deployment. Constraining discussion of Agile IT as a concept to only that facet is bound to give both CIOs and other executives the wrong idea.
This is in no way the fault of the presenters of the webinar; instead, it's a lack of advocacy of the larger potential of agile operations on the part of those of us who are not tied so closely to development. Indeed, the developers are doing all that they can with everything in their power to influence IT in adopting more agile principles. The fault lies with those of us who have a more general perspective of the operations role, but who are not nearly as proactive in adopting agile to the larger parts of our mandate.
Sermonizing aside, there was much for Agile Operations advocates to take away from the presentation.
Julie Craig opened with a good overview of Agile and its history. She also did an excellent job of outlining how cloud computing isn't agile, but that it serves as a powerful enabler for agile approaches, allowing low-overhead, on-demand resourcing in almost infinite variety, making low-cost, quick-start, very scalable project support well within reach of IT departments of all shapes and sizes. "The cloud can't make you think outside the box," Craig said, but it can help you realize more easily whatever imagings you have outside it on your own.
Mike Malloy of New Relic followed Craig, talking mostly about the costs of infrastructure and legacy application support. Sixty to seventy percent of most IT budgets is dedicated to infrastructure maintenance, according to Malloy, leaving at best a third for the adoption of new technologies. This obviously has an even greater impact at a time when outside options are already becoming appealing to users. In a quick poll of attendees, Malloy identified the number one drag on agility in their organizations resulted from required maintenance of legacy applications and infrastructure. His advice for dealing with this? Aggressively calling out the units relying on those objects as to their necessity, and streamlining the functionality. Malloy identified process re-engineering as the most important part of senior IT management work, a point that is often lost in the defensive world of CIOs and IT managers.
Cunningham rounded out the discussion with a number of good points. Foremost among them might have been his answer to executives and staff who worry that moving to rapid, incremental release cycles introduces a large element of risk. "The biggest risk is doing too much," Cunningham said. By moving to rapid releases, customers are necessarily constrained in their requests, because only so much can be expected to be accomplished in a one or two week development cycle. Over time, Cunningham says, this trains the customers to ask for only the simplest things that they need, avoiding the bloat and feature creep that pollutes so many traditional waterfall model projects.
This perspective obviously comes from a certain sort of development history, and it's not an uncommon story. Still, it is not the whole story and someone with more of an operations background might counter it with a contrasting observation, that users who have frequently been disappointed with the outcome to their requests start not asking for too much, but for too little. Fortunately, the antidote is of a piece; rapid cycles can not only train users not to ask for too much, but also that mistakes will be quickly corrected and genuine value can be delivered in short time frames. Cunningham also commented that the natural human tendency of avoiding the things we fear most tends to diminish our expertise in accomplishing them. Pushing staff into rapid release cycles, where they are forced to confront their fears of releases breaking things, both build confidence and expertise. IT staff who have to release frequently learn not to fear releases, not just because of familiarity, but because the cycle forces them to refine their tools and become comfortable addressing issues.
If there is nothing else to take away from the webinar, it may be that final point Cunningham offers. Agile Operations is frightening to both staff and executives on several levels. But the fear and avoidance only forestalls the inevitable. Putting into place practices that call for meeting and dealing with these most painful issues will reduce those issues over time, and create a staff capable of dealing flexibly with them when they inevitably arise.