In our post last week, we have explored how medical device development companies are increasingly transitioning to Agile to be able to develop quality products in shorter time. For them, switching to Agile entails the challenge of matching the process transparency, traceability, and compliance with relevant medical standards that their Waterfall processes allowed them to achieve.
However, this becomes even more difficult when you take into consideration another challenge companies in regulated environments are facing: that of scaling Agile across multiple departments, geographically dispersed teams, and various development lifecycles.
Challenges of scaling Agile in highly regulated environments
Let’s summarise the issues. First of all, companies developing safety-critical products need to be able to manage and coordinate the work of hundreds or thousands of people contributing to the same product, all via self-governing Agile teams. Second, they have to manage multiple Agile development lifecycles: countless sprints, and possibly several releases, in certain cases all contributing to a single product system. Third, all these development streams need to be regulated, with certain processes enforced, all activities recorded & documented, and complete traceability ensured between all artifacts in order to achieve compliance with the necessary standards.
Despite all these challenges, a growing number of large enterprises in regulated markets choose to make the transition to Agile in order to gain its oft-cited benefits: shorter time to market, enhanced product quality, higher customer satisfaction, and lower development costs. The way they do it is via enhanced, customized Agile processes.
Best practices of implementing scaled Agile in a regulated safety-critical environment
It’s important to acknowledge that a certain level of upfront (architecture) design is required when developing devices for highly regulated markets. Most companies do some kind of initial architecture modeling to help guide the development process. Thus, one could say that the Agile methods applied in such cases show similarities to Waterfall’s upfront design phase. Some consider this to be a Hybrid method, while others argue it’s just Agile enhanced & applied to safety-critical industries. In any case, the upfront design should also support risk analysis, serving as a basis for subsequent risk management (hazard reduction / mitigation) activities.
Failure Mode and Effects Analysis (FMEA) is one of the methods applied to support preliminary risk management, as it helps identify all the potential failure modes in advance, and also helps document mitigation efforts, as well as the coverage of risks with these mitigation efforts. Some experts claim that user stories (requirements) should be prioritized according to their risk levels in order to ensure optimal safety levels.
Documentation is also a vital process in safety-critical systems development. The level of rigour applied by industry standards varies, but almost all regulations require developers to thoroughly record and maintain documentation on:
- all processes used in the development of the product (including risk management, QA & testing)
- all changes to requirements & other artifacts during development (including verification of certain items/processes with signatures)
- the links established between all work items from requirements all the way through to release (including test coverage).
The exact type of documentation required by each standard varies, but generally, these are the most important processes safety-critical systems developers need to keep track of.
In addition to risk management, other processes of quality assurance are also important to ensure the reliability and safety of the end product. Complete test coverage not only means that all requirements should be covered by test cases – it also works the other way around, meaning that you should be able to trace back each test to a requirement (this is why complete, gapless end-to-end traceability is so important). Adequate QA processes and software verification should be part of each sprint, complete with testing and code review.
Workflows help enforce processes to ensure compliance & end product safety and reliability. These advanced process workflows may be configured with guards (not letting developers move on until certain conditions have been satisfied) and e-signatures (important for verification processes, e.g. certain critical user stories can only be passed on to developers once the Scrum Master has approved them).
“Continuous compliance” is a term that aptly describes how all the above should support the development of safety-critical end products: preparing for compliance audits doesn’t happen at the end of the development lifecycle, but is rather made one of the basic objectives of the process of development.
Overall, it is safe to say that Agile practices are fit for use in highly regulated industries for the development of safety-critical products. That said, basic Agile needs to be adjusted to the rigorous requirements of certain industry standards, regulations, and guidance documents, and discipline in development processes is key.