Agile in Action

A good post by Chris Hoff at Rational Survivability about the "DevOps Disconnect," discussing some of the incongruities in the most popular characterizations of DevOps. As usual, the discussion in comments is among the most valuable parts of the post.

This echoes many of my own concerns and thoughts about DevOps, which have been raised elsewhere by Andi Mann, and Hoff's entry makes three, which reassures me that those of us with this perspective aren't simply those who proponents claim "don't get it" but instead have a valid point that real supporters might take time to listen to and incorporate rather than simply rejecting it out of hand.

That was fast! It seems like I still spend ninety percent of my time explaining to people what exactly Agile Operations is, but already the City College of Plymouth (UK) is offering a Certificate of Professional Development in Agile Operations for the subject.

I'm not up to speed with British higher education standards and lingo, but from the course description it sounds like this is primarily intended to be offered to organizations as a continuing ed course for their staff. It's not exactly AgileOps in the IT sense, either; it's more business-oriented. I'm increasingly coming around to the view that business-oriented is a more coherent way of looking at Agile Operations, however, with IT serving as a vital enabling factor, so maybe they are just ahead of the curve on me there.

The course covers Lean Business, Managing Activities, and Effective Communication (if it's not effective, is it actually communicating?) in a flexible course schedule. I'm not sure how long it's been available or who teaches it; I'd be interested in hearing from anyone on that side of the pond with any more information about it, or similar courses.

It's not news that users are frequently dis-satisfied with the delivery of IT services for their job functions. In any company, there always seem to be some people that just hate IT, know how they could do it better, and constantly try to subvert systems that are often there for good reasons they don't easily comprehend in their quest for perfection. Of course there are plenty of legitimate user complaints as well, people who are frustrated with things that certainly could be done otherwise, but aren't for reasons of cost or inertia.

But this historic background level of dissatisfaction may be masking a new wave of frustration with corporate IT, one that is both more soundly rooted and more easily addressed. CIOs who fail to deal with it are missing a dangerous warning sign about both users and the future of the IT industry. So it's worth looking at the impacts of new technologies on work and corporate IT not from the ivory tower, as we are wont to do, but from the perspective of the users, as this Wall Street Journal article attempts to do.

IT consumerization is a factor that is on the radar screen for just about every CIO by now, but a standard and workable response to it has not yet been popularized. Reactions vary from grudging acceptance to outright hostility to studied indifference. Few and far between are organizations that embrace the trend as a component of their corporate strategy; yet that is the level to which companies must integrate this societal sea-change in order to profit from it. Continue reading "The User Perspective" »

Government IT gets a bad rap as being slow, outdated, and encumbered with an even more egregious project failure rate than the already horrific ~50% we face in the private sector. A parade of news stories highlighting these failures, or unveiling the antiquated machinery and processes that government workers are forced to make do with even when the systems are working, does nothing to improve the image. Innovative IT thinkers like new US CIO Vivek Kundra and GSA CIO Casey Coleman are getting some good press, but on the whole, the agencies they represent are still seen as mired in the past and resistant to change.

Turns out, though, those stodgy old bureaucrats may be more hip and cutting edge than their private sector counterparts. Agile Operations is gaining traction in federal IT shops with more strength and greater commitment than can be found anywhere in the private sector just yet.

It's entirely possible that all the lean years and antiquated systems are exactly what is causing this role reversal. Agile approaches in IT management are among the only effective answers for improving ROI and implementation time when you don't have buckets of money to throw at projects. With the private sector continuing to ratchet up expectations, public sector CIOs may have had little recourse but to adapt to more agile management techniques to make up the gap.

Though there have been, for the past couple years, and will continue to be financial pressures in private sector IT, the real motivation for private IT organizations probably will come from relevance and effectiveness. There are as many benefits to the agile philosophy for business as for government, but it's only slowly occurring to business and technology leaders what those are... and many, recognizing the possibilities, still don't have a clear understanding of the path leading to them.

It's a necessary rite of passage for new ideas in technology to pass through the Big Three analyst Gauntlet of Fire, and with respect to agile operations, Gartner seems to be faster on the uptake than Forrester or IDC. Novel approaches to provisioning and support don't seem to have phased them, and now at least one analyst has taken up the mantle of IT infrastructure and operations reform in the guise of agile operations. The question is, is that mantle the same one existing proponents are trying to hoist?

Cameron Haight posts on The Need for IT I&O "Reform" on his Gartner blog, peppering the call with provocative statements like:

At the end of the day, I believe that it is no longer tenable to simply layer an increasingly complex operations management tool, organization and process infrastructure on top of an already complex software and hardware foundation and to expect satisfying results.

And:

I like the agile construct though because it is focused first and foremost on people (i.e., individuals and interactions over processes and tools) who at the end of the day are the most valuable components within the IT service delivery system.

So far, AO seems to be holding up fairly well in the analyst's estimation, then.

What I find interesting in Haight's take is the emphasis on the aspects of agile that push decision making down to "the coal face" as another commentator put it. It strikes me that many of the contentious discussions that have occurred lately over the applicability of frameworks such as ITIL in the context of agile operations ultimately boil down to this central tension, a tension that I have largely ignored since it seems to me to comprise the essential "magic" in implementing agile operations. Articles can be written (and are) all day long about what tools you might use and what techniques have been beneficial, but ultimately someone in the organization has to be fundamentally good at deciding where people can freelance and where stricter controls are required. There is no real way to describe that process; it's different in every organization, as staff and the confluence of requirements are unique. This is, ultimately, what it's all about, and you're not going to get it all out of a book or analyst's report; experience and internal knowledge is where it has to come from.

Haight acknowledges as much, saying:

I’m not saying to do away with operations processes in a wholesale fashion, but rather be more selective in which ones will provide the highest value and focus on optimizing these (significantly fewer) disciplines.

But this acknowledgment hasn't prevented a strong reaction from Bernard Goldin in Network World, who points out that there are solid, time-tested reasons that controls of the sort implied by ITIL have evolved. Not all IT staff are capable of reacting appropriately in all situations absent some standardized framework; many of those that are cannot always be counted on to also do so in a manner capable of being followed or replicated by co-workers or successors.

At first blush, I might seem to favor Haight; I have always advocated a pick-and-choose approach to ITIL, only adopting such tenets as make sense in the adopting environment. There are times and places for heavy process, just as there are places where process only serves to waste resources. But, interestingly, I find that I side more with Goldin when it comes to internal IT operations.

Higher costs come from non-standardized operations. Toyota, grandfather of the lean principles fueling our discussions of agile in the IT world, preaches flexibility on the assembly line but certainly doesn't encourage every worker to pick a different size bolt for the engine mounts. Standardization at some level is a perfectly acceptable part of agile approaches. The idea that "agile" has to mean "individualized" and "anti-methodology" is just plain wrong. The Agile Manifesto says that tools and processes are less important than individuals and interactions; it doesn't say that they are unimportant, as some of the commenters in the ITIL/DevOps thread (a minority view, however) seem to want it to say.

This may be a position influenced strongly by my own experience working with IT operations in small organizations where far too much freelancing has left service delivery in a precarious place. Most of my own conceptions of pushing decision authority down the hill have actually revolved around pushing it outside the IT department entirely. After all, when you are talking about the coal face where work is actually happening to meet customer needs and drive sales, in most companies, that's still happening far from the IT department. I see more damage being done by IT staff, at all levels, who are making decisions that might be better resolved (in cooperation, of course) with actual business staff.

So is this debate simply about deck chairs on the Titanic? If so, will it sideline much of the good an agile approach can have in connecting the business with the right technology? Are we missing the real point of agile principles when we restrict our considerations to what is happening strictly inside the IT department? I rather think so. Of course, "DevOps" as both Goldin and Haight have primarily characterized it, lends itself to that interpretation... another reason to avoid using the term in conversation with business executives outside the IT department. But if our discussions stop at the IT doorstep, if we're trying to decide whether or not ITIL or any element of process makes sense simply based on the character of the IT department itself, we're simply repeating a rather banal and terrible error that has lead IT into the position it already occupies, vilified and facing drastic cuts in both resources and authority as technology spending moves outside the department and CIOs are increasingly marginalized in the executive suite. Did business/IT alignment get turned into a buzzword so quickly that everyone forgot why it came up in the first place? Anyone who is trying to implement agile operations in their IT department without involving the rest of the business in the discussion over how much or how little process is necessary is making a dramatic mistake.

In case you were interested, Andi Mann seems to have stumbled into the same general problem that I blundered through last month with respect to the applications of "DevOps" outside developers interacting with operations staff.

I don't have anything further to say on the subject beyond what I came up with in my summation post, so I will leave it at that and hope that Andi comes to similar conclusions about the utility of the philosophies behind DevOps, if not the terms or practices themselves.

Just a quick link to a recent ComputerWorld article on how Toyota, the birthplace of the lean manufacturing movement that has in turn fed into the agile development and agile operations movements, itself handles information technology. There has been relatively little published about how the company fits IT into the Toyota Way; the eponymous book on the process says of technology only that the company prefers to adopt and stick with proven and tested solutions, a reasonable enough stance from an operations perspective, but surprisingly tame from the constant improvement perspective.

From the article, it's possible to extrapolate the the organization itself has had difficulty adapting the Toyota Way to IT until recently; it sounds as if, at least in the plant described in the article, real progress on that front wasn't made until after 2007, despite the process having been adopted company-wide in 2001 (and practiced less formally for two decades or more prior to that). So, if you're having trouble working your own IT organizations toward an agile stance, don't feel too bad.

Of course, the timing of the adoption in particular of agile development methods just as the Prius was coming into its own and the subsequent accusations of faulty software in the braking systems may prove eventually to be a black mark associated with the concept. But the inappropriate application of a methodology isn't a curse on the methodology itself, if in fact it was even involved in the development of that particular software (I'm not sure I would choose an iterative development model for that application; if there were ever a case for hardcore waterfall development, life-safety code might be it), or if the software is even actually at fault in those accidents.

