Agile Operations - Comments

Scott Wilson: A degree in Agile Operations

nospam@example.com (Scott Wilson) — Wed, 09 Jun 2010 08:31:19 -0700

You're quite correct, of course... there are substantial differences between services and products and the processes aren't necessarily cross-applicable.

I am thinking about the integration and application of IT on a broader level than just web service delivery, though. When you're talking about putting boxes on trucks, inventory management, or vendor/distributor relations, no one is going to think you're crazy for attempting to use technology to improve those processes... it's already done on a large scale. Similarly, I don't think that idea that the technology operations groups making that happen already could be more tightly integrated with the "operations" operations groups doing it physically is so outlandish.

And if you're just talking about the processes, it's worth noting that a lot of our "new and revolutionary" agile IT ideas are basically repurposed ideas from tried and proven lean manufacturing processes. I suspect you might find more resonance than you think, at least in any organization that has already bought into lean on the manufacturing side of the house.

Ernest Mueller: A degree in Agile Operations

nospam@example.com (Ernest Mueller) — Wed, 09 Jun 2010 07:32:52 -0700

Well, my point is more that service delivery and physical product delivery are extremely different processes, performed by different people, supported by different tools... Sure, Web delivery is "equivalent to" logistics in terms of it's the process that gets the product to the end user, but in general the people, procedures, toolsets, etc. for "normal" logistics people have zero to do with online service delivery. I mean, I could see it being interesting swapping kanban concepts or whatever, but the worlds are too different for any fruitful interfacing to take place, and IMO that's what you'll find across the industry. Remember, the kind of operations people we're talking about are arranging for boxes to get put on trucks and get shipped to other countries, handling inventory, dealing with distributors... Though Web folks have analagous processes, if we were to show up and say "Hey, why don't you use your warehouse inventory system to track the servers in our data center too!" they would rightfully give us one of those WTF looks.

