Rolls Royce

DevOps+: How to deliver services, not just products

When I was living in India, I invited a friend over. He said, “I’ll be there in my Rolls-Royce soon,” and I thought to myself, “Wow, he has a Rolls-Royce!” Then he arrived in a motorized rickshaw. “Well,” he said, “it has a Rolls-Royce engine inside.”

Many DevOps champions describe a Rolls-esque state of being. It is, they say, a rich and luxurious experience, a goal to which all companies should aspire. But they often describe DevOps within the context of a relatively narrow scope of activities that take place across product development, testing, release management, and IT operations. That’s the Rolls-Royce engine, but it's not the Rolls-Royce experience.

But to be truly successful, to ensure that your customers have the best possible experience, your product management and development teams need to adopt a service mindset, alongside other technical and cultural changes you’re already pursuing. You need to take a step back and ask yourself: What is the business value and the outcomes my customers require? What are the costs and risks in delivering that value and those outcomes?

DevOps Enterprise Summit: Experts share lessons learned

Enter service management

Development organizations need to understand that customer value is not delivered once the code has been released and is operating in a live environment; it occurs when the customer is actually using the code. And with that use comes the expectation of a service.

The concept of a service can be rather ephemeral to most people, even seasoned service management professionals. It is usually an intangible thing that may draw upon many different products to deliver customer value. A commonly accepted definition of a service is:

“A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks.”

So, for example, when customers look for products to solve real-world problems, your service is valuable if they can find the relevant product bundle, or if they can read and compare expert or user reviews. When customers use your product, they value its ability to deliver desired outcomes efficiently. When the product does not work properly, customers value support options (chat, email, or phone) that enable them to quickly become productive again.

In other words, what customers find valuable changes over time and varies with context. Customers explicitly buy physical and digital goods, but they implicitly buy an expectation of service that will cater to their changing needs when using that product.

Once you acknowledge that customers value both technology and services, you need a way to manage both.

Extended product management

At DevOps Enterprise Summit San Francisco last year, Kevin Behr, chief scientific officer at PraxisFlow and co-author of the book ITIL Practitioner, joined me on a podcast exploring the links between DevOps and ITIL, especially in large organizations.

Kevin is highly experienced in many areas of IT management, as well as in management theory in general. While ITIL is a best-practice framework, he said, it should also be recognized as a series of lessons that IT organizations learned from failing to manage the delivery and support of services.

These lessons are especially valuable today, as new technologies and channels for delivering value emerge. Regardless of what technology your organization creates or uses, at some point you need to manage customer expectations, ensure stability, and achieve resilience. The drive in DevOps to integrate horizontally along the value chain must be accompanied by the transfer of responsibility to manage service components that used to be managed outside of DevOps functions.

Forewarned is forearmed, as the saying goes. It is time to extend your definition of a product to include these nontechnical, service-oriented aspects. Simply put:

Product = technology + services

And by extension, product management equals technology management (software architecture, development, testing, release, and so on) plus service management (customer care, support, governance over changes to live products, and so on).

Make service managers part of the team

In much of the current DevOps literature, the role of service management is acknowledged, but rarely explored; if it is talked about, the role of service management is usually limited to topics such as change management and incident management. 

As DevOps methods extend across the value chain, they will eventually span functional roles, from business relationship management and enterprise or technical architecture to customer and technology support. Leaders of teams that span the entire value chain must ensure that those teams balance the delivery of new functions and features with helping customers during major outages, responding to customer queries, and examining the root causes of outages.

One quick way to accomplish this holistic view of technology and services is to include service managers in development team efforts. They can prioritize and deliver work to be done in the next iteration, help groom the product (technology and services), participate in stand-ups, and so on.

In Chapter 8 of The DevOps Handbook, Gene Kim, Jez Humble, and Patrick Debois describe how to integrate operations into the daily work of development. But why stop there? Read the same chapter, and replace the term "operations" with "service management." Now you are reading about how you can:

  • Embed service analysts/managers into product teams.
  • Assign a service management liaison to each product team.
  • Integrate service management into development rituals (invite service managers to developer stand-ups and retrospectives, and make relevant service management work visible on shared Kanban boards.)

I have implemented some of these techniques in previous roles and jobs I've held, and in my experience service management teams are eager for closer cooperation with product teams. Often, they have inherited legacy controls and processes and are champing at the bit for a chance to change things. DevOps is the catalyst that can transform their teams for the better.

Why having a service management framework matters

When I meet with development teams, I like to listen to their war stories and learn how the teams have evolved over time. They all repeat the same patterns in how they learned to deal with a wider context than just development and technical operations. Many haven’t heard of service management frameworks such as ITIL, or they don't understand how to apply the information that's available.

ITIL, a framework of best practices in the larger domain of IT service management, is technology- and platform-agnostic, which means it needs to be adapted to your organization's context, drivers, and desired outcomes.

Specifically, it should be adapted to the cadence and rituals of product management and development, alongside other DevOps techniques, so you can deliver technical and service (and service management) increments frequently. As with product management, there are benefits to quickly learning which service management techniques work and which don’t and to quickly learning what is valuable to your stakeholders and what to drop.

You can find plenty of literature on ITIL, including the core books and supplemental publications that talk about the iterative approach, with a focus on continuous improvement, as well as blog posts and papers by industry experts. 

Get a head start on service management

Customers pay for their applications and software, but they also expect you to provide a service that lets them continue to reap value from their digital assets. Product management and development teams that take ownership of the technical features they build must also include the services that their customers expect.

And while it is possible to come up with your own service management techniques, a best-practice framework such as ITIL will give you a great head start over your competition.

Want to know more about ITIL and DevOps? Post your questions and comments below. Or come meet me at DevOps Enterprise Summit London, where I'll be discussing this subject in depth.

DevOps Enterprise Summit: Experts share lessons learned
Topics: DevOpsIT Ops