The article is extremely light on detail, so if anyone has run across on other resources documenting the Toyota Way as it's applied to the company's IT department, I'd love to hear about it. Just because Toyota came up with the idea doesn't make their adoption definitive, of course, but it's always helpful to see how the originator realizes a concept.

The degree of prejudice against using agile methods in large environments wasn't really obvious to me until last week, when a question about agile's suitability in a 50+ project environment exposed the bias, and in an unrelated post I ran across by Yvette Francino, Methodology Wars: Agile Versus Waterfall the author blithely re-stated what turned out to be a common assumption in that debate, namely, "Size of the project: I would think smaller projects cater more to agile, because the smaller the team, the easier to collaborate."

My own thoughts have always been that the development methodology was more or less independent of the size of the project or team; as I said in my reply to the question that cooked it all off, the decision to use an agile approach depends more on...

...the flexibility of customer requirements, the ability to deploy iterations frequently, and the fertility of the culture to adapt to that style.

As another commenter, Ernest Mueller, notes,

Agile can be uptaken by teams individually. From a release management point of view, they just need to hit the freeze date for the release, right?

It's an excellent point. Any large-scale effort is necessarily broken up into smaller components already, a simple artifact of the widely acknowledged inability of the average manager to actively and effectively control and coordinate the efforts of more than seven to eight direct reports (this number is being challenged recently; I happen to disagree with the premise of the arguments against it, but my point here is simply that there are going to already be manageable sub-divisions in any project). Looked at from that perspective, then there is really no such thing as a "large project" but only larger collections of "small" projects. And if that's the case, then there should be no real objection to agile methods regardless of the size of the overall group working on the product. As Mueller points out, it's not even necessary for all the sub-groups of that larger group to use the same methods as long as they can all meet the same milestones.

