cancel
Showing results for 
Search instead for 
Did you mean: 
Create Post

Start Your DevOps Journey by Looking at the Value You Add

Level 9

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.

joepPiscaerImage1Post1V2.png

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:

  1. Deployment Frequency: how often does the team deploy code?
  2. Lead time for changes: how long does it take to go from code commit to code successfully running in production?
  3. Time to restore service: how long does it take to restore service after an incident (like an unplanned outage or security incident)?
  4. 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:

  1. Customer satisfaction rate (NPS)
  2. Employee satisfaction (happiness index)
  3. Employee productivity
  4. 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. 

13 Comments
Level 14

So DevOps is just the new name for doing IT the way it should have been done in the first place but rushing it and almost certainly getting it wrong.

Level 14

Thanks for the article!

Level 16

Thanks for the great write up!

Nicely written.  I recommend all teams add budget for training their staff so they're all up to doing the job--and doing it right.  Training everyone to use recognized best practices for security, and so they thoroughly understand how to get the most out of their tools and data and apps is key to not just getting by, but to excelling.

Level 14

Training is the first thing to be cut.  I can't remember the last training I had.

Agreed--it sometimes seems training is under-appreciated by Management, perhaps due to their impression that its worst aspects can include:

  • Worrying about training someone and they leave shortly afterward.  This is easily managed by:
    • Creating a policy that requires employees to continue working for the company for a specific amount of time after receiving training, and if they leave, then:
      • Leaving within one year of training requires they reimburse the company for the cost of the class AND ALSO the additional costs incurred (hotel, meals, travel expenses)
      • Leaving within two years of receiving training means they only reimburse the cost of the class
      • Leaving after two years of receiving training no longer requires them to reimburse the company for any of the training or additional costs
    • Making your company a place they WANT to work at, not want to LEAVE.  Build a team that turns into friends, that does fun things at work AND after work together.  Cross train them so they can do more than just count packets--and they'll be motivated and interested.
    • Compensating them appropriately so they have no incentive to leave.  You're paying a Network Analyst $50K and a company in a similar market pays $80K?  You're just letting the good people go to another company and only keeping folks who aren't doing the best for themselves--or you.
  • Worrying about them learning something new and making mistakes--possibly expensive ones.
    • Get over it.  Trust your employees or train them better.
    • Provide a test environment, real or virtual, to implement the new ideas and processes.
    • Support getting your employees certified in all they do for you

In the long run, training always pays for itself.  It's that ounce of protection that prevents needing a pound of cure.  Employees are valued and they stay around longer.  They're more engaged and interested.

Besides, if you don't provide them training, and they stick around, what have you got?  Someone undermotivated, under-appreciated, and you have no local resources to trust when you need guidance for making big decisions.  You're forced to contract outside experts to advise you--and they can get it wrong, or be motivated to sell you services and products you don't actually need.

Train your internal team and trust them.

Level 14

In the past I was told I would have to sign a contract which stated that I would repay training costs if I left.  I refused and they quickly decided that I would get the training anyway as they would have lost out on a major contract if I wasn't trained.  As it turned out I left after another 3 years so the contract wouldn't have been enforceable anyway.  However I could have caused a major issue if I had been expected to support something without appropriate training.  I also could have caused some serious issues if I had got it wrong because I hadn't been trained.  The whole thing did create some very bad feelings between us.  I have often wondered how much it really cost them as I was far less likely to go out of my way to help them after this incident. 

Level 20

Everything is lean now... I guess out with the old six sigma and in with the new... we relabel stuff every couple years.

That's a real risk an employer takes, both with a contract for services to a customer, and with an employee.  It's a complex dance we must somehow all perform together, in which it is all too easy to step on toes or misstep and fall.

I've been in shoes similar to yours; it's never fun when the training budget is insufficient or missing.  I'm a firm believer in providing all the training needed, having an employee test for certification, and then paying that person the right wage to keep them in-house, making happy customers and increasing profit for years to come.

MVP
MVP

What if we train our staff and they leave?

vs.

What if we don't train our staff and they stay?

MVP
MVP

Nice article

Level 15

Nice concise article.  It is always interesting to see how we re-frame and re-shape the same basic concepts but we keep moving forward.

Level 11

Appreciate the article, enjoyed it.