Tag Archives: MedDev

Scrum in Medical Device Software Development – Three Critical Aspects

Many companies that develop software for medical devices, including for in vitro diagnostic devices and active implantable medical devices, are still struggling transitioning to an Agile software development process. Assuming you know how to develop software for medical device in the waterfall lifecycle model transitioning to an evolutionary (or spiral) lifecycle model does not take too much.

The Agile Manifesto is often misunderstood and misinterpreted that processes don’t exist, documentation doesn’t get created, and no plan will be followed. When the following three critical aspects are considered your are on the right path to succeed in your Agile implementation.

1. Definition of “Done”

Scrum teams are self managing and self organizing teams. Not the individual, but the team as a whole, is responsible for creating a potentially shippable product at every increment. Which doesn’t mean the team can decide alone what they do, but more how they do it, and who does what task. In the regulated world of software development for medical devices the “what’ includes critical elements like risk management tasks and other process requirements as they might be described in IEC 62304. Every product backlog item (aka. user story) should have a clear agreed on definition of “done” describing all relevant process elements and process outputs.

I collected some considerations what could be part of the definition of “done” for backlog items in a checklist.

2. Transparency

Every iteration should end with two meetings. First a sprint review meeting and then a sprint retrospective. During the sprint review meeting the team demonstrates to the stakeholders what was done and what not and answers questions. The team and the stakeholders collaborate on what could be done to optimize generating value in the next iterations. And please don’t forget, in the regulated software development compliance to the regulations and international standards is also value. Since management could belong to the group of stakeholders it gives management frequent opportunities to work with the teams and to ensure important business needs are met. The second meeting is the sprint retrospective where the team is amongst themselves and discusses issues and how to avoid them in the future. In following sprint reviews the stakeholders could see the improvements.

3. Discipline

One less obvious aspect is discipline. Under schedule pressure team might lead to making shortcuts. The scrum master should work with the team on not giving up on the best practices and agreed on objectives, and much rater adjust the scope of an iteration and do less. Keeping the technical debt low and quality high allows agile teams to continue developing high quality products at a constant pace.