Another argument against that perspective is simply the fact that plenty of people are already using agile in "large" project environments, quite successfully (see my post linked above for examples).

And frankly, the idea that "the smaller the team, the easier to collaborate" strikingly reverses the justification for any methodology; shouldn't you be selecting something that helps you achieve the things that aren't already easy, the things you are having difficulty with? If collaboration is a strength of agile methods, and large teams have difficulty collaborating, then I would think it would be a better fit, not worse.

I think the misapprehension comes from the fact that agile as a movement grew out of smaller project teams, and that it builds on attributes that are already more strongly noticeable in small teams. It's also a result, no doubt, of the fact that some notable initial failures came from attempting to use it with more large-scale projects. But I think those both have to do with my third yardstick for whether or not it's an appropriate methodology, the fertility of the existing culture to adapting it. The fact is that waterfall is pretty well established as the default methodology in the development world, and that going over to agile represents change. Change, irrespective of what is being changed to, is a hard sell with a lot of people, and the larger the group of people you are dealing with, the more likely you are going to find a significant number that are resistant to it, and the harder it is to isolate those people and work through it. Nothing works well without staff buy-in.

I mention all this because I think that this perception that the overall size of the effort mitigates against agile methodologies is more likely to find traction in objections to implement them in IT departments than in development shops. For one thing, most IT operations teams are larger than the development teams in the same organizations. For another, many operations-types already see agile as something that only applies to small groups of rogue-like developers already.

