Starting with DevOps can be hard. Often, it's not entirely clear why you're getting on the DevOps train. Sometimes, it's simply because it's the new trendy thing to do. For some, it's to minimize the friction between the traditional IT department (“Ops”) and developers building custom applications (“Dev”). Hopefully, it will solve some practical issues you and your team may have.
In any case, it's worth looking at what DevOps brings to the table for your situation. In this post, I'll help you set the context of the different flavors and aspects of DevOps. “CALMS” is a good framework to use to look at DevOps.
CALMS
CALMS neatly summarizes the different aspects of DevOps. It stands for:
- Culture
- Automation
- Lean
- Measurement
- Sharing
Note how technology and technical tooling are only one part of this mix. This might be a surprise for you, as many focus on just the technological aspects of DevOps. In reality, there's many more aspects to consider.
And taking this one step further: getting started with DevOps is about creating and fostering high-performance teams that imagine, develop, deploy, and operate IT systems. This is why Culture, Automation, Lean, Measurement, and Sharing are equal parts of the story.
Culture
Arguably, the most important part of creating highly effective teams is the aspect of shared responsibility. Many organizations choose to create multi-disciplinary teams that include specialists from Ops, Dev, and Business. Each team can take full responsibility over the full lifecycle of a part (or entire) IT system, technical domain, or part of the customer journey. The team members collaborate, experiment, and continuously improve their system. They'll take part in blameless post-mortems or sprint reviews, providing feedback and improving processes and collaboration.
Automation
This is the most concrete part of DevOps: tooling and automation. It's not just about automation, though. It's about knowing the flow of information through the process from development to production, also called a value stream, and automating those.
For infrastructure and Ops, this is also called Infrastructure-as-Code; a methodology of applying software development practices to infrastructure engineering and operational work. The key to infra-as-code is treating your infrastructure as a software project. This means maintaining and managing the state of your infrastructure in version-controlled declarative code and definitions. This code goes through a pipeline of testing and validation before the state is mirrored on production systems.
A good way to visualize this is the following flow chart, which can be equally applied to infrastructure engineering and software engineering.
The key goal of visualizing these flows is to identify waste, which in IT is manual and reactive labor. Examples are fixing bugs, mitigating production issues, supporting customer incidents, and solving technical debt. This is all a form of re-work that, in an ideal world, could be avoided. This type of work takes engineering time away from the good kind of manual work: creating new MVPs for features, automation, tests, infrastructure configuration, etc.
Identifying manual labor that can be simplified and automated creates an opportunity to choose the right tools to remove waste, which we'll dive into in this blog series. In upcoming posts, you'll learn how to choose the right set of
DevOps monitoring tools, which isn’t an easy task by any stretch of the imagination.
Lean
Lean is a methodology first developed by Toyota to optimize its factories. These days, Lean can be applied to manufacturing, software development, construction, and many other disciplines. In IT, Lean is valuable to visualize and map out the value stream, a single flow of work within your organization that benefits a customer. An example would be the manufacturing of a piece of code from ideation to when it's in the hands of the customer via way of a production release. It's imperative to identify and visualize your value stream, with all its quirks, unnecessary approval gates, and process steps. With this, you'll be able to remove waste and toil from this process and create flow. These are all important aspects of creating high-performing teams. If your processes contain a lot of waste, complexity, or variation, chances are, the team won't be as successful.
Measurements
How do you measure performance and success? The DevOps mindset heavily leans on measuring performance and progress. While it doesn't prescribe specific metrics to use, there are a couple of common KPIs many teams go by. For IT teams, there are four crucial metrics to measure the team's performance, inside-out:
- Deployment Frequency: how often does the team deploy code?
- Lead time for changes: how long does it take to go from code commit to code successfully running in production?
- Time to restore service: how long does it take to restore service after an incident (like an unplanned outage or security incident)?
- Change failure rate: what percentage of changes results in an outage?
In addition, there are some telling metrics to measure success from the outside-in:
- Customer satisfaction rate (NPS)
- Employee satisfaction (happiness index)
- Employee productivity
- Profitability of the service
Continuously improving the way teams work and collaborate and minimizing waste, variation, and complexity will result in measurable improvements in these key metrics.
Sharing
To create high-performing teams, team members need to understand each other while still contributing their expertise. This creates the tension between “knowing a lot about few things” and “knowing a little about a lot of things.” This is known as the T-shaped knowledge problem. To balance between the two, high-performing teams are known to spend a decent amount of time on sharing knowledge and exchanging experiences. This can take shape in many ways, like peer review, pair programming, knowledge sessions, communities of expertise, meetups, training, and internal champions that further their field with coworkers.
Next Up
With this contextual overview, we've learned DevOps is much more than just technology and tooling; grasping these concepts is vital for creating high-performance teams. But choosing the right approach for automation is no joke, either. There's so much to choose from, ranging from small tools that excel at one task but are harder to integrate into your toolchain to “OK” enterprise solutions that do many tasks but come pre-integrated. In the next post in this getting started with DevOps series, we'll look at why choosing a one-size-fits-all solution won't work.
