Introduction. 

Are you skeptical or convinced about the compatibility of agile IT system implementation and Computer System Validation (CSV)? You didn’t make up your mind yet? Or are you just hungry for information? In any case, if you are looking for an opinion about when and how to apply an agile approach (or Scrum – used interchangeably, which does not limit agile only to Scrum) on regulated projects, keep reading. To make the most out of this article however, you should have basic project management, agile and GxP or CSV knowledge. 

In this article, I show how to apply Scrum on projects where the technical solution must undergo CSV (see the “How to Scrum?” section). As such, I touch on how Scrum artefacts do match to the validation documentation. Before talking about how to apply Scrum however, I start by sharing my thoughts on when to apply Scrum (see the “When to Scrum?” section). This agile framework is so much more than a way of working. It is also a way of thinking. Understanding this is key to agile implementations. 

When to Scrum? 

According to Shenhar and Dvir (“Reinventing Project Management” by Aaron Shenhar and Dov Dvir), iterative approaches such as Scrum are best suited to deliver good results in situations of great uncertainty. Therefore, it is not a coincidence that Scrum first picked up for software development projects. One of the main characteristics of such uncertain environments is the inability to define user requirements from the start. Think about trying to hit a moving target in a highly innovative, technology driven, fast spinning environment. 

Nowadays, project teams explore and apply Scrum in traditional settings as well. They use Scrum as standalone or as a substitute to the waterfall approach in the context of project management methodologies such as PMBOK. In any case, it is used with the hope to solve issues that the traditional project management practices poorly address. How many of you witnessed or heard of successful UATs to discover only after the Go-Live that the system does not really live up to the end users’ expectations? Or of implementations that took so long that by the time they were finished the technology was outdated? While Scrum is not the solution for everything, I believe it can successfully address such issues. 

When to Scrum? Whenever you want to place extra focus on user engagement and satisfaction; need an iterative approach to define the user requirements or build the system; try to avoid a copy-paste situation when replacing a system; or avoid ending up with unclear, technically-oriented user requirements; improve transparency and collaboration on the project; or provide your team with a fresh way of thinking. All are good reasons to explore Scrum. One advice: don’t try it unless you understand and value its’s foundation – the Scrum way of thinking. 

The North Star. 

Software implementation projects are usually an orchestration of internal employees and externals coming from various vendors (e.g. software providers, system integrators and other vendors). You must have them all engaged in one boat to make a successful journey towards your destination. I will use this analogy to explain what the “way of thinking” and the “way of working” are. 

While the crew is the project team, the boat represents the resources at hand. The chosen journey (including the map, course and navigation tools) is the project approach, or the way of working. And the destination could be anything from launching an App to implementing an eDMS or ERP system to satisfy a given need. In other words, you might have one captain with a crew or a self-organized crew with a facilitator in a luxury yacht or a rowing boat taking the route A, B or C to reach a moving platform or an island. 

There is however a fifth element that often gets insufficient attention. Each organization, each department, each team have a unique culture. The interactions inside the crew and among crew members and others represent the project culture, or the way of thinking. All these five elements (team, resources, approach – way or working, scope and culture – way of thinking) are blended on a project to satisfy a given need and can take different shapes during a project. The constant is the business need that the project is to satisfy. Think of this need as the North Star of a project. 

Lack of spark. 

When choosing between agile or classical (used interchangeably with waterfall in this article) implementations, the way of working or the project approach is the factor that can be influenced most directly among the five elements described above. 

Project management methodologies, such as PMBOK, provide a set of processes, terminologies and guidelines viewed as standard practices across the project management industry. These standard practices can provide the foundation for the way of working on a project. The waterfall and agile frameworks go more into the nitty gritty details of the team dynamics on a project: how the teams should be organized in terms of structure, deliverables and hand-over points. These methodologies and frameworks, even though not necessarily, can complement each other. While I am not trying to compare apples with oranges, there is one thing that sets Scrum apart. 

The Scrum framework provides project teams not only with a way of working, but also with a way of thinking. That means with Scrum not only the approach, but also the culture element is heavily influenced. What sparks a project, motivates and unites a team if not its’ culture? 

Fireworks. 