None of this is to say that agile methods are applicable in every situation; as I pointed out above, I think there are at least three key things that need to line up to successfully use agile. At the same time, there are certainly also factors that necessarily must align for waterfall methods to apply. I think the success rate of IT projects in general (the overwhelmingly vast number of which are conducted as waterfall projects) would indicate that very few people are looking at those factors before selecting their methodology, or that they are in fact actively selecting a methodology at all.

Mike Pountney at System Soup has published a short list of books related to DevOps and/or Agile Operations. As is to be expected at this point, the list is development-heavy, but of the few resources available for IT managers and sysadmins interested in going agile, these represent most of what is out there.

Don't stop at the initial post, though; many more excellent suggestions are percolating up in the comments section, particularly from Patrick Debois, one of the leading lights in the Devops movement.

Andy Carey commented with a question on an older post here that highlighted a case study done by Dave Larsen on the adoption of an agile release management process at a client. Andy's question was if I had any cases where agile methodologies had been adopted on a large scale, and what techniques they used to overcome the challenges introduced by the adoption of methods perceived as being small-project oriented. I am re-posting both his question and my reply, but wanted to throw the floor open for anyone else who could comment or provide information on such projects. It's really more of a development-oriented question, as posed, although the operational requirements to match release cycles up to accelerated development cycles could prove interesting.

The Question:

My client is considering using Agile methodology to reduce Time-To-Market for a number of IT Programs.

The challenge is that 50+ projects are packaged into a single release and the release is deployed quarterly. Currently, a water fall methodology is used. I'm concern that switching all projects to an Agile methodology will actually deliver less to the customer because of the increased resources required on Agile projects and it will also create major development environment challenges with the large amount of projects running simultaneously.

Do you have any cases where Agile was done on a large scale like this and how these challenges were overcome?

And my reply:

There are some untested assumptions and unmentioned details in that scenario that make me unsure as to which examples I should point you toward. Packing 50 projects into a single release and deploying quarterly could be a business requirement, but it also sounds very much simply like an artifact of the historical use of a waterfall approach... and if that's the case, then as true as it may be today, it's largely irrelevant to the decision to adopt an agile approach or not. For me, what drives the decision to move to agile isn't the number of projects or the release cycles but the flexibility of customer requirements, the ability to deploy iterations frequently, and the fertility of the culture to adapt to that style.

The first two are factors of the business environment that you may or may not be able to alter; the last can always be changed, but requires a commitment to do so at several levels. If you have all three, then the scope of the scenario isn't really an obstacle. Agile teams break up into manageable units just like any other. It takes some organization and creativity to coordinate them, but no more than doing so for the same number of waterfall-using sub-teams.

Whether or not this will require more resources or create major challenges largely rests on those first three factors. If adopting agile methodologies does not, in fact, solve development challenges and reduce resources required, then your client ought to stay off the bandwagon; agile is a toolset, not a panacea. And even if it is appropriate, it's not something you will adopt in such an environment overnight.

That said, here are some articles you might look at for examples:

Robert Schaaf describes an agile development approach on a 2000+ development team and outlines some recommendations and pitfalls to avoid.
http://www.sstc-online.org/Proceedings/2007/pdfs/RJS1722.pdf

There are also reports from a 2003 Canadian conference that looked at scaling agile methods.
http://martinfowler.com/articles/canScaling.html

