Jim Rose on continuous integration and delivery

We’ve talked about the importance of lots of iterations paired with careful observation and on the development side of things, as a product manager, your interface with development, few things are as enabling for this as a continuous integration and your continuous delivery capability. With us today is Jim Rose, CEO of CircleCI, which provides commercial products that,

that help enable this capability. Jim, thanks for joining us. Thanks for having me. How would you explain continuous integration and continuous deployment to a product manager who is new to the topic? So, continuous integration and continuous deployment are basically end to end automation of the development process between the time a developer makes a change to code until the time that that code is a running application in the data center. So, continuous integration talks to the first part of that, and every time a developer makes a change the code, it merges that code into the main code base, and then tests the code base, and makes sure that everything is good, and everything still works.

Continuous delivery or continuous deployment is then being able to take that change in the code base and then being able to push that actively and automatically into the data center. So that’s kind of the Holy Grail. Once you get to continuous deployment you have end to end automation from a changing code to an actual function application that, instead of taking hours or weeks, can take just minutes. What do you think are the three most important things that a product manager needs to know about this emerging super important area? The first is that it’s all about speed to learning.

So, the idea of being able to make changes in your code, see those changes to your code, ultimately, in front of customers, is all about trying to reduce the time it takes between coming up with an idea and then actually getting data from customers. So, it’s all about getting things into small bite-sized pieces, and being able to push those quickly, and then iterate quickly on top of that. In order to be able to iterate, you have to be able to automate.

So, as much as possible you want to take out as many of the manual gates and as many of the manual processes between the time you make a change in code, you know, that code being in front of a customer. And then, the last piece is, because it’s all about speed to learning and it’s all about being able to see the impact of the changes that you’re making to your code, you need to know what you’re measuring.

So, you need to, in advance, be able to define what success looks like, how you would measure success, and then make sure, in your system, that you can actually see the results of the code as it goes live in front of a customer. Once you have all of those pieces together, you can really start to move quickly. And I think sometimes in practice there’s a tension between the product manager and their interface with development team where the product manager wants to get more features in there and the dev team wants to relieve some technical debt and, for example, invest in improving this automation, this delivery capability.

You talk a little bit about your land, your perspective on technical debt, what is it, and how PM should think about it. Yeah. So, technical debt is basically like the remainder of your development equation. So, technical debt is a result of informed choices that you’re making when you’re trying to build new features and get them in front of your customers quickly, and also, potentially just shortcuts that you take ultimately to try and speed up.

You should be incurring technical debt because you never want to be working on something until it’s perfect and it’s 100 percent done before you ship it out to a customer because, chances are, you’re 80 percent right on anything you ship and the question is which 80 percent. So, you want to get that feature in front of your customer as fast as possible so you can start getting data. And then, ultimately, you just have decisions that are in your code base that need to go back and be addressed. They just are shortcuts and they just have to be managed. And, what do you think is the best way to minimize and manage technical debt?

So, we create time inside of our development process to always address technical debt and always have, basically, a line item for maintenance inside our delivery system. So, the first step is, we divide product discovery, the idea of trying to find new and different features and new and different things to put in front of the customer, away from delivery. The idea of being able to create production ready software. That’s step number one. So it’s called dual track agile. It’s the process that we use internally. The second part of that is, in your delivery pipeline, you really want to break up each part of your delivery capacity into different buckets.

The first is, you never want to allocate 100 percent of your time because things change,

you get interrupted because production goes down, something takes longer than you expected. So, what you want to do is leave at least 20 to 30 percent of your overall development capacity totally unallocated. It’s basically slack in the system that, as things come up, you actually have the ability to address it without necessarily pushing back deliverables. The second part of it is, for the parts that you do allocate for your development team, the way that we do it internally, is we take 40 percent of our time and we allocate it to the construction of new features or radically new versions of existing features. So new things that are getting in front of customers, we usually take about 40 percent to that.

We take 20 percent and allocate it towards the maintenance of existing features, just fixes, enhancements, and those different pieces. And, we also leave 20 percent allocated for maintenance, technical debt, architecture debt. So your development team knows that they always have time to be able to address the pressing technical things that everybody wants to take care of and don’t feel like they have to either do it off menu and not tell you about it, and also don’t end up in a situation where you you end up with a pile of technical debt at the end of a development process that then you have to start paying down. Some great advice on managing your delivery capability. Thank you so much, Jim.

Sure, you’re welcome.