#91-Agile With Regulator Relationships

How can we best ensure compliance with the regulators that govern us?  It often seems like they compel us to behave in non-agile ways, so if we seek to be agile, how can we resolve this.  That's what this episode is about.

Transcript

Agile With Regulator Relationships 

Last week I discussed the fact that every process exists in the context of the inputs and outputs with and from other organizations that are involved in the creation of products. I focused on the vendor relationships specifically, but there are other external entities that can also impede our ability to be agile if we do not deal with them properly. 

Another example of this are the regulators that we are accountable to, usually from some governmental or industry board that has legal jurisdiction over the things that we make and sell. 

The problem can be very similar to the vendor relationship in that if we are operating in an agile fashion which thrives on speed, iteration, validation, and early correction resulting in frequent change, regulators are associated with formality, risk-aversion, extensive documentation, and adherence to fixed protocols.

Especially in industries that are heavily regulated, it is sometimes thought that agile processes will be too hampered by the regulatory regimes that they operate within, and that because of this we cannot gain the benefits of the agile mindset. 

As with many of the solutions I suggest here, this problem can be ameliorated starting with a shift in your thinking. Rather than considering regulators to be an obstacle that must be overcome, you should consider them to be valuable stakeholders to your project. 

In my agile tip number 25, “Enumerate Your Stakeholders”, I talked about the importance of spending time in the inception phase of any project to identify and make visible a list of stakeholders that should be included in the various planning that we do. If you missed that episode it is available in the backlog, but in brief I’ll begin by defining what is stakeholder is.

A stakeholder is any person or entity about which two things are true:

1) They are empowered to issue requirements that must be adhered to, or put another way, they have expectations of the product that cannot be denied.

2) They are a source for validation in that they can tell us from their perspective whether an aspect of the product is correct or not, allowing us to make adjustments and avoid waste and delays. 

If you consider regulators to be critical external stakeholders, then you know that you have to involve them early in your process so that you can build compliance into it. Regulators should be engaged with proactively - invite questions, ask for clarity on their expectations, allow them to offer alternatives, and in general create a high degree of transparency with them which will build trust and reduce friction. 

Do not make the mistake of assuming that compliance will be part of the end game of development. Compliance requirements should be treated like any requirements: they should exist in the product backlog, broken down into clear testable stories that are created collaboratively. Ideally that collaboration should include the regulators themselves. 

You should treat regulators as you would any stakeholder meaning that sprint reviews, acceptance criteria, and the definition of done should all include regulatory engagement. Documentation should not be created to comply but rather to inform, and it should be an ongoing process throughout the development of the product.  As always, I think acceptance tests are the best way to accomplish this.

There are two problems that can occur when you try to do this: Regulators may not be available to you on a frequent-enough basis to engage with them in this way, and they may not understand or speak the specialized language of your problem domain. 

If either or both of these problems are impeding you, then you need to establish an individual or group within your organization that can represent the viewpoint of the regulatory regime that you operate under and that also understands the nature of your work and the specialized terminology that you use to communicate. This person could be a product owner, an agile coach, or a person specifically tasked with this responsibility. Remember that validation must be available constantly and frequently and so very similarly to having someone on your team that understands the end user perspective, you need someone who understands the regulatory perspective as well. 

Next week I’ll discuss a similar challenge, namely how an agile team can operate effectively inside a waterfall organization.  Stay tuned!