I've also heard recommended Jutta Eckstein's book
Agile Software Development in the Large: Diving Into the Deep
although I have not read it myself.

And when I was pulling up the link for that one, this came up:
Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
Scrum seems to be one of the methodologies that has fared better in larger organizations; I know large teams at Microsoft that use it.

The short response to your question is that it absolutely has been done on a large scale, but that the challenges you and your client will face haven't been adequately articulated yet, and until they are, you'll have trouble finding specific techniques with which to overcome them.

And Andy, if you happen to see this and feel comfortable providing more details on the project, I'm sure that would help people point out similar circumstances, or even warn you off if it sounds like introducing agile into the situation would be a genuinely bad idea.

As much kicking and screaming as software developers had to endure when they first hauled agile methodologies into that realm is sure to be necessary to bring them into the world of operations. Little has been heard so far because this is a concept so far off the radar that no real threat to the status quo exists yet. But you can see a preview on the erp4it blog in the post "Agile IT Service Management: Why it's an oxymoron."

Service management is basically a subset of IT operations, but arguably one of the most important subsets.

The author argues that services must be stable, whereas agile is unstable, and so the two are incompatible. He does, however, compare services to manufacturing and allow that lean may be applicable to services management... but if so, it's a distinction without a difference. Much of what we know as agile is in fact an adoption of what are now broadly recognized as best practice "lean" manufacturing techniques. It's reflective of an understanding that preparation often simply leads to inefficiencies, that change is inevitable, and that dealing with the unforeseen outcome of those changes is a more important focus of effort than attempting to foresee and prevent them. Saying that IT service management is analogous to manufacturing processes is an argument for agile rather than against it.

This is an argument that follows from the stance that the author takes of change as an enemy and that reliability follows from careful planning and an aversion to alterations. From a certain perspective, that's absolutely correct, of course; it's a bit like the old maxim that the safest, most stable machine in the network is one that has everything unplugged and been buried beneath a foot of concrete. IT is not a venue where change will ever be exiled, not even in services management (and those responsible for managing services whose primary focus is to prevent them from changing, will soon find themselves out of a job). Change is constant and rapid, and in an anecdote at the end of the article, the author seems to acknowledge as much. We all have similar stories about the cascade effect of massive and expensive problems arising from seemingly small changes. Chaos Theory may well have been invented with IT in mind.

But as much as those stories are cautionary tales, the moral is usually "You're not going to see it coming" rather than "If you don't do anything, you'll be all right." It's hard to reconcile the basic position that seems to acknowledge that change is inevitable and will inevitably create unexpected issues with the stance that a methodology explicitly designed to deal with unforeseen issues is inappropriate. If the alternative is more of the same careful, stair-stepping waterfall approaches that have led the industry to its stellar 50% success rate in IT projects, how is that supposed to improve? If the claim is that more rigorous adherence to those approaches is the answer, then what exactly is wrong with all the bumblers who have been trying to apply them for thirty years or more, and how is the next generation of IT management any smarter or more squared-away?

The good news is that this is exactly the sort of objection you are most likely to see when you are moving to implement Agile Operations in your own organization, and it's easily dealt with by pointing out exactly these contradictions. The position basically represents a misunderstanding over how agile methods might be applied to operations and a misconstrued version of how existing operations are managed in most organizations. If that's the worst objection you hear, you're in good shape.

Just a quick link here to an article in Information Management Online on the insurance industry response to 2009. Based on a report "Escaping the Annus Horribilis: Insurer Views on IT and Business Strategies Moving Forward" the article covers the discovery among insurance industry IT professionals and executives that in uncertain times, agility is a must.

The conditions described in the article, of legacy IT systems leading to drag on corporate responses to rapidly changing operating environments, are hardly unique and have provoked much of the discussion here and elsewhere over the implementation of agile approaches in IT operations. We know what doesn't work, obviously. What I am more interested in hearing are experiences where agile approaches have helped businesses adjust to the difficult economic conditions of the past year. I'm not aware of anyone apart from smaller businesses who have adopted these methods early enough to be of us, but if anyone out there is aware of any such stories, I would love to put them up here.