The Scrum way of thinking is what I like most about this framework. It is intuitive. It is social. It is user obsessed. When projects struggle with Scrum, too much focus is placed on readjusting the way of working. But isn’t the effect taken for the cause? Without the Scrum way of thinking, agile is faked. 

A team truly lives up to the Scrum way of thinking when it is self-organized but also empowered, self-regulated but also transparent, results oriented but also failure-friendly. Above all, a Scrum team is user-focused. This culture is supported by the Scrum artefacts, events and team structure. Contrary to various believes, Scrum is not a laissez fair approach. It allows you to tap into the unknown in an organized, team-oriented manner. 

When fresh to agile, changing a team’s culture takes time and patience. And it is more challenging to do so in isolation, on a given project, in a company that does not implement the agile thinking top-down, or on complex projects where multiple vendors are involved. Yes, it is hard work. Yet, it is totally worth it. 

How to Scrum? 

You have good reasons to apply an agile approach on your GxP governed project? The main characteristic of such environments is that documentation is required before action. This documentation is fixed by your validation framework and there is no way around it. Plus, everything must be done in a waterfall sequence (DEV to VAL to PROD). That is quite the opposite from agile. How should you do it, how to Scrum?  

As I present below, go agile in DEV. Switch to waterfall once you go to VAL and continue to PROD. In other words, when you plan such a project, focus your DEV activity on the development/ configuration of the system or app. Focus your VAL and PROD activities on the roll-out of the system or app. The scope of DEV is the unofficial system or app sign-off by your key users. The scope of VAL is the official sign-off by your key user community and the Steering Committee. The scope of PROD is the formal hand-over to your end user community. 

You could do that in different ways. Start with a Proof of Concept (PoC). If you like the result, continue with the full-scale system implementation (system development/configuration and roll-out). Or, in case your organization and key users know well what they want, go directly into the system implementation. Whether you decide to roll out in clusters/ steps or as a big bang, all the same. DEV is your only agile ground. 

I do not recommend applying an agile approach in VAL and PROD during the project lifespan. This would overheat your change management process and your team. Incremental releases to production after each Sprint will have the same effect. Unlike the case of unregulated environments, the documentation required in case of regulated environment makes such an ambition very challenging. Here is why. 

Mix and Match. 

In heavily regulated industries, such as pharmaceuticals, GxP is a collection of quality standards to assure safety and efficacy of products for the patient through assuring high quality of e.g. laboratory, manufacturing or other processes. IT systems used to support such processes must undergo CSV. This means, the solution is assessed through two lenses: validation (user data and application) and qualification (infrastructure and platform). As applying a waterfall or an agile approach has to do with how an app or system is being built and tested, I will focus on the validation side and leave qualification out of this discussion. 

Figure 1 below shows where the agile approach could fit in the GxP governed projects. Such a project typically goes through the following milestones: Go-to-VAL, Go-to-PROD and Go-Live. It also shows the required documentation, which can vary from company to company depending on their validation framework, along the standard V-Model. These documents must be prepared, reviewed and signed by the specified experts in a given order. Once a document is signed, it can be changed only through the change management process. While it is a lot of work, this is meant to ensure traceability and high quality on a project. 

As already mentioned, I believe it makes sense to Scrum only in DEV. Therefore, I will further focus on the DEV related documents. How do they match with the Scrum artefacts (Product Backlog, Scrum Backlog, Burndown Chart, Definition of Done and Product Increment)? The only case where you have a one-on-one translation is the Product Increment: finished pieces of e.g. the system or app you are implementing. There is no direct equivalent for the Burndown Chart. To find the equivalent of the Product and Scrum Backlogs, and the Definition of Done, let’s have a closer look at the validation documentation. 

The User Requirement Specification could be viewed as a Product Backlog and Scrum Backlog, while a user requirement could be matched to a user story. There is no per se match for the Definition of Done but it can be related to the Requirements Traceability Matrix and the Specifications. While there is only one Definition of Done (which can evolve during a project lifespan) for all use stories, it drives the realization of each story in specific ways. How a user story or requirement is being implemented is documented in the Requirements Traceability Matrix and the Specification documentation. 

