So what exactly is Devops anyway?

You’ve probably heard the phrase ‘devops’ used by your engineering team but you may not be sure exactly what it means. Sure, you know that is has something to do with your infrastructure and that the people who work in devops tend to be obsessed with making things work better, but unless you randomly decide to dig a little deeper by asking specific questions one day, it’s unlikely that you’ll be directly exposed to the day to day intricacies of devops teams if you work in product management.

Devops is typically defined as a combination of 3 distinct disciplines: development, QA and operations. OK, so that explains the ‘dev’ and ‘ops’ bits but does that help you much beyond that? Probably not.

Devops is best thought of as a culture and not a single project.

It’s a culture which, when fostered and implemented effectively, can have a major impact not only on how your team works day to day but also on your users. More on that later.

The goals of devops

Broadly speaking, the primary goal of devops is to ensure that your processes and operations are streamlined effectively so that your development teams focus less on their tools and processes and more on building elegant solutions to important problems.

The goals of devops include:

Automating code testing
Automating workflows
Automating infrastructure
Automating everything

Developers shouldn’t be spending their time battling annoying infrastructural problems linked with deploying code. Devops engineers will help to resolve any potential infrastructural problems which free your developers from the burden of having to fix infrastructural problems when they go wrong.

The characteristics of a strong devops culture

When a team has a strong devops culture there are usually a few characteristics you’ll notice:

Automated testing
Continuous integration
Continuous delivery
Clear communication between team members

Automated testing

Automated testing is the process of automatically running tests to ensure that new code which has been added to the codebase hasn’t broken anything. Commonly referred to as TDD, test driven development is a development approach where engineering teams will write tests alongside the feature they’re building which test the code in units. Think of units as frames of a movie; in isolation they can’t achieve much but combined with the rest of the units in a codebase they perform the core functionality of your product.

In a TDD environment, developers will write their own unit tests for a specific feature they’re working on and will run the tests to see them fail. Once the tests have ‘successfully failed’, work begins on developing the specific feature / functionality. The tests are then re-run to ensure the functionality built meets the test specifications.

A strong devops culture will automate the process of testing your existing codebase and new functionality so that you can monitor when any new features / functionality may have broken the existing code base. There’s a few tools devops engineers will use to do this and we’ve included a link to some of the most popular at the end.

Continuous integration and delivery

Continuous integration describes the process continuously integrating new code into your main codebase and often works alongside another characteristic of devops culture – continuous delivery.

Have you ever worked in an organisation where releases only happen every few months? It’s rather painful. To coin a phrase from Twitter Product Superstar John Cutler, this is a classic case of #tragile (a tragic form of agile).

#tragile#agile tragically misinterpreted, or #agile gone/done tragically wrong

Example: The team spent 1 month breaking the project down into 1200 detailed user stories, estimated in ideal days, with pixel perfect mocks … “that’s #tragile!”

— John Cutler (@johncutlefish) December 13, 2017

There is no greater symptom of poor devops process than a company which ships software every 6 months. There’s usually a good reason for it and the folks involved generally feel impotent to do anything about it; the technology is outdated, there’s legacy code is all over the place and most of the engineering team don’t communicate with each other or if they do, it’s either by loud, aggressive rants or quiet, Slack-based passive aggression.

Continuous delivery describes the process of releasing – or delivering – code frequently. Ideally not every 6 months but on a daily basis if possible. This is often much easier in startups where the infrastructure has been built from scratch and you can start with a clean slate.

The benefits of continuous delivery

A word of warning though – getting to continuous delivery is often difficult.

Dealing with legacy code, changing mindsets and overcoming organisational hurdles all play their role in making the journey towards continuous delivery more difficult. But it is possible, providing the right people are incentivised to make the changes and that the rest of the business clearly understands what the benefits are. This is difficult, but possible. Here’s how.

Transitioning from Tragile to Agile

If you’re looking to shift from archaic outdated modes of delivery and closer towards continuous delivery here’s a few steps to get you there:

