Skip to main content Skip to footer

To compete with digital-native startups and “insurtechs” like Lemonade Insurance Co., which is wooing millennial renters with low paperwork and lightning-fast claims resolution, incumbent insurers are scrambling to deliver higher-value software, faster. To make this shift, insurers must create a “value-delivery factory” — that is, a streamlined, waste-free pipeline for rapidly delivering software with demonstrable business value.


Figure 1

Transitioning to a continuous delivery operating model is a major undertaking that requires modernizing the entire insurance value chain — from the front-end system of engagement through the system of record. To help insurers begin the process, we advise an incremental approach to building a value-delivery factory, with the four-step model detailed below.

Incremental journey

Before proceeding to the four steps, we must note the four dimensions of the continuous delivery model. In our engagements with insurers around the world, we’ve found that a successful transition to this model requires modernizing along these dimensions in parallel:

  • Teams and culture.
  • Process.
  • Engineering.
  • Platforms, including the data architecture.

Companies advance along each of these dimensions incrementally, starting with the simplest improvements and adding on. Tackling the new process, organization and supporting technology all at once is a recipe for disaster, because even small changes can have unexpected consequences. Therefore, we advise insurers to make small changes iteratively, evaluating their impact at each step.

It’s wise to start with a few carefully selected minimum viable products (MVPs) to build confidence, and then scale pragmatically from a base of demonstrated success. The idea is to mature along all four of the dimensions noted above at roughly the same pace, rather than going from zero to 60 on one dimension before tackling the next. For example, moving legacy applications to a modern cloud platform without also teaching teams to build a continuous delivery pipeline will deliver little if any business value.

Frequently assess whether changes have improved deployment frequency, lead-time to change, change failure rate and business value delivered. In its 2018 “State of DevOps Report,” DevOps Research and Assessment determined organizations that perform well against these metrics are twice as likely to exceed profitability, market share and productivity goals. If your changes don’t improve these metrics, change tactics and measure again.

It’s important to note that different teams in the same company will be working the following steps — and will likely progress at different paces, depending on their slice of the business value stream. For example, a team building a new cyber insurance product might rapidly progress through all four steps, while a team that’s evaluating an old policy administration system might decide after the first step (baselining) to extract the data and then retire the system.

Now, the steps to become a value-delivery factory:

1    Baselining

To conduct a baseline assessment, compare your software delivery performance to industry benchmarks. After establishing the baseline, set targets for the future state. The target, for example, might be to accelerate deployment frequency from months to minutes.

Next, identify the impediments to reaching the future state. Impediments that can hinder the need to deploy in minutes, for example, may include a lack of version control and work-in-progress limits, manual testing, a monolithic application architecture and poor job satisfaction.

2    Form pipeline teams

To get started with this step, form one or two agile pod teams comprised of six to eight members apiece; they will have end-to-end ownership of product delivery. Team members typically have expertise in product management, development, quality, the business domain and sometimes data.

Show these pods what “good” looks like in terms of team structure and culture, Lean/Agile processes, engineering practices and platforms. Provide basic training on modern processes (“Scrum”-style meetings, extreme programming, and the Lean Startup methodology) and modern software engineering practices such as build-measure-learn (BML), MVPs and an automated software development lifecycle.

Finally, strive to build a culture of continual experimentation. We’ve seen good results from “gamifying” the learning process with contests and rewards.

3    Build MVPs

Identify the first MVPs to deliver. It isn’t necessary to make an entire application cloud-native. Instead, ask which parts of the legacy application portfolio will provide the greatest business value if they’re made cloud-native. Measure value in terms of cost reduction, new policy sales, revenue per policyholder, average time to settle a claim, renewal/retention, and so on.

To tease out the value of existing software, we recommend using the value stream mapping methodology. Give priority to frequently modified applications, as microservices can be changed more quickly. Keep in mind that an application that costs more to migrate to the cloud, such as policy management, might also deliver the highest lift. Conversely, an application that costs less to migrate, such as compensation management, might deliver less lift.

4    Scale and optimize

To get started scaling the continuous delivery operating model across the company, have the initial pipeline teams transfer knowledge to new teams by working side by side on an MVP. The new teams can then train others until the entire organization has learned Agile processes and culture as well as modern engineering practices.

Next, the enterprise must work to continually improve along four key dimensions: culture and teams, process, engineering and platforms.

Finally, track the business value delivered by the new software. Measuring business value needs to become just as important as functional requirements. Writing code to capture business value metrics gives teams a solid basis to decide whether to pivot or persevere. By inserting a few lines of code, for example, the team can measure the effect of a new feature or interface on the number of people who click through to buy.

In conclusion, many insurers will find it helpful to work with an experienced partner to develop a backlog and coach the first several pods. We advise companies to start small; change their leadership mindset; enable teams to continuously learn; know what good looks like; measure what matters; build a community of engineering excellence; and continuously improve.

A successful transition to continuous delivery requires incremental modernization of teams and culture, process, engineering and platforms. Decide whether to pivot or persevere by continually monitoring the metrics that matter most to business success.

To find out more, read Continuous Delivery Operating Model for Insurers: Building a Software “Value Delivery Factory”, visit the Insurance section of our website, or contact us.