DevOps at (small) scale (part 1 of 4)

I’ve worked in IT for a very long time and I don’t think I’ve ever seen a more powerful approach to running a technology organization than DevOps. I’ve been a big fan of some of the authors since the mid-2000s. I’ve still got The Visible Ops Handbook on my desk. And I had a chance this fall to re-read The Phoenix Project with my (new) team (and my boss!).

I’ve also been enjoying my read through The DevOps Handbook. I find the suggestions very powerful and very timely. But I find that they make the most sense for organizations much larger than mine. I started working with a very small team about 7 months ago (I’ve got three developers on staff). Our challenges look different than the ones described in The Phoenix Project.

But they come down to the same needs – to accelerate the progress of code from our customers’ minds to production, to provide fast feedback, and to break down that code into small, manageable chunks that we can deploy in under two weeks.

How to scale DevOps small

I’m just starting my small-scale experiment with DevOps, but I started with where most projects should start: with the measures. My contention is that DevOps should measure three critical areas:

• Throughput
• Cycle time
• Quality

It turns out that a lot of my concerns about the scale of DevOps aren’t about these three areas of measurement, but the proxies that are used to measure them (and the tools required to gather those proxies).

So the natural conclusion is to look for other proxies, other measures that would allow me to measure these three key areas at a smaller scale.

In the next three posts, I’m going to review the baselines and proxy measures, as well as some of the tools we started using to implement DevOps.