On agile projects you will come across other artefacts (outside of the Scrum framework) such as the Work Breakdown Structure, Acceptance Criteria, Definition of Ready, Story Mapping etc. Having  clear definitions of the artefacts from the start and a common interpretation within your team will reduce potential frictions and misunderstandings. 

Whatever solution you choose, I recommend taking an iterative approach not only to the way you work on agile projects but also to the way you write validation documents. In any case, a dedicated validation expert with Scrum knowledge would be a good asset to your team. And remember, whether you chose agile or waterfall, the name and the structure of the documents you create on GxP governed projects must comply with your validation framework. When applying Scrum, the artefacts must get different names and a different structure, but their essence can be preserved. 

Back to the DEV related documents, you might choose to start the project work with an official (that means signed) User Requirements Specification and, following your change management process, update it before signing the Design Review document. Or, while your team iteratively works, you might want to keep all the specification documents (including User Requirements Specification) open until you hit the Design Review meetings during which the required documents (in this case all the specifications, the Requirements Traceability Matrix and the Design Review) are signed. Which way you choose is a matter of taste and navigation of company politics as framed by the company validation framework. 

Final Touch. 

As I mentioned at the beginning of this article, IT implementation projects are an orchestration of internal employees and externals coming from various providers. You must have them all in one boat to have a successful agile project. To bring the best out of a team trained in Scrum, there are two things I would pay extra attention to: team composition and the resources they have at hand. 

A Scrum Team is composed of a Scrum Master, a Product Owner and several Developers. On GxP governed projects you must add the competencies of a Quality Assurance and a Validation Owner to the team. Especially on international projects with external involvement, it is often the case that your team is spread around the globe. Thanks to modern collaboration tools, there are ways to work around it. That means, team members dialing into your Daily Scrum from e.g. Germany, UK, US and India. The more international the project is, the more countries and time zones will be added to the list. There is extra complexity to manage around the Scrum events in such cases. Therefore, besides carefully choosing your team, you should also consider what Scrum events would best fit the given situation. 

Furthermore, there are additional challenges due to patchwork teams. The final decision about which approach to take on a project is usually taken by the project manager or the employees working for the project sponsor or owner. What if there are externals e.g. Developers/ Configuration Specialists on the project that usually deliver following the classical approach? What if you train them in Scrum but their employer’s processes hinder agility? Their loyalty is split between your company as a project provider and their employer. One thing for sure, your team is there to build the system or app you desire, not to do politics. 

And last but not least, let’s have a look at the resources the team has at hand. Scrum works best when a team is fully dedicated to a project. But can such a team be functional with limited resources? The DEV environment is one of your project resources. The process know-how is another example of a project resource. If your DEV environment is too slow or the Developers must wait for days to get the input they need from your key users, you would have trouble to be truly agile. You can have a user obsessed agile project only by making these users available to the team, right? 

Conclusion. 

While not fully compatible, Scrum and CSV have the same goal on a project: improve the delivery quality for the end users. Scrum can significantly reduce validation efforts in VAL and PROD environments by minimizing the risk of late scope changes. A bonus effect of the early engagement of your key users, when building the IT solution in the DEV environment, is the improved user satisfaction by better meeting the expectations of your key and end users (assuming the key users are representative to your end user community). 

Furthermore, Scrum benefits not only your users, but also the project team by minimizing the waste that can translate in painful documentation updates as your Go-Live approaches. Thanks to its’ events (Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective), Scrum improves transparency within the team and facilitates better understanding of the project progress. This keeps your risks in check, reduces the probability of issues and escalations occurring on the project and gives you better visibility for planning your communication or VAL and PROD timelines. Once again, agile is no excuse for ambiguity or scope creep. By correctly applying the Scrum ways of thinking and working, you position your project for success. 

As a project manager, the question that I have on my mind during a system implementation project is the following: How do we, as a team, deliver the solution that the users want with minimal waste in optimal time? The answer to this question might differ from case to case and person to person. Bottomline, you must find the right balance for each project by applying an agile, or a waterfall, or a hybrid approach. 

Finally, projects come and go. What remain behind are stories. 
If you want to hear the story about how we scrummed on one of my projects, please register to receive an exclusive access to my follow up article

Agile in GxP CSV Environments - The Use Case