How process + tools + culture = organizational victory

[#1]

 

These are exciting times to serve the life sciences sector - thanks to technological advances, innovations abound and progress marches on at a lightning-fast clip. Working with a wide variety of organizations, @Rina Nir from Radbee sees two very different types of teams searching for an answer to the same fundamental question: "How do I best do Agile and still comply with regulations?" (For example, ISO-13485, GAMP® 5, etc.)

On one side there are traditional pharmaceutical companies. These companies have established ways to create software and have the manpower, capacity, knowledge, and procedures to manage compliant software systems. Still, there are significant inefficiencies related to time, effort and budget in doing business as usual. Given the copious benefits of both Agile and DevOps, as well as the ever-growing recognition of their efficacy, many pharmaceutical companies have realized they can no longer continue doing things the old way. For them, the key question is: "How do we continue to be compliant, but also adopt Agile methodologies?"

On the other side, there is a flood of young, highly successful companies who have been developing great software in Agile methods outside the scope of regulated software. (Rina is looking at you, ahem, health and fitness apps that shall remain nameless). These companies are extending their reach and moving into new territories which now includes operating in regulated spaces. These teams may have mastered Agile, but for them, the question is: "How can we continue to be Agile, but also be compliant?"

As with any organizational change, making it happen depends on the perfect blend of process, tools, and culture. Here's Rina's take on how to make this equation work! 

Process: Extending Agile practices to support the requirements of GCP and medical devices regulations

There is no way around it: GCP, FDA Quality System Regulation, and ISO-13485 each impact how you do Agile. It's worth acknowledging this fact and making the most of it. These are my top three observations about how Agile in life sciences is different:

1. "Working software over comprehensive documentation" is not applicable to this domain.Comprehensive documentation is essential, and there is no way around it. The good news is that with the right tooling and practices, the burden of generating the required documentation can be streamlined. Moreover, the need for comprehensive documentation can be aligned with Business-Driven Development (BDD) and other state-of-the-art practices. This may make the transition more easily accepted and implemented by teams who previously have had less regard for documentation.
2. A story is not a requirement specification: Typically, the Agile story is focused on an additional feature or a modification to an existing feature. As the product evolves, stories describe the small changes that are introduced throughout the development cycle. A specification of a product in a given release version provides the description of the feature at that particular time. This is not to say that a story cannot also be a specification – it can be, but it certainly is not always the case. As a product matures, and each version represents an incremental advance, a story becomes less likely to be a specification. I have seen teams that have regarded their stories as specifications of the software, which is not a sustainable approach over time. It's a form of technical debt you do not want to have. (For more on this topic, click here)

1. A comprehensive Definition of Done is key to success: As you need to have all the design specifications in place for the release, it is vital to not leave the update of these specifications as an afterthought of the sprint but instead consider it an integral part of the story work. Include in the Definition of Done the update of the specifications to reflect the story impact on user requirements, functional specifications, risk elements, etc. The benefits of this approach are:

1. It provides a more realistic measure of the sprint velocity, which is a key reason to agree on a Definition of Done and your plan as a whole.
2. There's less risk of release delay due to incomplete documentation.
3. It also aligns better with a short release cycle and frequent releases.

Tools

Tools can be hugely helpful in reducing the burden of compliance, particularly in the following areas:

1. Generating the traceability matrices: To those who are still using Excel and Word to generate the traceability matrices, I say this: there is hope out there. With the correct tools in place, you can have release documentation only "one click away." The key is to maintain the traceability elements (i.e. user requirements, risks, etc.) in Jira, and use Jira links to represent the traceability. You can then visualize the traceability in Jira and also export your release documentation from Jira. While this does require quite a significant configuration work in Jira and a use of Marketplace apps, the benefits far outweigh the investment. The following are some of my go-to apps to use in this context:

1. Structure for JIRA easily allows you to visualize traceability in Jira.
2. Xray is a test management plugin, which also provides some reports to visualize traceability.
3. PDF View enables the export of any combination of Jira information in a layout that makes it easy for FDA inspectors to digest.
4. Easylinks for Jira is a (free!) marketplace app, which is awesome in standardizing how different issue types are linked.

1. The software quality control process: This can be made significantly easier with Bitbucket, i.e. pull requests. Bitbucket can also generate the records required for future inspections.
2. Creating a solid Continuous Integration setup: This includes comprehensive coverage of automated tests and code quality control and is overall useful for the creation of good software, regardless of whether or not it's regulated.

Structure for Jira visualizes traceability matrices so that it's easy to keep your traceability during the development.

Culture

No matter if you are changing from waterfall to Agile, or from non-regulated to regulated, a culture change is required. As it goes, this is the aspect that typically is hardest and slowest. My two cents on this kind of shift:

1. There's no "one size fits all" for change: The bottom line is that it will take time for your organization to develop the best methodology that works for all involved parties. The transition has to be gradual, and taking baby steps in the right direction are better than trying to make such a seismic shift all at once.
2. A high level of discipline is necessary: What is common to regulatory compliance and to Agile alike is there's no room for sloppiness. While some people may think that Agile preaches less process, in reality, it is very structured and includes some widely adopted ceremonies. Looking at Agile through this lens may help you and others in your organization become more open to the Agile approach. For example, consider making retrospectives part of your quality control process.

Contrary to popular opinion, being both Agile and compliant is not only possible, it's preferable. Rather than look at it as if one side slows down the other when you see both processes as complementary, you get a clearer picture of what you were striving for in the first place: organization-wide victory.