The CSV and SDLC Landscape: What We're Seeing
We are currently at a place in the evolution of CSV where change has been called for for some time, and for many organizations that have not yet embraced those changes, the pressures and drivers are mounting. With increased demands from the business and growing needs to adopt - at least in some capacity - digital transformation, and agile tools and methodologies, quality and validation teams are being forced to adapt - and that’s not a bad thing.
Aside from staying up to speed on industry trends, requirements, and updates from a broader perspective, we are also in the fortunate position to engage with a number of clients of various sizes and maturity levels. This frequent engagement with real-world perspective and feedback allows us to formulate some good insights on the practical application of implementing modernization strategies within our clients, as well as some of the more common obstacles that teams may face as they go through these journeys.
As a result of these CSV improvement and modernization initiatives, we have been able to identify a few common themes and hold-ups that I thought would be good to share with our audience as it relates to the current state of CSV for many organizations, and the increasing push around hybrid and agile adoption (and let's not forget about the shift to CSA).
Transitioning to Agile While Anchored in Waterfall
Just about every organization that we engage with has some type of agile initiative. How broad-reaching that initiative is, or to what extent they will “go agile” differs from team to team as use cases and requirements certainly vary. There may also be areas where agile doesn’t make sense, so building out some type of hybrid framework may make more sense. Regardless, there is some level of agile adoption that is looking to be implemented, but there are some common roadblocks. Particularly around what we’ll call process or technical debt that has been built up over the last 10-15 years in waterfall-based processes and tools.
This technical and process debt that has been built up, particularly around large, enterprise systems like SAP, for example, can make this transition difficult. If an organization has 10-15 years of managing and testing these systems with tools and processes that are more waterfall or legacy-based, a strategy has to be put in place to move all that forward. In a regulated environment, it is not as easy as simply plugging in some new tools, training your team on a new process, and then getting rolling. There needs to be an effective strategy and roadmap put in place to migrate all that data effectively and to transition that technical and process debt to new tools, new methodologies, and new approaches.
Addressing Validation in an Agile Process
To expand on the technical and process debt, this also includes some debt around traditional, document-based validation. As teams are looking to adopt agile processes and tools, we really shouldn’t be looking to overlay traditional validation practices onto those tools and processes as they really are not supportive of an agile framework. In fact, document-based validation (whether paper or electronic) is simply disruptive and extraneous when grafted into an agile workflow, and it will drastically limit the efficacy, quality, and desired outcomes of tools and processes that are meant to support more iterative, nimble, and faster delivery.
In order to support this, a shift in mindset and approach to validation really needs to be embraced. In this transition, processes and tools need to be put in place to support and enable validation deliverables to be achieved and captured as a byproduct or natural outcome of the tools and processes that are stood up to support an agile or even hybrid transformation. What teams need to avoid as they undergo this transition, is trying to recreate traditional documentation.
Integrated Toolset that Supports Initiatives and Vision
What we often see is various teams across an organization are at different phases of this type of digital transformation or agile transition when in order to get the best results, standardization to some degree is required. IT, Validation, QA, Application Owners, etc, all need to be on the same page to most effectively support the business and achieve business objectives. If tools and processes vary from team to team, or application type to application type, you end up with fragmented and siloed activities with disparate processes. From an overall compliance standpoint, this leaves the door wide open for error and certainly makes traceability and audit submissions very challenging.
Key stakeholders across the SDLC need to come together to put a strategy place so that an integrated toolset can be utilized to support some type of standardization across the SDLC.
Identifying Tool Function and Optimized Use Case
Similar to above where we talk about seeing fragmented use of tools and processes across multiple teams in an organization, often tools are being used without identifying and implementing them for their best use case, or how their use could be better maximized across the enterprise vs relegated to one team or one application area.
Let’s take Jira, for example, since that is such a heavily utilized tool and is likely also being used within your organization (and is also often used in a very fragmented way before being deployed across an enterprise). People may be using it to create user stories as requirements and then signing off on those, but it may be limited to one group or one team within the organization. Is that really the best use of that solution? Is that really the best way to optimize the benefits of that tool?
Stepping back and taking a holistic view of the tools that are owned across the SDLC and how teams are using them can help begin to formulate a roadmap on how to better maximize the investments that have made in these tools. In doing so, we can begin to utilize them in a more strategic, enterprise deployment which in turn will support greater standardization and yield greater results.
Changing of the Guard
Okay, so this isn’t entirely a changing of the guard, but what it is referring to is a much more mixed bag of personnel with different backgrounds and varied approaches to SDLC practices. What we see more and more is sets of people across the organization at different maturity levels with different skill sets coming from different industries. There might be people coming from manufacturing or labs that come with a QA background based in GxP or GMP, but then you might have other folks coming from outside the industry looking to bring in new agile process and technology skills that might not yet be well adopted in our industry.
These types of different approaches and different backgrounds can sometimes end up at odds with each other, but it’s crucial that each side come together to best understand what can be taken from each to be best applied for the organization and business goals. We need to find a way to balance compliance and validation requirements with the need to introduce new tools and methodologies so we can adequately modernize our SDLC tools and practices while more effectively achieving our compliance requirements.
All of these factors need to be accounted for and taken into consideration so that we in Life Sciences can work together with our teams to drive effective change. The industry and the times are certainly calling for evolution in validation and SDLC practices, and communication coupled with effective strategy is a key component to successfully getting there. The technology is there, the process is there, the expertise is there. Now it’s just a matter of putting it all together, maybe by starting in some pilot application areas, and driving standardization across the organization from both the compliance side and the SDLC side.
If this is a topic that you are interested in pursuing further, a great place to start is with a Life Sciences oriented solution bundle. We are hosting a webinar on July 30th to discuss a bundle that ourselves and Tricentis have put together to bring Agile testing with qTest and CSV/CSA together with VERA hosted on our qualified cloud platform, Helios. It's titled "Purpose-Built SaaS: Agile Testing and Qualified Cloud". Click the link below to register!
Jason Secola manages content marketing and channel activities at Tx3 Services and has been with the company since 2016. Jason began working with the larger portion of the existing Tx3 team dating back to 2007 when he got his first start in the world of application testing and later began a focus on testing in a regulated environment. He currently resides near Sacramento, CA.
Jason Secola manages content marketing and channel activities at Tx3 Services and has been with the company since 2016. Jason began working with the larger portion of the existing Tx3 team dating back to 2007 when he got his first start in the world of application testing and later began a focus on testing in a regulated environment. He currently resides near Sacramento, CA.View all posts by Jason Secola