Educate – pick a few stars to become continuous delivery ambassadors who can educate the rest of the business and teams on the benefits of continuous deployments vs. deploying every 6 months. Ambassadors can (and probably) should be from a broad spectrum so that the whole business understand what is going on.
Success stories – using new projects or hack days, build up a repertoire of small success stories that can be used as case studies to demonstrate to your organisation the power of continuous delivery and strong devops processes
Upgrade – with a degree of momentum behind you, invest the time, energy and resources into upgrading your old CI infrastructure

The transition won’t happen overnight but setting clear, metric-based goals will allow you to work towards stronger devops processes which help foster a devops culture.

If you’re releasing every month today, aim to get down to every 2 weeks.

If your team have made it clear in your retros that they’re spending 60% of their time every day fixing broken builds, aim to get this down to 50%.

If you have no code test coverage coverage and you’d like to get to 100%, aim to get to 10% first.

Baby steps will act as milestones for your team and everyone will feel good if you hit them. If you don’t, the target milestones will have a motivating effect anyway.

Why should product managers care?

You might be thinking to yourself, well this is all very nice but why should I really care as a Product Manager? And you’d be partly right to wonder why; product folks don’t really have much business telling the devops team how to do their jobs or telling the CTO how devops should work in your organisation.

However, there are a few reasons why you should care about an effective devops culture in your team as a product manager:

How should devops work in my team?

If you’re thinking you’d like to introduce a devops culture into your team or that you’d like to strengthen your existing culture, tread lightly at first since you’re likely to get push back from your technical leaders if you’re from a product background. As with most things product related, you won’t have direct control over how you might implement a change in culture, particularly relating to your engineering teams. It’s ultimately your technical leaders’ responsibility to implement devops culture changes but you can potentially influence how this takes shape from the sidelines.

There are numerous ways a devops culture can be fostered and introduced into teams and there is no 1 set way to do it ‘properly’. Perhaps the most important principle is to be clear about the goals of devops and to explain the rationale behind why you might be introducing a devops person into your team.

Team structures

Here’s a team set up which works well in some cases:

This setup ensures you have at least 1 dedicated devops person who is overseeing the operational processes and infrastructure but with the added bonus of a rotating member of the engineering team.

Once every 2 weeks (or at a time interval that suits your organisation), you rotate the engineer that sits with your devops person. During this 2 week period they become a bona fide devops team member and can either attend the regular standups or have a separate stand up. If you do introduce a separate stand up, make sure you have at least 1 main standup with the whole team or you run the risk of being disjointed. Likewise, ensuring a devops person sits in on your retros is vital since your retro is often the time when day to day issues relating to infrastructure / devops might get raised.

Whilst this approach might not be suitable for everyone (particularly in organisations where resources are tight) this approach has 2 primary benefits:

It prevents the devops engineer from becoming separated from the ‘main’ development team and
It ensures the devops engineer is aware of the day to day problems being faced by engineers who are doing the day to day work. Without physically sitting together or collaborating in this way, communicating the day to day issues faced by the engineering team can be more difficult to articulate.

Devops tools and terminology

Here’s a selection of some of the most common tools used as part of a devops culture and a little explanation about what the role each of these tools plays in the overall process:

Git and github – used to store repositories of code and help developers with version control. Here’s a little explanation of how it works.
Jenkins – a tool used with continuous integration testing. If your engineers are continuously adding new bits of code, Jenkins will act almost like the gatekeeper and flag up any potential issues so that they know that something’s broken and needs fixing.
Green build / red build – used by your devops and engineering teams to highlight that your code base’s tests are either passing or failing. If the build is green, all tests have passed, if the build is red a test has failed somewhere.
AWS – Amazon Web Services, a monolithic suite of products loved by devops folks, used for hosting your application and a whole bunch of other fun stuff.
New Relic – used by devops teams to continuously monitor applications and identify problem sources – down to a single line of code sometimes. If something goes wrong, New Relic will flag it up to the relevant person, via email or text message usually.