How to Implement DevOps in Your Organization

How to implement DevOps in your organization

You’ve probably read about all the benefits DevOps offers tech teams once it’s embedded…but how difficult is it to introduce to a company that doesn’t use it currently?

If you’re the one who has that responsibility, it’s easy to feel under pressure.

The good news is, with some advance planning, a fair amount of hard work, and lots of communication, it is absolutely possible to implement DevOps very successfully.

If you put the work in and take it a step at a time, expect skyrocketing productivity gains, long-term cost savings, and happier, more unified technology function – as well as a place in senior management’s good books.

Why Implement DevOps?

Before you begin, you might be wondering ‘why DevOps, and what advantages would a long and potentially expensive implementation project offer me?’

Think of DevOps as an Agile approach to managing the relationship between your development team and your IT operations team. Those silos that exist currently, which hold everyone back, and result in missed deadlines and inter-departmental bad feelings…with a successful DevOps implementation, they could be a thing of the past.

Organizations that use the DevOps methodology can cut their time-to-release from weeks and months to days and (in some cases) hours. It’s hard not to be tempted by that capacity for speed – whether you want to launch your new, groundbreaking app before any competitors pop up, or simply get a bug fix out quickly to resolve customer complaints.

DevOps will save you time and money by shortening time to deploy significantly…and your competitors know this too. As more companies adopt DevOps, you’ll find it increasingly difficult to keep up – best be ahead of the curve now than behind it later.

Creating a DevOps implementation plan

Because DevOps is an approach to working rather than something more tangible (like a new software tool), it seems like a pretty intimidating thing to try and implement, right?

The good news is that if you keep a level head, devote enough time to planning, manage expectations, and keep everyone in the loop about what’s happening, DevOps is a change you can manage like any other.

The one essential thing to keep in mind is that DevOps will transform how your organization coordinates both its development projects and its IT operations – and this can have a knock-on effect across the entire workforce.

If, for example, you’re adopting DevOps for deployment speed, are your marketers ready for the increased activity surrounding new releases and features? Does your customer service team have the capacity to deal with the heightened levels of customer service requests that come with each feature release?

All of this means that transparency, communication, and teamwork will be key in making your implementation a smooth and successful one. Use the steps below as a framework for managing and communicating this change.

1. Initial consultation with key stakeholders

What sort of IT landscape are you implementing DevOps into, and what do you hope it will change?

You’ll never know unless you ask the people who know best – your development and IT operations teams. Consult with them extensively, create some focus groups, and schedule in some interviews until you have a solid idea of where you’d best feel the benefits of DevOps approach.

Doing this before creating any sort of implementation plan, project budget, or timeline is a good idea because:

  • No-one knows your existing IT challenges like your existing IT teams. If you want solid, real-world information about current challenges, productivity bottlenecks, and inter-departmental silos, this is the place to start.
  • Your IT teams are more likely to get onboard with the project if they see it as a collaboration, rather than something imposed top-down by management because it’s currently trendy.
  • You’ll be able to identify your DevOps needs more clearly, and this could affect the hires you make.
  • You’ll be able to present potential hires with a clearer picture of what you have now, and where you’re looking to move towards.

Remember: both organizations and people (and people in organizations doubly so) are naturally change-resistant. This is the first stage in getting people onboard with your DevOps project, so keep it open and encourage as much discussion as possible.

And…keep it celebratory! This is an exciting change after all, so let your enthusiasm show through, talk about it with as many people as you can, and run open meetings with free food. Do everything that’s the opposite of hiding away in your office and implementing it on the sly.

2. Decide which sort of DevOps engineers you need

Now that you’ve got the right info, you’ll have a better idea of the challenges you hope DevOps will solve, and the skills you’d be looking for in any new positions you create.

‘DevOps engineer’ is a pretty broad role description – and whilst very good generalists exist, you might be looking for something more specific. This could include:

  • Release manager: oversees the planning, scheduling, controlling and release of a software build.
  • Automation expert: fairly self explanatory. The go-to person for all things automation-related.
  • Software tester: responsible for all DevOps-related software testing.
  • QA lead: ensures quality and adherence to standards across the DevOps function.
  • SecDevOps engineer: takes the lead on embedding the appropriate security measures into your release cycle and across all other DevOps processes.

Before looking externally (and factoring in all the costs associated with new hires), investigate whether there’s anyone internally who’d be interested in a change of role. Both software engineers and IT ops staff can make great DevOps engineers, and hiring internally will take advantage of that bank of operational knowledge employees build up by working in the same place for a while. It’s also reassuring, particularly for those resistant to DevOps implementation, to have a sense of continuity to the change.

If you’re hiring more than one DevOps engineer, a good balance is to hire some externally, and mix them in with a couple of internal hires. You’ll get both the fresh experience and enthusiasm that new talent brings, and the operational knowledge built up by seasoned employees too.

