Working data harder (1) - how and why we developed a Lean SDLC

To become faster and better, Access Worldpay has created a Lean SDLC that automates metrics and shares tools and knowledge.

Written by the Access Worldpay Team
08 September 2021

To provide our customers with a better, faster payments platform, we're optimizing how we use data to enhance our decision-making. This has led us to develop a version of Lean SDLC where we automate operational metrics and share tools and expertise more effectively. In the first of two articles, we explain what we're doing, and why.

We just knew we could be faster. Previously, our development teams worked separately from technical service owners, service transition teams and support teams. The result was endless, circular conversations between them about functional and non-functional priorities. Not only did this cause frustration, it also demanded time and effort that delayed our Time to Live.

The issue was exacerbated because Access Worldpay's platform uses a lot of micro-services that we've been building out rapidly. Such expansion promised to turn an unwieldy structure into one that would soon become truly unsustainable.

Build out better

This was the trigger that prompted us to develop a version of 'Lean SDLC'. Instead of implementing yet another organizational restructuring, we've tried to completely reimagine how we build our platform, based on our tribe's central principles of empowerment, efficiency and collaboration.

Our Lean SDLC has three interlocking components:

• Process: what does the new process need to look like?
• People: how can we transform people and improve teams to achieve what we want?
• Technology: what tools do we need to make this work?

Five key metrics

Although tailored to our specific needs, Lean SDLC borrows heavily from industry best-practice work by Google and other companies.¹ Drawing on seven years' worth of industry data, this work identified five key operational metrics:

• Lead time: how long do we take to build and release our code?
• Deploy frequency: we want to make rapid, safe changes, so how often do we deploy new code?
• Mean time to restore: when things break, how quickly can we restore service?
• Change fail percentage: our changes should not be causing problems so we need to focus on this metric.
• Availability: how available are services right now?

The industry research demonstrated that optimizing these five metrics through a prism of continuous service improvement doubled the chance of meeting your business objectives. This sparked our interest, particularly as data for all five metrics was already available to us, albeit imperfectly formatted and unreliably located, so time-consuming to compile.

The metrics, reloaded

A clear starting point, therefore, was to improve our process. Just as we've been improving use of customer-driven data, as explained in a companion article, we needed to do the same operationally. We created a Lean SDLC site that automatically collected the data behind some crucial metrics, including the five listed above. The aim was to make it quicker and easier for development teams to access the data and benefit from the insights offered, so that "we could pull some of that knowledge and experience out of the operations teams and into the development teams," says service owner Sophie Hirst.

The site includes several Lean SDLC techniques, such as continuous delivery, that cover the end-to-end service development lifecycle. Teams can drill down into each technique to see key behaviors and metrics for each one. "The idea is that displaying these techniques gives teams a better understanding of them and the underlying behaviors and metrics," says Sophie. "And there's also lots of extra support sitting behind all this, including some awesome videos."

Tools and tech

Alongside the Lean SDLC site is 'Lean Stack', our technology and tooling component, which provides a directory of essential tooling that we've already examined and tested and found to be fit for purpose.

By way of example, if a team needs to set up on-call alerts, Lean Stack provides a recommendation for which tool to use and explains how to set it up and how the alerts flow. "We're simply trying to remove blockers so it's easier for all our teams to go on this journey," says Sophie. "It's fine for a team to do something different, but they then have to do the all the legwork themselves."

Cross-cutting communities

The third cog is about people. Here, 'Lean Communities' helps us export knowledge and experience from centralized operations teams into development teams. It contains a number of online 'community practices' that cut across all the domains using Lean SDLC. Each community practice involves a combination of people, including an expert community leader who knows how things should work, other experts and interested parties, domain representatives, plus new members who are there to learn.

Lean Communities is an effective way of sharing operations expertise with development teams, and of enabling new teams to familiarize themselves with Lean SDLC very quickly. It also helps teams tackle difficulties quickly. For example, within the testing community somebody might be struggling with integration testing, Sophie explains: "They'll have a conversation within the community about what 'good' looks like and once they're in agreement, they'll document it so it's available for others."

Principles-based development

In summary, this is the version of Lean SDLC that we've developed for our teams. As mentioned earlier, throughout the process we've been guided by our tribe's core principles:

• Lean Communities exemplifies our collaborative approach.
• Lean Stack is a straightforward way of driving greater efficiencies in key areas, like tooling.
• Lean SDLC empowers development teams by providing quick and easy access to key metrics which they can use to inform their priorities and decisions.

A second article covers this third point in more detail. It explains how Lean SDLC is being used by development teams, discusses the impact it's having on our productivity and explains how we plan to improve it further.

¹The industry research can be found here. Our work also drew heavily upon the insights found within Accelerate: Building and Scaling High Performing Technology Organisations (Dr Nicole Forsgren, Jez Humble and Gene Kim).