It’s in vogue right now to claim that there’s no such thing as a DevOps team or warn about certain kinds of teams that brand themselves DevOps but are not. Jez Humble’s doing it. Patrick Debois has made similar noises in the past.
I still haven’t met anyone who claimed that were a “DevOps team” that wasn’t doing something awesome for their company. Most are build and release engineers trying to help smooth the interaction for Dev and Ops. Others are evangelizing the ideas. Others come from a release management background. All of them come to the problem with a perspective of optimizing the whole. That is just great.
That hasn’t changed since I wrote this last July:
I see what I would call the “DevOps Infrastructure Teams” pretty regularly and they are hugely beneficial. These are groups sorting out problems like performing rapid releasable builds, how do we spin up new instances of our standard web servers in minutes rather than weeks, etc and providing canned solutions to both developers and operations. Ideally, developers and testers use a capability like quickly instantiating a server from the private cloud to generate test environments and the operations team uses the same capacity to borrow extra capacity for managing peak loads.
We also see these infrastructure teams serving as DevOps evangelists in the enterprise and serving as mentors as additional teams take on a DevOps approach in general and specific techniques such as Continuous Delivery.
I believe we’ll see more of these teams in the next few years and more existing teams that perform these roles take on the DevOps name. For better or worse, they may be to DevOps what Scrum was to Agile – an avenue to enterprise adoption that purists find a little unpalatable.
I agree with Curtis Yanko’s recent linked-in post as well:
I fully understand that DevOps is a philosophy and not a title but… in older organizations trying to shake waterfall there needs to be a cross functional team championing the cause and demonstrating the value of partnering for success.
Exactly. In small Agile/Lean shops, any sort of dedicated DevOps infrastructure group is probably an anti-pattern. In the bigger, more established companies that are just adopting Agile now, a group that provides DevOps help as a service is a great thing and one that’s unlikely to be very temporary.
I’ll add the caveat that it shouldn’t be its own silo, but instead bring teams together in some way. This really shouldn’t need to be said. I’ve never actually seen a “DevOps team” that was creating new silos. Maybe they exist. So far, I don’t think they exist in big enough numbers to worry about.
If you can describe what your DevOps team does in terms that serve as a caption to the picture above, you’re probably doing something right. Don’t let the DevOps elite give you the impression otherwise.
You are completely ignoring the end Humble’s post where he writes “OK so I lied when I said there’s no such thing as a devops team.”
Jen,
I’m not ignoring it. The presumption of the article is that the DevOps Team concept is, in the general case, flawed. He ends with an acknowledgement that there might be a non-harmful thing that takes the DevOps name, but that’s a corner case. This is similar to Patrick’s position in the presentation I linked to.
In the DevOps community, there is a presumption of guilt cast across DevOps teams. It is only after meeting certain criteria that you get a pass as maybe not totally evil.
I think that’s basically unfair. From what I’ve seen in the field, presuming innocence is better. If I was a process consultant, I’d love to work with someone who wanted to put in place a team to implement DevOps. With a little bit of bending we could probably help them create something great.
fair enough but the point is that if you start out to achieve “good enough” you are going to get considerably less than that. Even worse, you are basically telling people that it’s fine to stop at the devops team level because it’s better than what they’ve got now. They should be shooting for “the right thing” instead IMHO and know that just because they are seeing some results by having a devops team that’t not a good reason to stop there.
It’s just the beginning!
Really, my point was simply this: if “devops” is going to work, you need to get rid of functional silos and have developers to take responsibility for things like deployment and quality so that they can learn how to create systems that work when exposed to the real world.
You say I’m describing a situation that doesn’t really exist, but I know hardly any large organizations where the dev team is on the hook for deployment and quality. Instead, QA/testing and ops are usually on the hook, and I’ve seen that been the responsibility of a “devops group” too (although as you say, fortunately that’s not very common)
I am fine with a devops group that acts to coach and support the existing teams – and I say so in the last couple of paragraphs. I know these groups help improve things, and I agree it’s a step in the right direction. I wasn’t trying to argue against that.
But if you’re not going to get rid of the functional silos, that’s only ever going to be a band-aid. Enterprises need to realize that and actually fix it.
We totally agree on too much siloization. I’m just not seeing groups that call themselves a “DevOps team” adding a silo between Dev and Ops.
While I’m sold on the Dev team having ownership of quality, honestly, I’m less sold on Developers owning deployment – particularly script writing. Maybe that makes me a bad DevOps acolyte. One of the things that I think let Maven take off was that the build script was pretty much abstracted away. If you followed reasonable conventions – set by either the industry or your enterprise – you’d run a goal, the right stuff would happen and you’re done.
I talked to a enterprise delivery team last week who said, “one group of developers has good scripts for this, another good scripts for deploying that, and most are a train wreck.” I’d much rather find a way of abstracting the good scripts and providing them as a service to everyone, than try to teach all the developers how to script Jython updates to JDBC queues to WebSphere.
I don’t see any value delivered to the customer by having each team write its own deployment scripts. If a central group can consolidate that, and provide it as a service the product/project teams can exploit then the developers can focus on writing quality code that does deliver business value.
A group doing that doesn’t feel like a band-aid to me. It feels like a really good way to scale.
I’ve been seeing this “DevOps” team antipattern with many of our customers in the past few years. They call it a “DevOps” team and it’s really “Operations processes for Development teams” or it’s a new way to refer to the traditional “Build” or “Configuration Management” or “Release Engineering” teams, but with a hip new team name. While these “DevOps teams” have the best of intentions, what often happens is that they have different processes and tools than the team that releases the software to production leading to more confusion and longer cycle times. In any case, our objective is to identify this organizational antipattern and work with them to fix it.
Great insight Paul. I’d totally agree that’s an anti-pattern.
PS – Got my hands on your DevOps paper for GigaOM. Good stuff.
Creating a DevOps department is an easy temptation to keep things going as they used to be and at the same time, telling top management that you are doing DevOps now. I agree that you need a support/coach team of DevOps engineers to spread the seed, but I think that is right pointing that there is not sucha a thing as a “DevOps” dept when talking to the policy makers
I think the intent/advantage of not having a separate team for DevOps is to avoid additional overheads of communication between groups. As it exists today, a lot of problems with deployment, operationalization and quality of applications can be attributed to different groups (developers, operations, QAs) not understanding each others pains/needs very well. Creating a devops group does not increase the collaboration by default. I agree with Jez’s point of using the DevOps group to help improve the skill sets of developers around these things.
I have been working on an application for over an year and a half. In the first few months, we faced a lot of issues with deployment and with debugging issues in production. The releases were fewer and far between. Over time, we started interacting a lot more with the operations team. We started understanding the issues with deployments and started scripting it in a way which would make deployments simpler, easier and more predictable in the setup that we had. We also started publishing the information in a way which could then be extracted by the operations team (based on production usage) and improved the overall experience based on this. This is just an example. We release to production every week (for over an year now). I think we did 100s of improvements in the application which would have been harder without a collaboration with the operations team directly. Another DevOps group would probably not have been so effective in improving the collaboration.