Transition to agile software development 

Experiences of a medical device manufacturer

After 25 years of developing medical devices and software for cardiological diagnostics and ambulatory monitoring of vital signs in high-risk patients, we have developed a consistent and complete quality management for our company. This includes a structured and documented development process for our hardware and software, which complies with regulatory requirements such as DIN EN ISO 13485 ¹ or DIN EN IEC 62304 ² are met. With the continuous growth of the organization and the area of research and development, this implemented process reached its limits. Thus, the development process had to be improved in order to execute projects more efficiently and to shorten the development cycles. Inspired by industry best practices, experiences, conferences and literature, we decided to investigate and evaluate agile development processes.

Choosing an agile development process

The main problems in choosing an agile development process are to comply with regulatory requirements and to provide the necessary technical documentation. Classical development processes were often linked and referenced to regulatory requirements. Most agile development processes do not reference regulatory requirements, especially 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 organization's development process with regulatory requirements in mind. So, we selected agile principles and adapted them to our development process with the requirement to adhere to the relevant standards. The new process was not rolled out to the entire organization, but implemented in our daily work in a pilot project covering all relevant aspects of a typical development project in our organization:

• Development of hardware, software and firmware
• Medium complexity
• Broad spectrum of departments and roles involved

Sources for the agile ideas, methods and approaches we choose were mainly:

• Manifesto for Agile Software Development ³
• Kanban - Evolutionary Change Management for IT Organizations ⁴
• Agile Testing - A Practical Guide for Testers and Agile Teams ⁵
• Implementing Lean Software Development - From Concept to Cash ⁶
• Basic knowledge of medical software - Training and further education to become a Certified Professional for Medical Software ⁷
• The Scrum Guide ⁸

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 on our project management in terms of controlling the project and on the efficiency of the development team, was the division of the project into small iterations. For the big picture and planning, a classic project plan was set up. However, for the operational 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 must be completed 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
• Unitand component tests
• Refactoring of existing parts
• Review sources, schematics, etc.
• Integrationand system testing
• 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 cooperation

In recent years of development, team members have become more and more focused on "their" work, which leads to two major problems when it comes to organization:

• 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.

Daily meeting

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.

Continuous checks

Part of the "definition of done" defined for a Sprint is that all artifacts (design documents, source, schemas, ...) are reviewed by at least one other team member within the Sprint. Depending on complexity and risk, some documents are reviewed formally, others informally. This leads to a continuous quality check of the artifacts and to a broad knowledge about the artifacts in the team. The quality of our development teams' artifacts increases significantly as a result of implementing continuous reviews. Some developers have also gone a step further and started pair programming, where two developers work on one problem at one workstation.

Tools

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 ⁹.Polarion is a very generic tool with the possibility to customize nearly the whole product. It is based on the version control system Subversion 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 Mindset

More than in classic development projects, the soft skills of the team members and team motivation are crucial to the success of the project. All team members have to get involved with the new methods and approaches in order to successfully implement the process improvement. The experience of our development team shows that skeptical team members usually had not understood the benefit of e.g. small iterations. The best argument is the presentation in the review meeting, iteration by iteration. Agile methods often include a fun element that motivates team members. Some ideas that 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 like the documentation, the test automation grows with each iteration. It is continuously adapted.

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.

Conclusion

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.