Welcome!

DevOps, Cloud and Continuous Delivery Blog

Andrew Phillips

Subscribe to Andrew Phillips: eMailAlertsEmail Alerts
Get Andrew Phillips via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: DevOps for Business Application Services, DevOps Journal

Blog Post

How Continuous Delivery Is Like Pizza | @DevOpsSummit [#DevOps]

Application delivery could learn a few tricks from the pizza delivery business

Our expectations for buying all sorts of consumer goods has gone through a radical transformation we now take for granted. Why should we not expect this same level of service from IT businesses? We accept the status quo for how software delivery exists today but would reject it without hesitation if it were applied to pretty much any other online consumer experience.

Take pizza delivery as an example. Fifteen years ago ordering a pizza meant trying to choose an item from a grease-stained menu somebody shoved under your door. You'd make a phone call and end up speaking to somebody who sounded like they were trapped in a dungeon. You'd do your best to communicate your order, often repeating it a few times. They put you on hold, "Sorry I got to get a pencil." You attempt to communicate clearly with them. They take down your order and promise to get the pizza to you quickly. Ninety minutes later, a half hour late, somebody arrives with a cold pizza with toppings that certainly don't look like what you ordered.

For the most part, this is the experience business consumers of IT have today.

Fast forward to today. Pizza delivery expectations have long changed to the high side. Pizza joints have websites or mobile apps with up-to-date menus, customer reviews and a simple ordering process that allows you to choose exactly what you want. A tracking system can show you exactly where your pizza is, tell you how warm it is, tell you the delivery driver's name and the ETA. They can inform you it'll be there in 8 minutes, 53 seconds. You can watch its progress in real time, ideally speaking.

What is Continuous Delivery? Well, it's a strategy or best practice for turning delivery and consumption of IT into a modern business. We want it to be a business that works in the same way we would want anything else to be delivered - be that a package, a book, or pizza.

If you're on the customer-facing side of software delivery, the problem is pretty clear: the consumer experience of big business IT is disastrous. But does the inside technical IT person really care about that? Those not on the frontlines facing customers, do they care about the buyers who are essentially writing their paychecks?

Going back to the pizza analogy, technology has radically improved the customer experience. It gives the end user relevant, up-to-date insight into how the process works. For software, a Continuous Delivery pipeline should do that, functioning as an automated delivery system, like the dream drone from Amazon.

There's still the fundamental, initial challenge about finding a way to communicate what you want, however. The way continuous delivery as a philosophy addresses that part is by using data and customer behavior - what the customer ordered last time, which parts of the menu they spend the most time on, etc. - to make sure you don't get the new order wrong. Amazon is great at using past buying patterns to determine future wants. If somebody has ordered a vegetarian pizza the last twenty times and they suddenly order a meatball sub, then the system should generate an alert about this anomaly.

The more obvious way CD works is via the agile method of working in smaller bits; delivering smaller units of change because the chance of screwing up big is lowered. If you order an entire banquet at once, the chances of messing up big are high.

As applied to Continuous Delivery, observe your customer's behaviors. See how they actually use their systems. Don't try to second guess your users: look at what they're doing, then use their input. If somebody writes in a feedback form, solicit that input and use their input. The goal is trying to reduce errors, guesswork, and the risk of building the wrong thing. Get insight into the process of delivering it.

You can continue offering a poor service to your end users, or you can start offering the kind of service that your customers are used to getting in most other facets of their consuming lives. And, of course, if you're not going to do it, somebody else most likely will.

More Stories By Andrew Phillips

Andrew Phillips heads up product management at XebiaLabs. He is an evangelist and thought leader in the DevOps, Cloud and Continuous Delivery space. He sits on the management team and drives product direction, positioning and planning.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.