How to build agility into a regulated project?


(Heather) #1

Prompted by this tweet from Jean Ann Harrison

Based on my own experience so far in FDA regulated companies it is really difficult to have agile practices in those environments. Equally waterfall based approaches can end up costing a lot of money when they fail at the end of the process. I’ve worked on a project where it was waterfall based and the deadline was forever being pushed later and later due to complications that could not have been foreseen. More recently I worked on a project where we had sprints and testing throughout but the release of the product was more of a waterfall type with a deadline in X months to deliver to customers.

Are there ways to build agility into regulated testing projects?

Are there any things that you have encountered that you would forewarn people about?


Has Continuous Deployment Become a New Worst Practice?
(Kent) #2

I work in a heavily regulated space as. I’d agree it’s a challenge.

We have agile elements to our process, but loosely fixed delivery dates. I think the fixed delivery is as much an artifact of the domain as due to challenges in the development process. Regulated customers have to do a great deal of due diligence to validate a system for use, in addition to what is done in the SDLC.

That being said, I think there are things you can do to maintain agility in the regulated environment without being waterfall. Even if you have a fixed delivery date, like all agile projects, scope and priority may shift during the development cycle, so you need to be adaptable from the start.

  • Test throughout the lifecycle. (a given)
  • Build your validation in small enough components that if a piece gets de-scoped, it doesn’t impact your entire test suite (that goes for both manual and automated checks)
  • Keep your stories small
  • Plan for different regulatory requirements. (All of our raw documentation is in XML, which means we can post process it into different formats via XSLT)

Most of those are pretty standard agile concepts, but I think they become even more important in the regulated space.
The biggest challenge/mistake I’ve seen is orgs being afraid to build their documentation out until the end because ‘things may change’. That leads to a long tail of not much productivity for the team.

Best of luck.


(Heather) #3

I’ve seen the opposite of this where a lot of documentation was done up front and a lot of the teams time was spent on change controls for the documentation.

I guess you have to find the balance with the right kind of documentation through trial and error. Also the person writing the documentation and the target audience for it needs to be taken into consideration I think but often it seems to be left to the person who appears to have the most time and may not necessarily understand the reason or audience for the document. Perhaps this is not always the case but it has been my experience so far.


(Kent) #4

I find the different workflows people need to use really interesting. Historically, our test documentation has not gone through the formal approval process until near the end of a project lifecycle. That worked for us, because our official validation is done near the end too. Change controls were minimized, but it did have the end result that all execution for ‘validation’ had to be done at the end as well.

We’ve started to mitigate that long tail by executing most of our low-level verification via automation, with extensive documentation of the execution.
High level validation is still done manually for the business needs, but the test cycle for that can be comparatively quick with low level verification done in an automated fashion.

That way, if we change scope (cut features) late in the dev cycle, it’s just a matter of excluding those tests from validation. We still have the documentation for those features, they just don’t get executed or submitted for approval. That’s where it gets important to keep things compartmentalized.

Embracing the V-model has actually strangely allowed us to be more efficient.


(Heather) #5

A follow on from that, I had a discussion with JeanAnn during the week about how code can be documented. Do you include code comments (including comments in automation code) under the umbrella of documentation or is it something else?


(Kent) #6

Our automation code is pretty much self documenting (more below). So, the automation is definitely included in the umbrella of documentation.

All of our automation logic is abstracted into keywords that are readable by business users. Things like:
Element Text Should Be [locator] [expectedtext]
Click Link [LinkText]

Beyond that, we abstract the granular checks into higher level keywords. So, a test at the highest level will be similar to gherkin.
A made up example would be:

  • Log in as Administrator User
  • Change Read Only User to Write User
  • Log out
  • Log in as Read Only User
  • Make Change to Data
  • Log out

Every one of those keywords may include a bunch of steps (although they still use pretty readable language). For some of our business users, we provide the documentation at this very highest level.
For others, we might provide the documentation at a slightly lower level.

For our official validation documentation, we include full execution results, which include the detail down to the lowest level keyword (i.e. Element Text Should Be) along with the results.
That’s where having our results in xml has been really valuable, because we generate all the different formats off a single source file.


(Heather) #7

Interesting. By that description I’ve been accidentally building documentation into my automation code quite well then :slight_smile: obviously there’s places I can improve but it’s great to know I’m not doing a terrible job. Thank you :slight_smile:


(Heather) #8

An interesting blog post from James Christie related to this

@mb1 also suggested I look at the FDA guidance for least burdensome


(Paul) #9

I’m not sure it is just about externally regulated audit. In a recent project I was asked to submit a complete set of written test cases AND a requirements testability matrix before the start of testing to BAs for approval before the start of every test cycle. In the project I am on now I have to submit written test cases for approval by the senior finance manager and the BA for every use case I test as a precursor to testing. It was a slow process, although not as slow as getting our UAT test plan approved, which required negotiation and formal signoff from tens of stakeholders in different departments.

Apparently (in the former case) this was because test cases along with defects raised are seen as the “deliverables” of the test team and approval of requirements and test coverage is a business and internal audit process. It’s the way testing goes in the financial services industry apparently. For someone who prefers exploratory to pre-scripted tests, I found it unsettling and would struggle to fit that into a fast and agile testing approach, however my manager and I couldn’t change their mind.


(Jesper) #10

This one is interesting, as it is a guidance document by a industry organisation. The regulated industries usually follows Good Industry Practice described by interest organisations (aka industry best practices), so this is a an interesting development.


(James ) #11

This gets me riled. Internal audit processes should apply only to the work of internal audit. Auditors should never dictate the processes in other areas. Their job is to review the processes, controls and management. The reason auditors want something they can count and check is that it makes their job easier. It turns audit from a difficult and valuable job into an easy and worthless one.
In this blog I refer to the problem of auditors building a cosy consensus with auditees. The auditees produce something that the auditors can check easily, and in turn the auditors give a glowing report.