It's not a big secret that enterprise IT projects have a terrible failure rate, much of it ascribed to their traditional waterfall planning and management approach, and this is frequently mentioned and critiqued in commentary by agile proponents who feel, with some justification, that they have found a better way.

One of these sorts of articles was posted recently by Tim Bray, a Sun employee with experience in both enterprise and startup systems. Bray takes the conventional format of such critiques and turns it on its head, though, by calling out enterprise architects and programmers directly and contrasting their sad state of affairs with the apparent success of such low-cost, low-risk, web-based efforts as Twitter, Facebook, and Basecamp.

Bray's point is that the massive waste of enterprise systems is downright shameful, the more so when compared to these web-based efforts, and yet no one is out there hanging their heads in shame. How is it that in the face of such waste that no one is held accountable, and why aren't enterprises trying the alternatives that seem to be right there in front of their faces? Those alternatives, according to Bray, narrow down to utility computing, and agile development.

The thing about massive, wasteful IT projects is that they fuel the IT industry. The reactions Bray has seen on his blog in part reflects this; there are a lot of people out there who are invested in the status quo, who have convinced themselves that no better way is possible.

In fact, sometimes it doesn't really matter if this is the case or not. This sort of waste isn't necessarily entirely evil, and in systems dominated by humans, may simply be a cost of doing business. It doesn't make a system bad, after all, just inefficient. Consider the US military. It's a hugely wasteful entity, and yet it is the finest war-fighting entity on the planet today. The waste, many long-time soldiers will tell you, is just part of the process. That's how it works, even if it seems insane when considered objectively. Without it, things fall apart or don't happen at all.

So what is the difference between enterprise development and Web 2.0 startups that allows the latter to create massive, working systems without such waste? Bray puts it down to the widespread adoption of agile methodologies in small, web-oriented software development shops. He notes that this has become ubiquitous to the point of invisibility... as he says, "I don’t hear a lot of talk these days from anyone claiming to “do Extreme” or “be Agile”. But then, in Web-land for damn sure I never hear any talk about large fixed-in-advance specifications, or doing the UML first, or development cycles longer than a single-digit number of weeks."

Nonetheless, many, if not most, large development shops have adopted agile methodologies; and yet the failure rates, while somewhat improved, remain egregious.

Tim concludes with a simple test of the validity of his arguments by asking readers what might happen if they asked a large, conventional software services firm (or, for that matter, an in-house development group) what the costs would be for developing, say, Twitter, or Basecamp, and what degree of confidence they would have that the end result would be similarly successful. The reaction most people will have is reflexively, "It would never happen" and I share that reaction. As Tim says, "...that kind of thing simply cannot be built..." if undertaken in the conventional world of detailed specifications, fixed-price contracts, and years-long development cycles.

But he doesn't go far enough with that argument, because he doesn't really ask why the "new normal" of agile methodologies work and why the old systems don't. And this is because he has framed the argument in terms of the successes of agile and the failures of waterfall. On reflection, that's clearly an uneven way to evaluate the processes. But it holds the key to why agile works efficiently and waterfall does not. And that is, agile dramatically reduces the costs of failure.

I haven't seen any formal studies on the subject (let's hope there are some in the works) but just as my own anecdotal experience has always left me with the understanding that most waterfall-based projects sink, I have the sense that most agile projects probably "fail" when judged on the same basis. We have engineered it, though, so you can't really judge them on the same basis; agile projects don't reach as far, don't promise as much. But the needs those promises were made to fill didn't go away; we just stopped over-reaching.

If evaluated on whether or not the project achieves everything that the customer desires, I think agile projects probably fall short just as often and for just as long as most waterfall projects. The difference is that the ability to fall short, regroup, and start moving again in the right direction is inherent in the agile framework, and those failures are much smaller and cost must less than they do in a waterfall project.

This is alluded to in comments, particularly one from David Megginson

It would take a brave (and well-funded) CTO to really emulate the web application development environment: she'd have to authorize (say) 500 one- or two-person projects and wait for natural selection to pick the most viable ones, reassigning people to the winners as the losers drop out, until after a couple of years she has one or two decent, fully-developed apps left standing.

