Transition to Agile Software Development

Experience of a medical device manufacturer

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

Selection of an agile development process

The main problems when choosing an agile development process are complying with regulatory requirements and the necessary technical documentation. Traditional development processes have often been linked and referenced to regulatory requirements. Most 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 organization’s development process taking into account the regulatory requirements. We therefore 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 that covers 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

The main sources for the agile ideas, methods and approaches we chose were:

• 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 - Education and Training for Certified Professional for Medical Software
• The Scrum Guide

Best practices and restrictions

Agile development processes have numerous methods and best practices that can be utilized. During the implementation and improvement of our new process, we have identified some of these practices that have been most beneficial to us since our process change. On the other hand, there are some limitations, mainly due to regulatory requirements that need to be considered at all times.

Planning of small iterations

The biggest impact on our project management in terms of controlling the project and the efficiency of the development team was the division of the project into small iterations. A classic project plan was drawn up for the big picture and planning. For the operational work in the development team, however, 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 start of a sprint, in which the product owner (product manager) explains their high-priority requirements and discusses them with the development team (consisting of developers and testers). This ensures that all relevant roles - the product owner, the developer and the tester - have the same understanding of the requirements. Based on this shared view, the development team decides what it can deliver in this sprint. However, delivering a part of the product does not only mean completing the development. It also means that the following tasks are completed in this sprint:

• Design specification and review
• Unit and component tests
• Refactoring of existing parts
• Review of sources, schematics, etc.
• Integration and system test
• Regression testing of existing parts

This ensures that the development artifact is not implemented in a quick & dirty manner at the end of the sprint, but has assured quality and consistent documentation. At the end of the sprint, the results are presented by the development team and reviewed by the product owner, who provides feedback directly to the team. There are many best practices on how to organize planning meetings and sprints and how to estimate the work for the upcoming sprint. However, experience shows that it is more important to change the project to work with these small iterations than the details of planning and estimating. The methods and approaches for organizing and managing the iterations may change during the project and should be adapted to the needs of the development team. The big advantage of dividing the work into such iterations is the possibility to check progress more often, to review the development results during the project and to maintain a consistent view of the requirements between the development team and the product owner.

Communication and collaboration

In the last few years of development, the team members have focused more and more on “their” work, which leads to two major problems in the organization:

• Some codes, circuit diagrams etc. were only understood by one or two developers and could not be maintained. When problems occurred during illness or vacation, it was very difficult to analyze the problem.
• The developers sometimes get lost in solving their problems, which could perhaps be solved by other developers in the team in less time. This causes a great loss of efficiency.

To avoid these problems, two approaches were chosen: the daily meeting and continuous reviews.

Daily meeting

In a daily meeting, limited to e.g. 15 minutes, each team member tells the others what they have done since the last daily meeting, what they will do until the next meeting and whether there are any problems that are blocking their work. With this short meeting, perhaps held as a stand-up meeting in the morning, every team member knows what is going on in the project. This reduces the risk of one team member getting lost in a problem and wasting time solving it, where another team member can solve it very quickly. It is important that this meeting is not seen as a “report to the project manager”, but as a transfer of know-how 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 checked formally, others informally. This leads to a continuous quality check of the artifacts and to a broad knowledge of the artifacts in the team. The quality of our development teams’ artifacts increases significantly through the implementation of continuous reviews. Some developers have also gone a step further and started pair programming, where two developers work on a problem at one workstation.

Tools

As part of 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 our needs and then decide which tool can support us. The tools for development remain essentially as they were. As a tool for managing our entire development process, we have chosen an application lifecycle management tool: Polarion ALM. Polarion is a very generic tool with the ability to customize almost the entire product. It is based on the Subversion version control system and works with work items (e.g. requirement, design, test case, anomaly, etc.) that can be linked to each other and to other artifacts such as source code, etc. The most important advantages for us were

• Traceability via elements: We are able to show the implementation path, e.g. from a requirement through the design to the test cases, the errors found and the corresponding source code. This makes it possible to carry out a simple impact analysis if an element changes. Furthermore, this traceability is an essential part of the regulatory requirements for medical device manufacturers.
• Traceability over time: As Polarion is based on Subversion, it is possible to go back to a set of work items at a specific point in time in the past. For example, you can view the requirements as they were in an old release and show the changes from the old release to the current state of development.
• Customization: Polarion gives us the ability to customize the tool to our process requirements. There are a variety of templates, APIs and configurations that can be used to design a workflow that meets the requirements.

Another major problem was the task management of the development teams. Various tools were used for the tasks, e.g. Microsoft Outlook and Polarion, but neither were suitable for quickly tracking, changing and editing the tasks. This resulted in the developers not using the tools. After a few iterations, a really lightweight tool was found to manage the tasks: a simple whiteboard with post-it notes. Each note is a task that can have the status open, in progress or completed. The relevant elements in Polarion (e.g. defects or requirements) are also referenced on the notes. The whiteboard is also ideal for the daily meeting, as it shows the current status of the iteration.

Motivation and attitude of the team

More than in traditional development projects, the soft skills of the team members and team motivation are crucial to the success of the project. All team members must embrace 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 did not understand the benefits of small iterations, for example. The best argument is the presentation in the review meeting, iteration by iteration. The agile methods often contain a fun element that motivates the team members. Some ideas that have inspired us:

• Daily stand-up meeting outside the office building
• Motivational cards for team members
• Bug-hunting sessions
• Planning and estimation poker
• Small challenges

But the whole change is not just a process change. The mindset and culture of the organization are also affected. For a development team working in a traditional development process, this is sometimes not easy and cannot happen from one day to the next. Especially if the developers only work in their domain and there is little interaction with the team. So everyone needs to be aware that the changeover takes time and that efficiency may drop at first. In our projects, 5 to 7 iterations were necessary to become more productive and efficient than before.

Regulation and documentation

A special feature of the development of medical devices is the large number of regulations that must be met. If the medical device manufacturer wants to participate in the global market, there are also many regional standards that must be met in order to be accredited in these countries. In addition to product standards, there are process standards that require traceable and complete documentation from the first to the last step of the project. Another aspect is quality and risk control. A medical device places high demands on safety and reliability, which requires a broad spectrum of quality assurance throughout the entire project, from reviews and static analyses to dynamic tests.

These documentation, quality assurance and risk control requirements need to be part of your process for every iteration of the project. When we started defining 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 also be met in an agile process. For us, the agile process even has advantages over the classic development process in two areas:

• Documentation: According to our definition of “done”, the documentation must also be completed at the end of each iteration. This means that the documentation (e.g. requirements, design specification, test cases, etc.) must be consistent with the development artifacts and must be checked within a sprint. This leads to continuous, consistent and quality-checked documentation at the end of each iteration.
• Test automation: Just like the documentation, the test automation also 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 of completing the documentation and test tasks in one iteration, but the entire team begins to work intensively on the documentation and test automation. In addition, an employee from quality management joins the agile development team to support these activities.

Fazit

In summary, the transition to an agile development process has worked for us as a medical device manufacturer. The regulatory requirements make it necessary to think about every step when changing the process, especially because the agile methods and approaches do not focus on documentation and regulation, as is necessary in the medical field. An adapted agile process must therefore be used. The methods, ideas and approaches that are established in agile development can be used to improve the existing development process. This leads to a standard-compliant and more efficient development process, which is now being used in two large projects for the development of medical hardware and software.