The question I want to discuss here is to know if a Software MD (Medical Device) can be developed in an Agile way. Or is it condemned to a Waterfall-old-style method ?
To apply Agile on a Software Medical Device of class B or C (for Europe - IEC 62304) or Major or Moderate (for USA - FDA), several problems appear.
In this blog, I want to share some challenges when maping Agile to a regulated environment and to open some a discussion about how to deal with. Some solutions are clear, some other not.
In first, let’s talk about Agile values.
The Agile Manifesto (http://agilemanifesto.org) tells us the Agile values:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
So, we see a first problem. In a regulated environment, we ask especially three things:
- to follow processes,
- to produce a comprehensive documentation (at least, very important documentation),
- to follow a plan.
Wow! It seems clearly that Agile is not compliant with standards as 62304 or FDA. Really ?
Standards tell us to strictly follow the processes, what doesn’t seem compliant with the Agile values. But can we consider that individuals and interactions can be used as a force to propose improvements in the processes ? Of course, in a such case, the processes couldn’t evolve at the speed of an Agile team. So, can we adapt processes for a project if it’s documented, justified and verified ? Well, anyway, a such hypothesis would require a perfect cooperation between the Agile team and the Regulatory and Methods team.
Agile tells us to promote working software over comprehensive documentation.
Of course, the problem is that the standards doesn’t negotiate with this point. We have to produce the attended documentation. But can we make a parallel with testing effort ? Testing effort is very high, so we use automated tests tools. Thanks to technology, it’s enough mature now, while there are still several limitations.
So, can we consider that the generation of documentation should be addressed by DevOps, to produce documentation automatically ? Anyway, it would be a solution for this point.
OMG, to follow a plan sounds like to work with a Waterfall method ! All should be plan before to start. Well, perhaps not. Can we consider the iterations of a Scrum project as mini Waterfall projects ? An iteration is bounded by a plan (Sprint Planning) and a validation (Sprint Review). Scrum introduces just several other ceremonies, especially a Retrospective. So, for standards, can we consider that we follow a plan, at the level of each iteration ?
There are several tools for Configuration Management.
For the source code, the best practice is to use Git, especially appropriate for us.
For delivery, there are several Continuous Integration servers.
For the documentation, there are several documentation management software… but far to be enough. What about DevDocs ?
Let’s have a look at the definition of DevOps on Wikipedia:
- DevOps is a software engineering practice that aims at unifying software development (Dev) and software operation (Ops).
- The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction, from integration, testing, releasing to deployment and infrastructure management.
- DevOps aims at shorter development cycles, increased deployment frequency, more dependable releases, in close alignment with business objectives.
Wow! So, what about the definition of a new concept, DevDocs:
- DevDocs is a software engineering practice that aims at unifying software development (Dev) and documentation writing (Docs).
- The main characteristic of the DevDocs movement is to strongly advocate automation and tracking at all steps of documentation writing, from creation, updating, verification, approval, traceability and archiving.
The Risk Management is at the center of the development of the software. So, it seems logic that developers should have knowledges about risk management.
How to reduce the impact of the risks? Choose an appropriate architecture of course. What else?
If DevOps is important for Agile projects, it’s more than important for Agile projects in regulated environments.
As, depending on the severity of each specification, we have to adapt the testing effort, at the end, the workload of testing can be quickly very important. Fortunately, with the technology, it’s no more a problem, there are a lot of technology to automate tests. The technologies for Unit Tests and UI Tests have their limitations, it’s important to know, but once known, it solves a big part of the problem.
Anyway, the testing operations should be as automated as possible with a Continuous Integration server and eventually several other servers (testing automation, …):
- Unit Tests by using TDD (or not),
- Integration tests (with User Interface or with REST API, …),
- Static analysis,
- End-User tests by using BDD.
Sure, a part of tests will be manually, but it allows to focus efforts in an optimal way.
What about other kind of tests ? Stress testing, security testing ?
What we talked above is about Design control. Once the software delivered, it enters in maintenance phase. The development follows a small development cycle, and the document has to be updated. Thanks to DevDocs!
For specific activities for Problem Resolution, the tools used are of course very important. It should respect the workflow the standards require.