Why DevOps? Convince your boss in 5 minutes.

What if I said to you, “It’s safe and possible to release work to my customers at any time.” Would you be able to say the same? You might have your own questions and concerns before you answer.

On reflection, you might consider that its probably not at all safe to release your work straight to the customer. Something beyond your control might break! You might say something like, “well… I’m not trusted to release my work at any time,” or “I don’t trust others to release their work at any time.” Additionally, there may be other procedure in place that make releasing work at any time problematic.

Each one of these concerns yield great team discussion about ways to make things safer, or to increase trust, or to streamline processes. As concerns are discussed, we start to move a closer to, “Maybe it is possible to release our work at any time…” But… many teams inevitably reach a seemingly unsolvable problem.

Consider being a member of the development team, all the way to the left in the process, with teams and phases sitting firmly between you and the customers at the other end. Of course, you’ll never deliver your work straight to them this way. Now a batch of new work is sent to your Development team, who completes it as quickly as they can, delivering it to the next team to do something like functional testing, after which, if successful, the batch goes on to performance testing, and so on. These phases vary between organizations, but this is roughly the situation. Eventually, the batch of work makes it to an Operations team responsible for deploying the batch into a production environment for customers to use.

So, an idea, originally intended to delight customers, enters development as a large batch of work, but must make its way through the entire process before being delivered to customers months later, or longer! This is a “batching issue.”

It’s intuitive to think that if we are given all of our work at once, then we will be able to focus and get very fast, completing the whole batch efficiently, passing it all on to the next group to do the same. The strategy is, “batch it up, and be the fastest at processing your batch.”

We can test this strategy in a simple, and cheap, exercise using only pennies and a timer. For this exercise, we have 20 pennies and a customer that needs their pennies to be flipped 4 times. Of course, they’d like to receive fully flipped pennies as soon as possible.

Starting with a batch of 20 pennies and a penny flipper for each time the pennies need to be flipped, we can simulate all 20 pennies being flipped once, then passed on to be flipped a second time. Only after all 20 pennies are flipped a fourth and final time does the customer start to receive their fully flipped pennies. With this batch size, they get all of the pennies, all at once …a nice big release.

Typically, the batch of 20 pennies can be flipped 4 times in about 2 minutes. Since all pennies are delivered at once, the customer gets their first and last, of the 20 pennies, at the same time, in about 2 minutes.

If you run this exercise with 2 batches of 10 pennies, or 4 batches of 5 pennies, the customer gets their pennies faster and faster. Doing 1 penny at a time, essentially a batch of 1, yields significantly faster deliveries. Doing 1 penny at a time means 1 penny is flipped and passed for its second flipping, then for the third and fourth, and delivered to the customer with the rest of the pennies flipping in right behind the first.

Done this way, the first penny is delivered to the customer in about 5 seconds! Further, the customer continues to receive pennies until the 20th penny arrives at approximately 30 seconds. This is a big deal. By reducing the batch size to 1, the customer starts receiving value in 5 seconds instead of the original 2 minutes, and then they receive everything originally asked for in 30 seconds instead of the original 2 minutes. That’s a big difference for the customer.

So, we can prove through this exercise that there’s a much faster way to deliver value to our customers. DevOps is how we do this, by essentially flipping the old process to release smaller batches more frequently.

By having everyone on the same team necessary to release work, and keeping our batches of work very small, our teams can deliver value to our customers more frequently and significantly sooner. Automated Testing and Continuous Integration are only two examples of methods to help achieve our improved collaborative focus on better product development and delivery to our customers.

DevOps transforms teams allowing their definition-of-done to include putting value in the customer’s hands. This is what DevOps is about and this is why we do it.