How to Fail Fast and Iterate Rapidly in a Regulated World – InApps Technology 2022

The world of agile software development is about experimentation and innovation. But how do you, a la Spotify, learn to fail faster but this time in a regulated environment? How can you iterate rapidly in the banking, healthcare or government spheres?

Nigel Wilson, general manager, Scott Logic

At the Agile Roundabout Meetup at the LendInvest offices in London, this is just the question Nigel Wilson and Rob Newsome of Scott Logic looked to answer.

Scott Logic is a U.K.-based software consultancy with 200 team members focused mainly in capital markets and financial services. To be sure, the company has learned a number of lessons in remaining agile in a regulatory environment.

Unique Challenges in Regulated Environments

Wilson delineates a regulated environment as any kind of industry or type of delivery of products or services where particular requirements come from outside the business. These impose external restrictions and functional and nonfunctional requirements for delivery.

“Essentially any industry where products or services are subject to requirements that originate from a stakeholder outside of the organization,” Wilson explained. Most often this is found in the finances, trade, security, energy and healthcare sectors.

With externally regulated software, the product owner becomes the go-between, working with the software team, any internal regulatory roles, and the external regulatory stakeholders.

In the typical fast-paced agile software environment, you set priorities that are first and foremost based on business value. That can be challenging when you continue to have the added barrier of not only making sure software is stable and secure, but also compliant.

So what exactly is agile? For Wilson, agile is valuing-creating software without documentation, which works to overcome the limitations of the waterfall project management model. In agile, you “work in a way that’s sustainable,” he said, and “team velocity sets the pace which we deliver.”

But he explained that in a regulatory environment, the regulatory body usually sets dates for projects to be met. For example, he said, “Banking is usually better at setting a requirement date than explaining it.” While those dates come with an expectation of a lot of evidence and documentation, they often don’t come with instructions on how to get there.

“From my experience agile actually helps you meet these requirements — the alternative is waterfall to meet it and hope it works,” he said referring to how agile-opposing waterfall project management can be so structured from the beginning that any alterations in the plan are prohibitively costly in time and money.

Scott Works went agile specifically because it allows them to work incrementally with the regulators and catch things as they go.

Agile Approaches to Compliancy

Wilson and Newsome offered their own experiential guidelines to not losing agility in your effort to be compliant.

Results Focused

Check off these bullets and figure out how to build them into the agile process, while always staying focused on that end game:

• get clarity on the goals
• determine how to demonstrate compliance
• define the acceptance criteria and how to test is
• incorporate the definition of “Done”

Be Extra Collaborative

Rob Newsome, head of development, Scott Logic

“Even regulators and creditors are human!” Wilson says that often developers and product owners put regulators on pedestals looking down on your organization to impose regulations, but he reminds us that “Regulators are more than ready to engage in dialogue.”

He argues that success comes when you treat these regulators as key stakeholders in your business and your agile process. He’s had this work especially well for security accreditation in the public space. It all comes down to one question:  How can we get to the point where there are no surprises?

Newsome, Scott Logic’s head of development, always works to get to know the security team from the get-go. By working with them from the start, “No you can’t do that. No, you can’t release that.” usually turns into easy acquiescence. Other teams, he said, have ignored the security unit and then eventually had to simply start the whole project over.

Newsome has found that at the Financial Conduct Authority in the UK, “they are a bit worried that in-house compliance people may be saying ‘no’ too often.” He pointed out that the regulatory authorities are actually quite open to talking, although not that many development teams are reaching out to them.

But success isn’t just about sucking up to these external regulators. Wilson pointed out that it’s the product owner’s job to get the team on board, making sure they understand the intent behind any regulation. This will bring about another important question: Are there alternative implementation approaches to get there?

Then, make sure both sides are involved in deciding how you will demonstrate incremental goals.

Follow Patterns, Like Sprints

This is where Wilson best argues that agile is indeed better-suited to a regulatory environment. While the traditional waterfall development model risks what he calls the “big bang at the end,” agile is well-suited to compliance as it naturally comes with incremental delivery. Agile comes with defined time chunks or “sprints” that can last anywhere from two weeks to a couple months.

You can incorporate a regulatory validation process into your sprint activity. This way, you aren’t risking waiting until the end of a waterfall only to find out you can’t release your software because it isn’t compliant after all.

Agile has you releasing much more frequently so your stakeholders calm down.

Flex the Boundary; Get Creative.

Boundaries are where the team at Scott Logic gets a little creative.

“The thing that needs to be compliant is your whole product or service,” Wilson explained. “We’ve got to be compliant in terms of the full service but we don’t have to necessarily do that through technology.”

He says sometimes it’s better to automate what you can and then do manual workarounds, as a way to get compliant before the product is ready.

Collapse Those Silos!

The larger a business is, the larger both the physical and organizational silos seem to become. If you are an organization that has an internal regulatory department, you need to bring them in early on.

Regulatory requirements need to be built into the project scope from Day One. You’ve got to learn what these internal stakeholders need and then build it all in as requirements from the get-go. This also makes sure that the product owner has a lot of compliance knowledge that she can then pass onto the team, who must be, at minimum, familiar with the regulations.

Wilson also gave the great advice to network within your industry. He pointed out that by sharing challenges, you can also share solutions: “Regulation outside the body doesn’t just affect you but the whole industry.”

Work to be Continuously Compliant

There are three reminders that Nelson offers in order to stay compliant:

1. Build Continuous Inspection into your Continuous Delivery. You should build compliance testing into your continuous delivery and automate it as much as you can. It’s much easier to remain compliant when it’s a natural part of your process.
2. Learn and optimize. It’s important to keep up to date with the broader community — learn from what others are doing in your regulatory environment. This is a great way to keep aware of what’s coming up around non-compliance, keep you aware of edge cases that maybe you haven’t tested for yet, and to keep you alert for intent, as well as ways to refactor and improve.
3. Look to the future. Whatever product or service you’re building, you’ll have a roadmap for that and a product backlog.

Feature image: Washington D.C., Library of Congress.