Agile methods like Scrum, Unified Process, and RAD are increasingly becoming the tools of choice in R&D, especially when there is a high degree of uncertainty regarding viable solutions. This uncertainty is typically seen in complex projects where the technology is still unknown and the requirements are still notably far from an agreement. Contrary to that, the traditional waterfall approach is applied for projects where the problem domain is well understood and the solution is an incremental evolution based on the existing solution (see figure 1). 

However, in regulated industries, product development has to fulfill certain industrial standards, regulations, or norms regardless of the project type, and these industrial regulations tend to get increasingly complex as well as country specific in each industry. 

Common industry examples are the homologation standards in the automotive industry and the new European Rail Traffic Management System (ERTMS) that applies changes to many railway systems and their trackside equipment and operation systems. Thorough documentation is indispensable for the purpose of obtaining product authorization, especially when collaborating. Good documentation enables handing over a clear scope with defined requirements to suppliers or partners. 

So, how do companies ensure that the content in the documents for authorization or for suppliers is complete, accurate, and fit for its intended use? 

If companies use the traditional V-model, the documentation and specification are part of the requirements and verification axis. That means companies verify the content against regulatory requirements in a designated phase. Some regulatory requirements even necessitate the validation, verification, documentation, formal assessment, or an established protocol to prove the quality of a product or system, e.g., Medical Device Regulation 2017/745. 

With an agile development approach, this is not mandatory or planned and is even contradictory to the agile philosophy, which encourages a rapid and flexible response to change. 

Thus, many companies are uncertain how to implement agile product development while managing the required documents to prove a system‘s quality and worthiness to external authorities.

In practice, three agile approaches have been proven valuable. The right option should be chosen according to the type of organization, the degree of agile knowledge, and the regulatory environment. 

Approach 1 – Act agile in the waterfall: Water-Scrum-Fall 

The Water-Scrum-Fall approach is one of the smoothest methodologies to slowly transition traditional project development into an agile approach. For companies wanting to start with agile pilots, this approach supports the slow adaptation to new processes. The agile approach is implemented into the regular processes of the company by reconfiguring the agile work into traditional project phases. 

Most projects can be summarized at a high level into three phases: planning, development, and delivery. The Water-Scrum-Fall approach uses the standard planning and delivery phases and executes the development phase using agile methodologies (see figure 2). Thus, the company can gather agile experience and slowly transform project by project into an agile approach. The risk of failure is comparatively low, as the company initiates the transition with small projects and focuses on only one phase of the process. Projects that might not be appropriate for the agile method continue to use a traditional approach. 

In greater detail, this means that the project uses traditional project management tools like a master plan, a work breakdown structure, etc. in the planning phase; however, the milestones that are indicated in the master plan are then transformed into epics and user stories, which the project then lists in its product backlog. This means that in the Water-Scrum-Fall approach, the detailed planning is done through the backlog. To prioritize its product backlog, the project simply refers back to the milestones set in the master plan. The “definition of done” for each backlog item is specified by the deliverables at each milestone. Using this method, the team gets a clear orientation on what to deliver and in which order. 

The entire delivery phase maintains traditional methods as well, including established documentation methods, which means that best practice in documentation can continue and communication with authorities does not change. Since the planning phase is also executed in the traditional way, necessary forms and certificates can be prepared to be filled out in the delivery phase. Consequently, awareness of what must be submitted to authorities is established from the beginning. 

After the initial pilot projects have experienced the advantage of agile working and have generated results, other employees take an interest in developing their work and other projects into agile as well. Over time, the company can decide to transition more phases into agile working or go back to traditional project realization.

Approach 2 – Deliver the mandatory documentation in every sprint: Small V-Models 

The Small V approach is applicable when transitioning an entire project to the agile method. The processes of the traditional V-model with specifications, build, and verification is transferred into every sprint (see figure 3). The large V-model is comprised of many small Vs that are subsequently executed in sprints. If the small Vs are combined to create a large V, the result is a complete product with all the necessary documentation (see figure 4). 

In order to perform successful sprints, the product, parts, modules, and development deliverables must be broken down into small pieces with the corresponding documentation. In the sprint planning, the team takes the manageable increments into one sprint, including its documentation. Simply put, all product parts are developed together with the mandatory documentation in one sprint. 

The advantage of doing the documentation in sprints is that it means less work because it is divided into small parts and done on the run. It is completed in tandem with product development and not as part of the whole package at the end. Thus, it is not a final, uneditable version but is instead a living document that might be revised in subsequent iterations. 

To ensure that the documentation is done correctly and in a timely manner, the regulatory and quality requirements must be implemented into the increments. This means that the “definition of done” of these increments is defined by specific documents, forms, or certificates. Therefore, assigning an experienced team member is critical in producing the right documentation. 

Approach 3 – Dedicate time for the documentation: Validation Sprint 

This approach is a hybrid between agile and traditional and can be described as “regulated agile”. The validation sprint is an enhancement of the small V approach and applicable for products in highly regulated environments. The first official delivery of a product increment or a system is only after a validation sprint (see figure 5), ensuring that the documentation and the product completely fulfill the requirements. In prior sprints, delivery occurred only into a “sandbox”. Tools and technologies like additive manufacturing are used to enable rapid prototyping. Though these prototypes do not support a final approval (for example, due to an inability to test final materials), they enable the team to play around with their design and learn quickly.

The validation sprint acts as an authentication, wherein the team conducts an extensive test to get final approval for deployment. Thus, the validation sprint typically does not deliver any additional functions for the product; its only intent is to deliver all necessary documents, tests, and approvals. The advantage is that the team focuses on the documentation during a dedicated time and is not under pressure to add any new features. Furthermore, unnecessary documentation, like in the second approach (Small V), can be avoided as the documentation is only done in the validation sprints. 

After the validation sprint and delivery, the team proceeds with “normal” sprints until the next validation sprint. The last phase is typically a validation sprint where the overall product is integrated, documented, tested, and ready for the final official release. 

Conclusion 

Agile methods do not always comply with regulations or conditions that are applied/imposed by authorities. “Hardware” companies in particular are faced with many regulative requirements and do not know how to implement agile into their processes. Nevertheless, businesses recognize the value of agile methodologies and want to take advantage of its benefits, so they cherry-pick certain elements to try to adapt the agile approach to fit their current environment, which is oftentimes not very effective or successful. 

The three presented approaches – Water-Scrum-Fall, Small V-Models, and Validation Sprint – are adaptions of the agile approach that are meant to address regulated environments. The table above provides an overview and shows the differences, risks, and advantages of each approach. The decision regarding which method to implement should be based on the type of company, the regulative requirements, the authorities, and the company’s environment. In most cases, each approach must be further customized to the company’s needs. This should be done by considering similar industry examples, competitors, and suppliers, and with a partner experienced in applying agile approaches within regulated environments.