3 signs you're on an actual DevOps team

Creating a DevOps team that’s headed in the right direction is harder than you might think. There’s not a one-size-fits-all approach to DevOps, but by embracing new strategies you can make sure your team is a true DevOps team. Read more in the post below, which was originally published here on InfoWorld.com. 

Everyone’s hollering “DevOps” so much these days, you might be ready to just give in and go buy a box of it. Except that DevOps is, for the most part, not something that comes in a box. Sure, there are tools that can help a DevOps-centric organization work more smoothly, but the heart of DevOps is in the teams that implement its philosophies. Implementing DevOps means embracing some new – and sometimes scary – strategies for team organization, responsibilities, and expectations. Here are three things that will tell you you’re on a DevOps team that’s pointed firmly in the DevOps direction:

1. DevOps: Product-based teams

A true DevOps organization will typically organize IT teams around the products those teams deliver. That means abandoning the old discipline-silo approach that most of us have used for decades. A DevOps-style product team (like this) will include things like product managers, developers, infrastructure experts, systems administrators and everyone else needed to make that product become a production reality.

Of course, many of those responsibilities won’t be a full-time occupation on every project. It’s not unusual to have a single network infrastructure expert serve on multiple product-based teams, for example, sharing their time as needed based on organizational priorities.

There’s also still a lot of value in discipline-specific coordination. Having all the sysops maintain a high-level view of everything that’s happening can ensure smooth operations, and having all the developers occasionally “huddle up” can make it easier to share new techniques, lessons learned, and other valuable information. That happens in cross-product guilds, where members of each discipline occasionally get together to talk shop and share information.

2. DevOps: Failing with style

True DevOps teams don’t try to prevent failure by slowing the rate of change. Instead, they play to move quickly, trusting in their team’s ability to recovery from failure just as quickly. By deploying products in small, controlled sprints, teams know that the number of changes being deployed in any given moment will be minimal, thus mitigating risk and making it easier to recover quickly.

DevOps teams welcome failure as a significant learning experience. Thanks to automated delivery pipelines and automated unit testing, each failure becomes another test that gets incorporated into the build process. Rather than relying on institutional knowledge and experience to prevent the same failure in the future, DevOps teams code everything into their process, automatically preventing the same failure from happening twice.

A DevOps team still tries to anticipate and prevent as much failure as possible in a proactive sense, but doesn’t shy away from the occasional hiccup, either. Culturally, this means organizations have to adopt a mature attitude about failure, eliminate “the blame game” from the culture, and focus on anticipation, learning and prevention as a deeply rooted part of their process.

3. DevOps: Obsessive automation

A real DevOps team knows that human error is the biggest point of failure in any process, and the biggest bottleneck when it comes to moving quickly. These teams adore automation, both for its unfailing consistency and for its incredible speed. From code check-in rules and analysis, to test environment spin-up, to actual unit testing, all the way through to final production deployment, these teams know that automation is the only way to go.

But a truly effective DevOps team isn’t particular about their automation tools or technologies. They focus on the right tool for the job, and they’re willing to step away from one tool and adopt another if it provides a smoother path to the business end-goal. Heterogeneous just begins to describe the average DevOps shop, and that can be a huge challenge for legacy organizations that have a deep philosophical commitment to a particular platform or approach.

Effective DevOps teams know that the whole point of IT is to deliver applications and services to their users–delivering user experiences, not just features–and that everything in between is just a lot of potential for speed bumps. They know that the job of DevOps is to provide the smoothest, safest, fastest and most reliable path between the developers’ keyboards and a production deployment, so that each new coding sprint can quickly result in a tested production deployment. DevOps isn’t “NoOps;” rather, it’s an obsessive operation effort to automate as much of Ops as possible.

DevOps is a major shift

From companies that abhor and control change, rely on manual deployments, focus heavily on manual QA processes to catch problems and maintain a silo-based organizational chart, DevOps can come across as strange, controversial or even crazy. But trust me – some of today’s most agile, fast-moving and highly reactive technology companies are relying on DevOps-style approaches to put more product into the hands of their customers than ever before. They’re doing so with less internal bureaucracy, a stronger focus on results and customer experience and – generally speaking – happier technologists and less employee turnover. 

Learn more with Pluralsight's path to prep for the exam: AWS Certified DevOps Engineer