[VIDEO] Building an Agile Team: What Does DevOps Mean to You?
What does DevOps mean to you?
That was the question we proposed to Jillian Haffner, Director of Cloud Solutions & Integrations at Turbine/Warner Brothers Games, and Jennifer Davis, Software Engineer at Chef, when we sat down to get their expert insights on building an agile team.
As Jennifer explains, DevOps has been a “culture change” that has helped teams, from both large and small organizations, work more effectively together.
In the first video of our Building an Agile Team series, Jillian and Jennifer share their perspective on DevOps and how it has changed the way their teams function.
Watch the video or read the transcript below.
I was in the military for a number of years and one of the things we always said was, “work smarter; not harder.”
You don’t need to be a superhero. What you need to do is be smart enough to automate your job and progress through to make things repeatable and better. That’s really what DevOps has become.
We’ve finally bridged the gap of development dropping operations with complete trash and saying, “Deal with it. It’s your problem now.” And then not taking responsibility when there are bugs and errors, and people are getting up at 2am to recycle services, and all that happens.
There has always been this gap in the middle and I don’t know why it took so long to get here.
I have never understood it. When I first got into my career, I had a job offer to be a developer and I had a job offer to be a sysadmin and I had no idea that there was this holy war between the two. I was very disappointed to find that as a sysadmin, you’re not considered a developer, you’re considered an operator — I hate that operator word.
To me, DevOps is very much a culture change in how we talk about and communicate with each other. It’s all about empathy and understanding at the end, what we’re trying to achieve. Too often we’re too focused on a feature that we’re just trying to get out the door and then throw it over to QA, who then throws it over to development.
I prefer to think about it like, “Okay, we’re trying to provide this type of service, here’s how we’re going to get there.” That’s why I’m very much anti the DevOps name. It’s not just DevOps. It’s QE, it’s your product managers, your project managers, and all these other people who have important parts of the job.
I think small organizations got it. If you work in a small company, you wear so many different hats. Developers have direct access to production, and they aren’t always using automated tools.
I think the reason larger companies are starting to catch on to this is that they’ve seen the success of small companies, making a lot of money by allowing people to wear different hats and do things that are nontraditional.
Now in a big corporate environment, where you need to put line items on everything, DevOps became something that was easy to sell. They could say that they need these DevOps engineers and that there have been studies about DevOps, so now big corporations can buy into it. But big corporations do what big corporations do, so every single person needs a line item and a number.
This happens especially when you get into situations where you could have compliance issues. You have SOPS compliance; you have PCI, PII compliance issues where you can’t have people who have source code access actually have access to the environment to deploy things. This is something big corporation worry about, especially with all this Sarbains-Oxley compliance and credit card compliance.
I can speak for Warner Brothers in this case. We have a large credit card PCI compliance issue that gets reviewed every year by an auditor and we want to be beyond reproach with that. So where does DevOps fit in with that?
This is where you need to put a name on it and put structure and rules around it, which is exactly the opposite of how it came to be.
You have enlightened me. We had similar policies we needed to follow at Yahoo!
I feel like we are trying to put people into buckets when we should actually look at tools and policies. That way you can look at configuration and deployment — nobody touches production — so that you can have that policy-driven configuration management and deployment.
And then separately, if we think about people as engineers and all the skills they have and we don’t say “You do this and you do this,” then we will stop limiting the growth of the individual and company.
Now, I’m seeing how we bridge this understanding of this idea around culture and DevOps over to enterprise, and how we give them that bridge to not force your people into DevOps engineers, but get the right tools instead.
What does DevOps mean to you? We want to hear from you. Share your ideas in the comments below.