UltraVista is using agile software development approaches in the tightly regulated field of mission-critical applications. Many organizations believe that they must use a waterfall approach in regulated environments, but our experience shows that is not the case.
The fundamental principle of a waterfall approach is that development proceeds in stages and does not move from one stage to the next until each stage is considered complete. As Figure 1 shows, it starts with user and system requirements, and then progresses through design, development, integration and verification, to installation and validation. Thus, at the end of each stage, you either have a complete description of the system, at some level, or a complete system. This characteristic is often seen as making it easier to be compliant with regulations, because each complete description can be checked against its predecessors. The waterfall approach is often characterized as a process that permits flow in only a single direction. However, it does allow for feedback between stages as issues are discovered.
There are two main advantages of the waterfall approach:
- It works well in a contractual environment, because the contract can be let against a well-defined set of requirements.
- It avoids the problems of developers working without sufficient context to know whether they are creating something that is not maintainable or will prevent other needed functions being implemented.
However, in practice, it is rare if not impossible to be able to define requirements completely before starting development work, and if that is done, they are often obsolete before the project is completed. Typically, in waterfall approaches, companies actually iterate in each area, and the next area starts before the first is finished so development can prove that the requirements can actually be met. This means that you are actually doing some agile style development without the rigors of an agile process.
Agile development is a radically different approach. It recognizes that requirements will change as more is learned about the way that the proposed system will be used. It places the emphasis on working systems (typically software), rather than enforcing a process with strict deliverables. If this approach is not carefully managed, it could degenerate into a process with all of the problems that the waterfall was designed to avoid, so various means are used to avoid this. In fact, agile approaches often require more discipline than waterfall methods. The main control mechanism used in agile processes is to break the development up into a number of sprints. Each sprint aims either to deliver a well-defined subset of the overall required functionality or to perform well-defined restructuring of the architecture of the system. This is known as refactoring in agile terminology. The approach described in the rest of this article is how UltraVista has successfully applied agile development methods. In addition, we have integrated the scrum project management method that is often combined with agile development practices.
The V-model process
We should also mention the V-model here, as it is often seen as being just another way of looking at a waterfall approach. The main distinction from the waterfall method is that each of the activities at each level of development (the left side of the V) is related to the relevant activity for verifying and validating the system (the right side of the V). Although viewing it as an extension of the waterfall was the original intent, most modern interpretations treat the V-model as representing relationships between activities rather than a set of stages. In many ways, it does not matter whether we consider the items as activities that produce assets or as the assets themselves.
If we regard the V-model as representing relationships, it is clear that it is equally applicable to waterfall and agile development. The only difference is that in agile development, you do not have to complete one activity (with its related assets) before starting another. In fact, you do not even have to create any content in the assets, because they become containers that are populated during development. So lets start with mapping of the activities,
Being agile in a regulated environment
Given the success of agile development, an inevitable question for companies in medical, transit, dangerous goods and other regulated industries is: Can we adopt agile approaches in our environment? UltraVista has done it number of times by sticking to the strategy that where agile and regulatory principles reinforce each other even when they seem to collide.
Regulations currently follow mainly a descriptive approach. This means that regulators expect manufacturers to establish their own development processes and document them, while showing that their processes are robust enough to render safe and effective products when followed. Guidance documents and standards define a set of activities that are expected to be found in these processes, while leaving manufacturers ample room for deciding how to organize these activities in time.
This principle of quality assurance by establishment of robust processes seems to collide with the Agile Manifesto statement that "we have come to value individuals and interactions over processes and tools." In fact, following the agile principle of gathering skilled people and providing them with the means to work well just makes a robust process even more robust. This is because it ensures that teams continuously ask themselves how these are working and whether there are any improvements needed. That's something that regulators explicitly ask manufacturers to do.
Regulatory inspections seek to assess whether established processes were followed or not in the development of the inspected product. From a regulatory standpoint, only objective evidence is valid to support the fact that the process was followed. That leads to certain kinds of documentation that seems to collide with the agile value of "working software over comprehensive documentation." In fact, both agile and regulated principles serve the same purpose if we equate working software with safe and effective software. Documentation is not an end in itself. It is merely a means of showing that the product is going to fulfill its intended use in a safe manner, because it has been developed by following a robust process. Agile principles can help to challenge the documentation that is produced during development to ensure that only valuable materials are produced and wasteful ones are eliminated.
One of the main activities that guidance documents and standards ask for is to define design inputs. These definitions will be the basis for subsequent activities, such as architecture, design, coding, and testing. Regulations also expect a final validation activity that shows that the product is adequate to fulfill its intended use, as defined in those design inputs. Again, this seems to collide with the agile value of "customer collaboration over contract negotiation," although it's actually the opposite. That's because continuous customer involvement during all of the development helps developers fully understand the intended use and user needs. It also means that those needs are translated into a set of design inputs that define the system so that other activities can create the software to fulfill those needs.
Finally, development planning is another of the cornerstone activities that guidance documents and standards ask for to show how the processes that manufacturers establish are tailored to a given product and followed. Although this seems to collide with agile value of "responding to change over following a plan," the fact is that agile puts tremendous emphasis on planning at various levels. Also, regulators admit the need to update plans as development evolves.
Mapping regulated activities in an agile development process
The diagram below shows how the following regulated activities map into an agile development process:
- Requirements analysis (software requirements specification, or SRS)
- Architectural design
- Detailed design
- Unit, integration, system, and regression testing
- Software release
This mapping of activities tries to make up the best of both worlds by trading off its conflicts, as we discuss in the next section.
Resolving conflicts and making trade-offs
One of the main conflicts that arise in practical life when developing software is the degree of detail and formality of the requirements to implement. It is hard to argue against a complete set of requirements that has been reviewed and approved by all stakeholders as the basis to start the development work. Unfortunately, real life shows that complex systems are impossible to fully anticipate and describe in a set of complete and precise requirements that have no flaws. Add to this the fact that changes will occur through a variety of sources, such as customer feedback, and it is easy to see that a significant amount of effort is often spent in rework.
On the other hand, there are system features that are defined and decided outside of the development team. Every system has its business logic derived from its end use. Customers and other stakeholders (for example, service engineers and manufacturing engineers) are going to ask for a set of features that is adapted to the way that they will operate with the product. Moreover, when products evolve, a big part of the development has to build on existing functionalities. Therefore, it would be naïve to leave all this to a self-organized agile team and start the project without enough effort spent gathering all of the needs. These needs, if successfully addressed, can ensure commercial success for the product.
In addition, timing puts pressure on the development job, making concurrent work attractive as a way to shorten time to market. However, the dark side of parallelism is augmented communication complexity and a bigger impact of rework. Going back to our initial set of requirements, it makes sense to start writing test procedures while developers focus on implementation. In regulated environments, those can take a long time to write and are subject of formal review and approval cycles that delay their availability. Hopefully, this ends with a set of test procedures that are readily available to run after implementation is finished. The problem with concurrency is that when changes arise, they can affect requirements, implementation, and tests, thus multiplying the amount of lost work.
Thinking about the worst scenario, we can imagine a case where requirements are gathered, formally reviewed and approved, and given to developers and testers so that implementation and writing test procedures can start in parallel. If the developer later discovers contradictory requirements, lack of detail, or technical issues that render the desired functionalities impossible or impractical, the work must stop and new requirements must be developed. A significant amount of time devoted to the initial requirements will be lost, and obsolete test cases will need to be rewritten.