Dedicated DevOps? I Smell a Rat…

You can’t just hand a team some tools and expect them to "do" DevOps. Success depends on a coordinated cross-departmental effort involving people and cultural change.

DevOps has been around for several years now, so it’s striking to still see so much variation in how it’s understood and implemented across different software development organizations. DevOps has become a trendy but nebulous buzzword that means a multitude of things depending on who you ask. Some organizations that implement Continuous Integration and Continuous Delivery, for instance, say they do DevOps, and conversations I have with DevOps engineers and teams often immediately gravitate towards a long list of supporting tools – Jenkins, Ansible, Docker, and Terraform, to name just a few. What I rarely hear people talking about is people, organizations, or culture.

Are You Doing DevOps or “Doing DevOps?”

Whatever the name might suggest, DevOps isn’t just about development and operations; it’s about the high-performance, cross-departmental working of all critical functions. It’s an organization-wide movement, requiring everyone from the CEO downwards to buy into it if it’s to be successful. This means development, operations, product, security, marketing, legal, and even sales are each responsible for different elements of the successful delivery of working software.

I smell a rat when I hear organizations talk about having a dedicated DevOps function. DevOps isn’t a function you can devolve to a separate group or team and expect to reap the full benefits. Often these teams are in fact not even much more than a glorified operations function given a fancy name. Sure, perhaps they do some cool work to simplify the automated delivery of software for developers, but fundamentally there is still a handoff between development and software in production.

Don’t get me wrong, it’s definitely worth building up a team to provide high-quality tooling and automation to support DevOps ways of working. Netflix, for example, has an Engineering Tools Team that is responsible for some great open source contributions to DevOps practices, such as The Simian Army and Spinnaker. At FINkit, we have our Cloud Platform Operations Team that strives to make development on our platform as efficient and easy as possible by providing automation and tooling that supports the rapid development of software. Essentially though, these teams are not operations teams. There are no handoffs of software; they support the business to get things done.

How to Use People and Culture to Make the Most of DevOps

Make Change Easy

Let’s get the tooling and automation stuff out of the way. Yes, automate and codify everything you sensibly can. Think hard about your architecture and whether it can support many small changes a day – it’s far easier to "fix forward" on a small, well-defined and well-understood change than a huge change of potentially thousands of lines of code. This is one of the reasons a microservices architecture works well in a DevOps world.

Changes to code and underlying infrastructure should be easy to perform and audit. While CI for software services is commonplace, it’s far less common to see infrastructure managed as code. Codifying your entire estate makes it far easier to automate, test, change, and audit. There is an investment is putting this into place but you will reap the benefits in the long term. The automation and tooling piece of DevOps is essential to success, yes, but for me, there is much more to be done around people, collaboration, and culture to make it really fly.

Agree on Shared Goals

Everyone in the organization is responsible for the successful delivery of working software, so ensure that people and teams are set goals and objectives that align with your business requirements and with each other. For example, have objectives relating to production stability and performance for your developers, and perhaps add objectives concerning code review and quality for your ops guys.

Build Cross-Functional Product Teams

Break down silos and build product-centred teams that include all the roles and skills required to work autonomously with just some steering direction from senior management. Each product team should have the development, product, security, infrastructure, and testing resources required to complete a given product feature (ideally, all those resources will be in the same place). This approach has many advantages: knowledge is shared among team members who perhaps in the past would have been stuck in just their respective areas of expertise, it reduces handoffs to other teams (almost eliminating queuing when set up correctly), and it’s easily scalable.

Hire (and Trust!) Great People

Provide clear guidance and direction to your product development teams, then give them the freedom to deliver as they see fit. As your product grows, having autonomous, empowered teams will be essential to scaling success. This can be a tough one for management, who have to let go and give over some control. To some, this may feel like letting the foxes loose in the hen house, but this is a key element of the cultural shift towards true DevOps.

Encourage Accountability

You break it, you fix it: make developers accountable for the code they push into production. If you know you’ll be called out if there is an issue with your change, you might think twice about pushing that fix at 17:29 on a Friday afternoon.

Pursue Continuous Improvement

The hard work is never done! Identify key useful metrics, both technical (e.g. number of errors) or team-based (e.g. the time work items spend in wait status), and measure them. Review them regularly and identify where your constraints are. As per the Theory of Constraints, remember that investing in fixing anything except the source of a given constraint is waste.

Show Transparency

Make every stage of the process visible and accessible to all stakeholders. Embrace failures and learn from them. Be open about failure, encourage blameless post mortems, and publish lessons learned.

Ultimately, there are many ways to skin the DevOps cat – but the foundation of meaningful DevOps adoption lies in addressing people and culture first and foremost. Cross-organization buy-in and shared goals will really help you get the best out of all those amazing tools, pipelines, and platforms.