Mapping Agile onto an IEC 62304 Compliant Process
Sprint releases, production releases and an evolutionary project plan — how agile software development maps onto the activities IEC 62304 requires.
Sprint releases, production releases and an evolutionary project plan — how agile software development maps onto the activities IEC 62304 requires.
Agile development and regulated development are often presented as opposites — one favouring working software over documentation, the other demanding documentation before anything ships. In medical device work you do not get to choose. The question is how to run an agile process that produces, as a by-product, exactly what an auditor will ask for.
The Agile Manifesto values individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. Under IEC 62304 the items on the right cannot simply be set aside. They have to be earned alongside the items on the left.
Sprint releases are milestones marked by customer demonstration points. The version created at the end of a sprint release is a potentially shippable product increment; whether to hand the customer the binary or simply demonstrate it is the Project Lead's call.
Production releases are different. They are shared with the customer, they carry an assigned release version, and from that point on versioning rules apply.
The initial project plan divides the work into several sprints, ordered by the priority of the backlog items selected for each one. High-priority items are those core to the operation of the end product — but also the ones that are complex to design or carry the most unknowns.
Tackling those early is deliberate. If an obstacle appears in sprint two, there is still room to build a contingency plan or choose a different path to the same functionality. If it appears in the final sprint, there is not.
IEC 62304 sets out the activities required when developing medical device software. Those activities map directly onto the ones already executed as part of the development process — which is what makes an agile approach and a compliant one compatible rather than opposed.
None of this is meant to be applied uniformly to every project. It is a starting point: on each engagement a Project Plan is written that tailors the process to what that particular product, standard and timeline actually require.
Tell us what you're building and the constraints it has to work within, and we'll come back with an honest view of whether we're the right fit.