(In our org, we actually moved a group of core people including myself from IT into R&D, so there's no competition aspect to it - traditional R&D engineers are working on a lot of the functionality and we're working on the Webbiness of it. There's no hostility, but when we bring an online service to, e.g. our manufacturing guys they say "Uh, that clearly has nothing to do with us, we wouldn't know the first place to start.")

Scott Wilson: A degree in Agile Operations

nospam@example.com (Scott Wilson) — Tue, 08 Jun 2010 14:37:36 -0700

Interesting... I look forward to your blog entry on the process (hint, hint)!

I think that's a somewhat atypical scenario, though, in that you are a business with software products and established processes surrounding the production of those products. That pipeline already "gets" development and release, in its own way; I imagine elbowing in on that would be difficult and probably detrimental.

In most other organizations, the IT shop generally wouldn't be in the same position of producing a marketable, externally available product in (theoretical) competition with the products generated by the existing operations units. You're putting together a service offering, which is necessarily going to differ from a product offering; other places, the IT shop would only have to be concerned with integrating with the operation teams producing the existing products or services.

I feel like I'm not saying it well, but it seems to me that's a different kettle of fish. I have a strong visual picture of a bunch of engineers reacting to a gang of cowboys from WebOps coming into their bar, it just doesn't play out for me the same way if I'm thinking about, say, homebuilders, or doctors, or factory workers. I can see the initial resistance of "what are these geeks doing in here?" but it's not the same as alpha-geek headbutting over process models.

Ernest Mueller: A degree in Agile Operations

nospam@example.com (Ernest Mueller) — Tue, 08 Jun 2010 11:58:08 -0700

Well, I can see your point, and actually we've been going through an interesting process here. We're working on our company's first online service type product, but there are very mature processes for handling "shipping" software and hardware. A lot of the places where we're plugging into the process are in these areas - sort of. But in our sense, "instead of" manufacturing, you have Web operations. There hasn't been a lot of synergy in interfacing, it's been more a one or the other.

So I agree they kinda fill the same niche (product delivery) but so far all those guys see what we do as "a totally different world." Maybe there's some interface there eventually, but it feels a long way off.

Scott Wilson: A degree in Agile Operations

nospam@example.com (Scott Wilson) — Tue, 08 Jun 2010 11:50:25 -0700

Hi Ernest,

I am sure you are right that they are aimed more at traditional operations management centers. On the other hand, I disagree with you about referring to what we do as "Operations," which is also why I think the course is somewhat relevant... I think IT operations should be much more closely aligned, and even integrated with, conventional mainstream business operations. Traditionally, IT has been lumped in with, of all things, finance, which has lead to a somewhat pervasive corporate perception that it's a cost center best managed by bean counters.

I think conflating IT operations with other corporate operations might help change that so that IT is viewed as more of an enabler than a drag. There have been a few studies done that seem to show that IT departments perform, and are perceived as performing, more effectively when they are reporting to the COO rather than the CFO.

When you think about the things that IT can most effectively help with in most corporations, I think you get the same list of things that this course probably covers... logistics, inventory, distribution.... In the same way that a lot of people are talking about DevOps helping merge IT operations with development, I think both groups (and IT as a whole) might do better when integrated more tightly with other operations divisions in the organization.

Ernest Mueller: A degree in Agile Operations

nospam@example.com (Ernest Mueller) — Tue, 08 Jun 2010 10:18:31 -0700

Hmm, I think this isn't really for technical operations folks... I think they mean "operations management" in the supply chain sense, aka logistics, inventory, distribution...

This is one of the issues with referring to our sector as Operations, it's an overloaded term and the other meanings can get confusingly close esp. in cases like this.

Scott Wilson: "Worms, Roxanne! Worms"

nospam@example.com (Scott Wilson) — Sat, 13 Mar 2010 08:23:57 -0700

I absolutely agree; I think it's entirely appropriate for the folks who are talking about DevOps to be talking about it. It increasingly seems to be a very small subset of how agile can be applied in operations organizations, though. I think your focus on separating the principles, practices, and tools is extremely helpful in distinguishing that, whether you thought it was "deep" or not.

Ernest Mueller: "Worms, Roxanne! Worms"

nospam@example.com (Ernest Mueller) — Fri, 12 Mar 2010 13:05:09 -0700

I didn't know I was being quite that deep!

Interesting, it's good to see you state your use case. I tend to agree; I don't know if I'd pitch management on "DevOps" - that is a term more to use with the ops and devs "on the ground" to illustrate a specific area between them. At the management level I think it's more "collaboration among all stakeholders in the system."

My last Web Ops team partnered directly and heavily with the business directly; is that a separate "BizOps" movement? No, probably not, just an extension of the agile concept that "all these guys should be collaborating."

It's not that the DevOps term shouldn't exist; I think a rallying cry for the extension of the exiting agile collaboration to include ops is very valuable. But it does seem like more of a tactical implementation level term.

Scott Wilson: DevOps and Agile Operations

nospam@example.com (Scott Wilson) — Fri, 12 Mar 2010 08:22:07 -0700

Perfect! That's just what I was waiting for; now I can just post a link without having to do anything difficult like thinking or writing about it!

Ernest Mueller: DevOps and Agile Operations

nospam@example.com (Ernest Mueller) — Fri, 12 Mar 2010 07:38:12 -0700

I wrote up my thoughts on this topic more at length and hopefully more coherently here: http://www.webadminblog.com/index.php/2010/03/11/defining-agile-operations-and-devops/

Ernest Mueller: DevOps and Agile Operations

nospam@example.com (Ernest Mueller) — Tue, 09 Mar 2010 08:30:29 -0700

woot

Though upon further reflection, I think there may be three distinct things people are actually lumping in. The "collaboration" part, the "automation" part, and the "process" part.

Collaboration - dev and ops working together (and if dev and business are working together as part of agile development, really this becomes a trifecta of bus/dev/ops).

Process - as in discussions about "kanban vs iterative development", using user stories and burn down charts and all that

Automation - all the tech stuff.

The wikipedia entry on agile development has sections on "agile methods" and "agile practices" - practices are things like test driven development that apply across methods, which are flavors of process (XP, Scrum, Lean). I would tend to argue our "automation" things like build automation/deployment/config management are practices, in this sense. And it's an open field to come up with combos of collaboration and process into different flavors of agile operations methods!

Scott Wilson: DevOps and Agile Operations

nospam@example.com (Scott Wilson) — Fri, 05 Mar 2010 17:31:19 -0700

Thank you, Ernest! That's an excellent rubric to use to break down these concepts. I will adopt the terms you propose in my future discussions.

Ernest Mueller: DevOps and Agile Operations

nospam@example.com (Ernest Mueller) — Fri, 05 Mar 2010 09:00:57 -0700

Well, I think some of the confusion is that agile software development has two different parts to it.

The first is the techniques of agile - mainly iterative development focused on interim working and tested deliverables.

The second is the collaboration of agile - where crossfunctional teams, including their business counterparts, all sit and work together.

Note that descriptions of agile development incorporate both!
http://en.wikipedia.org/wiki/Agile_software_development
http://agilemanifesto.org/

However in practice people often adopt the tools and techniques of agile and ignore the collaboration part (something that the agile manifesto specifically warns against!).

I'll be honest, that's a common failing at my company - a team starts developing in sprints, but their requirements are still tossed down on high from a business analyst they seldom see.

I think the percieved difference between the terms "agile operations" and "devops" are an intuitive attempt to explain the difference. I also feel that the usual connotation of "agile operation" is more about using an agile process/methodology and "devops" is more about dev/ops cooperation. (And there's an unfortunate side meaning of devops which is "doing ops via more development" that is kinda-but-not-exactly like agile operations).

On the one hand, I think that having different terms from the technique part and the collaboration part is useful, if only because in the real world the two don't always go together and it provides more precision as to meaning.

On the other hand, I think it's an antipattern to implement one without the other, and we need to stress both aspects as part of a comprehensive whole.

My proposal:
- "Agile Operations" as the umbrella term that incorporates both, for parallel meaning with agile development.
- "DevOps" meaning "dev and ops collaboration" for the collaborative aspect specifically
- Some new term like "Programmable Infrastructure" or "Infrastructure Automation" to mean the tool/process automation part specifically

Scott Wilson: DevOps and Agile Operations

nospam@example.com (Scott Wilson) — Wed, 24 Feb 2010 17:53:08 -0700

I agree completely that those principles can be more broadly applied; in fact, I specifically drew comparisons between those you listed and the principles that I tend to identify as key to Agile Operations. But although they can be applied more broadly, it didn't seem to me that you (or people discussing DevOps in general) specifically did so. And again, I find nothing wrong with that... if you can't apply a little focus to some particular practice of a principle, the principle is of little value. I'm just saying, so far, DevOps hasn't done much to apply those outside the Dev/Ops cooperation genre. And perhaps it shouldn't; I think it's a worthy area of focus in and of itself.

But just because you describe principles that apply to both, I don't think that means you have really covered them equally, or that it's simply a question of "branding." That's a bit like saying that, since those principles have already been well-articulated for years now by proponents of agile development, that DevOps can really just be called agile development and there is little distinction between the two; or that in turn, agile development's core principles had already been described by lean, so it can just be called lean manufacturing.

I think DevOps and agile operations, despite having similar philosophical underpinnings and sharing some close similarities in many respects, still represent different disciplines, and I think the distinction is worthwhile because, as I identified in the original post, most of what you find when you Google "DevOps" speaks specifically to developer/admin relations... and that embodies a class of issues that aren't going to strike a chord for the majority of admins out there. There is much that can be done with agile principles in the operations realm that has little or nothing to do with developer relations and ought not be lost within that scope.

Of course none of this is to say that your articulation of those principles aren't valuable generally, and in fact that's why I linked to your post in the first place; it's some of the clearest writing I have found on those principles, and on their realization in the DevOps movement.

James Turnbull: DevOps and Agile Operations

nospam@example.com (James Turnbull) — Wed, 24 Feb 2010 10:53:36 -0700

Oh and BTW - my comments aren't a critique of your post. More trying to articulate that "one name" != "another name" doesn't mean much to me. Whatever the branding we're all on the same page and have pretty similar objectives.