3. Create a project budget and timeline

Now that you know what sort of person you want to hire, and what challenges you think they can help solve, you’ll no doubt want to shout about the potential benefits from the rooftops.

Before you go all out, however, make sure that you can confidently answer:

  • ‘When is this happening?’
  • ‘How much will this cost, and what benefits do you expect to see from it?’

Creating a realistic, reassuring timeline

Tempting as it is to try and get your project done at breakneck speed, take a step back and allow yourself time to think things through. If you implement poorly, hire the wrong people, or don’t allow an appropriate amount of ‘bedding in’ time, you won’t feel any of the benefits you’re after.

Your DevOps implementation timeline should include:

  • Time to hire
  • Time to onboard
  • Time to get the function up and running
  • Time to train

Whatever you do, don’t assume your work is done once the new hires have arrived on their first day. People don’t want to be told “the new hires will start on the 18th March.” They want more detail than that. Rather than milestone dates, divorced from any context, aim for a more real-world approach.

Something like:

“We’ll be hiring over the next three months, with a proposed start date of 18th March. For the first couple of months after that, the DevOps team will be working towards some process improvements in consultation with key IT stakeholders. We’re aiming to have the first of these go live on 1st July.”

You don’t have to give all the details in the world, but you do need to give a sense of planning and purpose. Reassure people that there’s more to it than ‘new hire starts, everything changes suddenly’.

The budget

Your budget for implementing DevOps should cover:

  • The first year’s salary for each DevOps engineer you hire.
  • Hiring costs ($4,000 to $8,000 per hire, depending on which study you read and which hiring methods you use).
  • New software – a new DevOps hire is useless without the tools to do the job. You might already have some of these, though you’ll probably need to purchase others. Don’t forget – more user subscriptions to software packages you rely on day-to-day, like team messaging services and productivity software, need to be factored in as well.
  • New hardware and office equipment. New laptop, desktop, and company phones required? Add those costs here.
  • Any training courses your DevOps hires will need to complete. These costs may be higher if you’re training someone up internally rather than bringing in someone more experienced.

As a quick aside, you should be looking at the following types of software as part of a DevOps investment – for more detail, check out our blog on what DevOps engineers do day-to-day.

  • Automation tools: for automation of your delivery pipeline.
  • Containerization software: contain apps (and their configuration files and libraries) in their own operating environments so they can run across different machines.
  • Configuration management software: allows DevOps teams to configure, manage, and automate your infrastructure.
  • Monitoring software: monitors your infrastructure for issues and helps with speedy resolution of any problems.

Next, think about what you want to get back from your DevOps investment and when you might achieve this. In the long term, a DevOps investment can cut your time to market, increase organizational security, resolve IT issues faster, and result in happier, more connected teams that are easier to manage and more likely to stay working for your organization.

This last point is overlooked far more often than it should be. Remember that there’s a big shortage of IT professionals right now – especially software engineers – so if they’re unhappy, your technical-oriented teams can and will jump ship for something that suits them better.

Then, start to figure out how to quantify this. This will inevitably require a few estimates rather than precise calculations – but you should be able to get to a relatively useful indicative figure here. If there’s any doubt, remember to understate rather than overstate – it’s always better to exceed your promises than to fall short, particularly where justifying it to senior management is concerned.

4. Decide on some project KPIs

One mistake that businesses of all kinds make is that once a change has ‘gone live’ in their organization, they leave it and don’t check back in to see whether everything is running as it should.

Don’t fall into this trap. You’re not implementing DevOps so that it can solve existing issues but create new ones. Identify some KPIs and track them  religiously to make sure you realize the benefits you wanted when you first started the project

These could be:

  • Budgetary: are you spending less whilst doing more?
  • Time-centered: are you getting releases out quicker?
  • People-centered: do your IT teams report being happier and more productive?

There’s no such thing as too much tracking. Keep a close eye, and don’t beat yourself up if something starts to go south. There will be issues (when have you ever worked on a business project that went 100% to plan, 100% of the time?!) – but if you keep your eyes open, you’ll catch them in good time and be able to take corrective action/

You might realize that a lack of experience in, for example, SecDevOps is holding you back, and either make another hire or invest in more training for your existing team. Tracking your KPIs means this small problem doesn’t go undetected and turn into something more serious further down the line.

4. Share, and share more

You have everything you need to share your DevOps implementation plan with the world. The project timeline and budget are researched, realistic and raring to go. To use a horrendous corporate metaphor, all your ducks are in a row.

Now’s the time to share your plan with the rest of the organization. Don’t limit this to your tech teams – get the whole organization involved!

Remember those departments we mentioned at the top of this article – the ones like marketing and customer service whose working patterns may also change as a result of a DevOps implementation? They’ll want to be kept in the loop too, so run regular drop-ins and stand-ups where you can field their questions, rather than keeping it among the higher-ups.