Transition to Agile Development - Experiences of a Medical Device Manufacturer
After 25 years of developing medical devices and software mainly for cardiological diagnostics and ambulatory monitoring of vital signs in high-risk patients we acquired a consistent and complete quality management system for our company. This includes a structured and documented development process for our hard- and software which complies with the regulatory requirements such as DIN EN ISO 13485 1 or DIN EN IEC 62304 2. With the constant growth of the organization and the department for research and development this implemented process reached its limits. So the development process had to be improved to accomplish projects more efficient and to shorten the development cycles. Inspired from industry best practices, experiences, conferences and literature we decided to investigate and evaluate agile development processes.
Choosing an agile development process
The major issues when choosing an agile development process are the constraints to stay conform to the regulatory requirements and the needed technical documentation. Classical development processes were often linked and referenced by regulatory requirements. Most of the agile development processes do not refer to regulatory requirements, especially not to regulatory requirements for medical device manufacturers. Therefore it was not possible to choose a strict implementation of an agile development process and the decision was made to adapt the methods, ideas and approaches from different agile processes to the development process of the organization with consideration of the regulatory requirements. So we picked agile principles and adapted them to our development process with the condition to stay conform to the relevant standards. The new process was not rolled out to the whole organization but was implemented in our daily work in one pilot project which covers all relevant aspects of a typical development project in our organization:
- Development of hard-, soft- and firmware
- Medium complexity
- Broad range of involved departments and roles
Sources for the agile ideas, methods and approaches we choose were mainly:
- Manifesto for Agile Software Development 3
- Kanban – Evolutionäres Change Management für IT-Organisationen 4
- Agile Testing – A Practical Guide for Testers and Agile Teams 5
- Implementing Lean Software Development – From Concept to Cash 6
- Basiswissen Medizinische Software – Aus und Weiterbildung zum Certified Professional for Medical Software 7
- The Scrum Guide 8
Best practices and constraints
Agile development processes have numerous methods and best practices which can be used. During the implementation and improvement of our new process, we identified some of these practices which have the most benefit for us since our process transition. On the other side some constraints are given, especially from the regulatory requirements which need to be reflected at every time.
Planning of small iterations
The biggest impact to our project management in terms of controlling the project and to the efficiency of the development team was the split of the project in small iterations. For the big picture and planning a classical project plan was set up. But for the operative work in the development team this plan is divided into small iterations (sprints). A sprint has a duration of 2 to 4 weeks and the planned work has to be finished within this sprint.
Each iteration is planned in a separate planning meeting at the beginning of a sprint where the product owner (product manager) explains his high priority requirements and discusses this requirements with the development team (consisting of developer and tester). So all relevant roles – the product owner, the developer and the tester – have the same understanding of the requirements. Based on this same view the development team decides what they are able to deliver within this sprint. But to deliver a part of the product doesn’t mean just finishing the development. It also means that the following tasks are done in this sprint:
- Design specification and review
- Unit and component testing
- Refactoring of existing parts
- Review of the sources, schematics, etc.
- Integration and system test
- Regression test of the existing parts
This ensures that the development artefact at the end of the sprint is not implemented quick & dirty but has an assured quality and a consistent documentation. At the end of the sprint the results are presented by the development team and reviewed by the product owner, which gives his feedback directly to the team. There are a lot of best practices how to organize planning meetings and sprints and how to estimate the work for the upcoming sprint. But based on the experience, it is more important to change the project to work with these small iterations as the details of planning and estimating. The methods and approaches used to organize and manage the iterations may change during the project and should be adapted to the needs of the development team. The big advantage of splitting the work in such iterations is the possibility to control the progress more often, to review the development results during the project and to get one point of view to the requirements between the development team and the product owner.
Communication and collaboration
Within the last years of development the team members got more and more focussed on “their” work which leads the organization to two major problems:
- Some code, schematics, etc. was only understood and maintainable by one or two developers. Incase of issues during illness or vacation an analysis of the problem was very hard.
- Developers got sometimes lost in solving their problems which maybe can be solved by otherdevelopers of the team in less time. This causes a big loss of efficiency.
To avoid these problems, two approaches were choosen: the daily meeting and continuous reviews.
In a daily meeting, time boxed e.g. to 15 minutes, each team member tells the others what he had done since the last daily meeting, what he will do until the next meeting and if there are any problems which block his work. With this short meeting, maybe done as a stand-up meeting in the morning, each team member knows what’s going on in the project. This reduces the risk, that a team member gets lost in a problem and wastes time with solving it where another team member can solve it very quick. It’s essential that this meeting is not understood as “reporting to the project lead” but as know how transfer to the other team members.
One part of the „definition of done“ defined for one sprint is that all artefacts (design documents, source, schematics, …) are reviewed within the sprint by at least one other team member. Based on the complexity and the risk some documents are reviewed in a formal way, other in an informal way. This leads on the one hand to a continuous quality check of the artefacts and to a broad knowledge about the artefacts in the team. The quality of the artefacts of our development teams increases significantly by implementing continuous reviews. Some developer also took one step forward and started coding with pair programming, where two developer worked on a problem at one workstation.
Within the implementation of the new process we evaluated our existing tools to support our new process. Our main rule was that we first want to define a part of our process as it fits to our needs and then decide which tool can support us. The tools for developing stay mainly as they were. As a tool for managing our whole development process we decided to use an application lifecycle management tool: Polarion ALM 9. Polarion is a very generic tool with the possibility to customize nearly the whole product. It is based on the version control system Subversion 10 and works with work items (e.g. requirement, design, test case, anomaly, etc.) which can be linked together and to other artifacts like source code, etc. The main benefits for us were:
- Traceability over items: We are able to show the implementation path e.g. from a requirement overthe design to the test cases, the found bugs and the according source code. So it is possible to do simple impact analysis if one item changes and furthermore this traceability is an essential part of the regulatory requirements for medical device manufacturer.
- Traceability over time: Because Polarion is based on Subversion, it is possible to get back to a setof work items at a specific time point in the past. For example you can view the requirements as they were in an old release and can show up the changes from the old release to the actual state of the development.
- Customization: Polarion gives us the ability to adapt the tool to our process needs. There are a lotof templates, APIs and configurations which can be used to design a workflow that fits the needs.
Another big issue was the task management of the development teams. Different tools were used for the tasks, e.g. Microsoft Outlook and Polarion but both were not usable for fast tracking, changing and working with the tasks. This leads to the situation, that the developer didn’t use the tools. After some iterations a really light-weight tool was found to manage the tasks: a simple whiteboard with post-it-notes. Each note is one task which can have the state open, in progress or done. On the notes also the relevant items in Polarion (e.g. defects or requirements) are referenced. The whiteboard is also ideal to use for the daily meeting, because it shows the actual state of the iteration.
Team motivation and mind set
More than in classic development projects soft skills of the team members and the team motivation are essential for the success of the project. All team members have to commit to the new methods and approaches for a successful implementation of the process improvement. The experience of our development team shows that sceptic team members mostly had not understood the benefits e.g. of the small iterations. But presenting the results iteration by iteration in the review meeting were the best argument.
The agile methods often contain a funny element which motivates the team member. Some ideas which inspired us:
- Daily Stand-Up meeting outside the office building
- Motivation cards for team members
- Bug hunting sessions
- Planning and estimation poker
- Small challenges
But all the change is not only a process change. Also the mind set and the culture of the organization are affected. For a development team who works in a classical development process this is sometimes not easy and cannot happen from one day to another. Especially if the developers worked only at their domain with a poor interaction with the team. So everyone has to be aware that the transition takes time and the efficiency may decrease at first. Within our projects 5 to 7 iterations were needed to be more productive and efficient than before.
Regulation and documentation
One characteristic of developing medical products is the big amount of regulations that have to be fulfilled. In case the medical device manufacturer wants to join the worldwide market there are also a lot of regional standards that have to be fulfilled to get accredited in these countries. Next to the product standards there are process standards which require a traceable and consistent documentation from the first to the last step of the project. Another aspect is quality and risk control. A medical device has a lot of strong requirements for safety and reliability, which causes a broad range of quality assurance along the whole project from reviews, static analysis to dynamic tests.
These requirements for documentation, quality assurance and risk control have to be part of your process at every iteration of the project. When we began with the definition of our new development process it looked like a no-go for this transition to an agile process. But our experience shows that these regulatory requirements can be fulfilled in an agile process as well. For us, the agile process even has advantages compared to the classic development process in two areas:
- Documentation: According to our definition of done at the end of each iteration also the documentation has to be done. This means the documentation (e.g. requirements, design specification, test cases, etc.) have to be consistent to the development artefacts and have to be reviewed within one sprint. This brings us to a continuous, consistent and quality checked documentation at the end of every iteration.
- Test automation: Just as the documentation also the test automation grows with every iteration. It has to be adapted and executed in every sprint, otherwise the iteration is not finished.
In both cases our experience shows that within a few iterations not only the tester pursues the goal to finish the documentation and test tasks in an iteration but the whole team starts to work intensely at documentation and test automation. Additionally an employee from quality management joins the agile development team to support these activities.
In summary the transition to an agile development process worked for us as a medical device manufacturer. The regulatory requirements require to think about every step in changing the process, especially because the agile methods and approaches do not focus on documentation and regulatory as needed in the medical area. So an adapted agile process has to be used. The methods, ideas and approaches which are established in agile development can be taken to improve the existing development process. This takes us to a standard conform and more efficient development process which is now applied to two big projects developing medical hardware and software.
DIN EN ISO 13485:2010 – Medical devices – Quality management systems – Requirements for regulatory purposes ↩︎
DIN EN IEC 62304:2009 – Medical device software – Software life cycle processes ↩︎
Anderson, D. J.: Kanban – Evolutionäres Change Management für IT-Organisationen. d.punkt.verlag, Heidelberg, 2010 ↩︎
Crispin, L.; Gregory, J.: Agile Testing – A Practical Guide for Testers and Agile Teams. Addison-Wesley Longman, Amsterdam, 2008 ↩︎
Poppendieck, M.; Poppendieck, T.: Implementing Lean Software Development – From Concept to Cash, Addison-Wesley, 2007 ↩︎
Johner, C.; Hölzer-Klüpfel, M.; Wittorf, S.: Basiswissen Medizinische Software – Aus und Weiterbildung zum Certified Professional for Medical Software, d.punkt.verlag, Heidelberg, 2011 ↩︎