While Megginson casts the idea in a somewhat negative light, implying extra costs and a lack of directional control over the development effort, in fact such an approach could happen more rapidly and at less expense (those are, after all, related) than traditional waterfall approaches. The clue as to the real problem with enterprise development is in the last sentence: "...decent, fully-developed apps..." are what enterprise developers assume to be the goal, and what they have lead corporate executives to believe to be the goal as well.

In fact, nearly two-thirds of conventional enterprise products fail to meet that goal in the specified time frames. Since the enterprise hasn't collapsed and melted into obscurity with that abject level of accomplishment, it may be time to acknowledge that enterprise architects have been shooting for a bridge too far all this time. More limited objectives can still fulfill the actual business requirements. And agile can more cost-effectively achieve those limited objectives.

While this debate revolves around development, it's as true of operations, as Bray's references to utility computing reveal. The question of whether or not to develop and over-spec in-house is not exclusive to the development world. Many of the same debates over complexity and competitive differentiation can be applied to operations, except it's even more difficult to claim a business advantage when everyone is using the same hardware and protocols at that level. On the other hand, operations is often much better positioned to effect a truly competitive advantage for most companies, just by dint of its more direct hand in the customer experience; but that capability usually languishes behind the unfortunate firefighting loop that most IT departments are trapped in.

This state of affairs raises the question posed in the title of this post: are agile enterprises inevitable, or impossible? Is it too difficult to move against the inertia and entrenched interests that result in such repeated and expensive failures? Or will the increasingly competitive post-Recession environment weed out organizations that fail to adapt to more agile approaches?

I suspect the answer lies outside of the IT realm, surprisingly. Rather, it's a question of economics. If the "new normal" continues to mean shrinking budgets and increasingly competitive markets, then enterprises will have little choice but to find ways to become as efficient as the Web 2.0 efforts that Bray cites. If, on the other hand, we return to another bubble or even genuine prosperity, the incentives won't exist for that transition, and the status quo will continue to be adequate and unmoving.

I ran across a collection of stream-of-consciousness notes taken by Stefan Tilkov on Stu Charlton's San Francisco QCon presentation "From Agile Development to Agile Operations." Though unpolished, they provide a snapshot of what looks to have been an extremely insightful presentation; while it falls into the pattern lately of Agile Ops talk from the Agile Development perspective, I believe Charlton does a much better job of addressing the important differences between development and operations and assessing the potential of AD techniques applied to operations problems.

Charlton, chief software architect at Elastra, has certainly been in a position where accelerating the tempo of the operations side of the house to match that of the software development side must be critical for success. Not only do cloud services help enable Agile Operations, but they must also demand agile operations internally in order to keep up with the flexible nature of service delivery in that environment. Charlton's talking points certainly have the ring of the practical over the theoretical, a strong point over most "developer preaches to sysadmin" presentations.

In fact, he appears to take some pains to look at the differences between operations and development in the agile context, asking "What is the test environment in operations?" (planning and rehearsal), "Where is the source code in operations?", and observing "In operations, transitional states matter a lot more than in development." He even drills down into fundamental differences such as funding, with the differing contexts of operations versus capital budgets. The notes show a clear understanding of the different values and challenges between development and operations, and the adaptations of agile techniques to operations reflects those realities. Much of it comes down to configuration management, and while he has a cute line early on ("Mimicking the illusion of working software by building a lot of documents") it's clear that documentation plays a more important role to agile operations than agile development. Change management seems to be a key.

There's an intriguing concept offered in the notes regarding the accounting issues. "Time-driven activity-based costing; activity-based costing is an approach used to make consultants rich in the 80s, but in combination with time-driven seems useful."

I would take this one-step further and say that value-based costing is in fact better yet. As Charlton points out, these costing models are familiar to consultants and have been used to line pockets for a while, and that is part of the problem with them; they are subject to manipulation, whether you are dealing with internal or external agencies. Value based costing, on the other hand, forces everyone onto the same page initially and forces the organization as a whole to clarify the benefits it is receiving before it settles on what the appropriate expenses will be.

That's tangential, however, and I'm simply reading between the lines anyway. Kudos to Mr. Tilkov for posting the notes, which are useful reading even if some of it does have to be done between the lines.

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. Continue reading "Review, EMA Agile IT Webinar" »