As an organization sold on the idea of DevOps what’s your first step in the journey?

Despite a constant deluge of well-reasoned guides for implementing DevOps the most prevalent step most companies have made is simply contributing to a proliferation of DevOps job titles.

Most likely it’s in no small part because asking the HR department to add “DevOps” to the latest sysadmin job posting title and “Chef” or “Puppet” to the requirements is easy. This is a woefully low bar to set for DevOps implementation. Compounding this further, afterwards when the CIO gets a survey asking about DevOps adoption, they gleefully indicate the company is well on their way and join many others as they artificially inflate industry statistics of a very worthwhile but nonetheless major undertaking for large companies.

Surveys can contribute to confused starts. Any survey that does not include questions on specific practices and draws its conclusions from simply asking if a company is doing a practice that has positive buzz in the industry is worthless. A welcome contrast is the Puppet Labs 2014 State of DevOps report which is quite a beneficial collection of supporting information covering various practices, recommendations and nuances of organizational structures.

Even actually making progress on an individual automation project, whether with newly titled DevOps members or from a grass roots effort in an existing engineering or operations team, does not fulfill a complete implementation strategy nor is it the best way to start. Automation is certainly vital to reliably and repeatably managing environments, but groups shouldn’t rush to tackle automation first only because it’s comfortable to start hacking away at a problem they think they can deal with on their own.

These isolated and well-intentioned practitioners may find that without buy in and solid trust and relationships across groups they may not be given access to automate and orchestrate certain key areas.

You can’t automate relationships!

There needs to be a holistic understanding of the value streams driving engineering work and how best to make improvements. Instead of diving headfirst into automation work on identifying common goals, shared pain, and potential wins across organizational groups. Starting either with collaboration between group members directly or through management level alignment can work provided the other quickly follows. Buy in is required from both engineering and management or progress will stutter.

Taking people through a story can bring support more readily than just listing bullet points. People need to feel emotionally engaged and connected to the pains of the culture and process prior to DevOps and how they can be realistically mitigated. For a large company audience, seeing a story from another large company with timeframes and phases that shepherd the transformation in bold, yet manageable steps can be helpful. The story of SAP Global IT is a candid and useful case study.

Once the stage is set then tackle automation together in a cross-functional group with shared measures of success leading your focus. Depending on the complexity of your process it may be beneficial to collaborate on a smaller application or time boxed simple proof of concept to vet new ideas and working relationships.

Despite the potential for rocky or inefficient starts, the transformative power of a meaningful DevOps implementation contributes to incredible innovation speed and satisfaction. What has worked to keep your organization keeping the long view in mind regarding DevOps?

Many companies are misappropriating the term DevOps to get attention, headcount, or perceived leverage in internal turf wars instead of building a cross-team continuous improvement engine. Is this a sign of the early peak of inflated expectations in the hype cycle?

Are we heading for a serious backlash? Is the tireless promotion of proper practices from prolific thought leaders enough to make failures clearly misguided implementations and not fundamental flaws in the movement?

I’m eager to hear your thoughts in the comments.

One of the vendor’s lead technologists mentioned that it was pretty involved and it sounded worthy of a good blog post. That mention had come up again when another piece of architecture was discussed.

On the surface this had seemed like a good thing that the company was working at the edge of this space, but as the day went on and the themes of simplification of architecture and focus were discussed, it had become apparent that they had spent entirely too much energy in a space that was still nascent in the industry building a complex data and analytics pipeline. Much of this effort would have been better spent on simplifying the ability for new data insights to be generated and productizing them instead.

While it may seem somewhat meta and ironic to discuss the merits of blog posts in a blog post, this seemed like a good experience to share.  Blogging about bleeding edge technical pursuits at your company can have other benefits such as building the strength of your brand in the technical community which can be a powerful recruiting boost.  Just don’t conflate useful research and POC’s that you learn from and blog about with what you actually put together for your production data architecture nor lose sight of the actual analysis goal.

Photo Credit: Link by Rob Davies

You’re better off taking real steps to change your habits first and after you’ve adjusted your routine for the better even if in a small but measurable and consistent way, then make your purchase for whatever will save you time or help you get to the next plateau. So start walking more, eating better, or doing small home projects first before making your bold proclamation purchase.

Here’s the kicker. This is not the end of a post just talking about your personal life…

Businesses fall into the same traps!

It can manifest by hiring some outside consultant or speaker or having a series of large offsite meetings intending to effect change but in the absence of management and cultural support for the initiative. The response within the events themselves can run the spectrum from excitement to disinterest, but often the same end result of no meaningful change occurs without proper pre and post event alignment and follow-up.

In the DevOps space we’re at the point on the hype curve where organizations with a shallow understanding want to jump on for touted benefits, but aren’t really interested in transformation. That’s not going to happen no matter what consultant you hire.

There’s a great clip from the consultant Andrew Clay Shafer on the Food Fight podcast “The Future of DevOps”.  The whole show is a fantastically blunt, but very real assessment and discussion of learning organizations, DevOps, and a host of worthwhile topics and worth a listen, but you can hear the clip here:

https://www.youtube.com/watch?v=jT6JdGHVbj0&feature=share&t=13m37s

We want “The DevOps” but we don’t want to change anything. Is there some way that we can DevOps without changing anything. Give us that thing. Can we just have the DevOps certification and then we’re done with you?

Hiring a consultant or even getting a handful of people training/certification is easy. Changing your organization, changing multiple teams’ responsibilities and relationships to each other, building trust and tearing down walls is hard.

Another inspiration for this post was the video Don’t Reward Yourself Before You Earn It by John Sonmez

Photo Credit: Link from http://taxcredits.net/

I worked at a company several years ago. We created a dedicated devops team. The rationale was solid – the company had a monolithic idea of roles and titles. We also had a large group on both sides that were only interested in doing their little bit and going home. By creating this title/team, it was easier at a company level to justify them working on non-standard projects.

So a “devops” team was created. This was a small team of what essentially boiled down to “super sysadmins”. We wrote puppet manifests, worked with the developers to automate build processes…shit like that.

What ended up happening was that the devops team was seen as elitist by the operations team, nosy and invasive by the developers and everyone just passed the blame on to them – “Devops did that. Not us”

In my department we setup a DevOps responsibility rather than a team or specific job title. The responsibility lies with a subset of the sysadmins and developers. It doesn’t take them out of their main teams and it’s not their only responsibility.  They do their main day to day work respectively with the rest of the sysadmins and developers but additionally have a role being on call, exposing monitoring capabilities in code as well as hooking it up to tools, setting up automation, doing deployments, etc.   Lessons learned are shared with the rest of their teams and the members with this on call responsibility are not coincidentally also some of the most well respected troubleshooters and thought leaders in their groups leading the whole team to improve.

User stories for themselves or other dev/sysadmin team members are created in JIRA under a DevOps epic along with a DevOps label. Though it’s not a perfect world where these stories are always done right away in the next sprint or on top of Kanban TODO list, the team members do have incentive to push for the improvements generally in the areas of monitoring or some reliability improvement.

As with many places, there isn’t a special budget to just spin up a new DevOps team, but by building the roles from within existing teams we captured the experience of the teams.  Augmented occasionally with some help from automation experts from other parts of the organization, this has worked well. It should go without saying that members with DevOps responsibility should have capacity budgeted in their sprint to deal with production issues and continuous reliability improvements, but sadly common sense is not necessarily common.

Photo Credit: Doc Searls – Link