Scrum in Medical Technology: Opportunities and Challenges
Speed, flexibility, and agility are critical success factors in the market. For companies, this means high time pressure in development projects. This field report shows you the opportunities and risks of agile development methods using the example of medical device development.
Agile System Development
An essential driver of agile thinking and procedures is the increasingly competitive market situation of many companies. Speed, flexibility, and agility are crucial success factors in the market. For companies, this means high time pressure in development projects, shorter development loops and the necessity of early customer feedback. And this at the same time leads to steadily increasing costs due to the regulation of the authorities.
What opportunities and risks does the agile approach in the development of a mechatronic system entail?
The following field report by David Huber, project manager at konplan systemhaus ag, shows you the opportunities and risks of agile development methods using the example of medical product development.
His experiences are based on a project for the new development of an instrument within an interdisciplinary development team. Before the project, the development team had no experience with agile development methods.
A field report by David Huber, Project Manager / Mechanical Engineer at konplan systemhaus ag
My project starts with a two-day training on the agile principles and principles of the Scrum methodology. The contents: Change work processes and methods, reassign roles and responsibilities.
Thorough training of all employees involved in the Scrum concept is indispensable. The employees must not only understand their new role, their new responsibility and the meaning of the new way of working but also respect and actively participate in shaping it. I also needed some time to put what I had learned into practice and to break away from familiar patterns, processes, and structures. In addition to the team members, the existing process landscape is also adapted to the Scrum philosophy. Central to this is the clarification of the interfaces to other stakeholders of the project so that the continuous exchange of information can be ensured. Only under these conditions can the new methods and processes be efficiently implemented and applied.
Clear distribution of roles in agile system development
In Sprint Planning, the work packages to be completed, the so-called backlog items, are distributed to the team in the form of stories. Together in the team, we estimate how long a backlog item will take, decide whether it should be processed as a story or whether it is an epic. An Epic is too extensive to be able to estimate the amount of time required. So it has to be split into smaller parts that can be used as a story. In the end, each team member commits himself to work through the selected stories within a sprint.
I find it exciting that the development team is regularly involved in planning activities. However, some team members find it difficult to commit to the amount of work in a sprint timeframe. This can lead to engineers completely refusing the Scrum. Or lengthy discussions can arise during the Scrum Meetings. In these cases, the Scrum Master has the critical task of finding suitable solutions with a great deal of sensitivity. He must also ensure that the team does not have to deal with urgent short-term tasks from other projects or areas. Otherwise, the sprints cannot be completed on time. The Daily Scrum is available for stocktaking. This is the exchange of information and the alignment within the team. However, the meeting is not intended to solve the problem. Also here the Scrum Master has to intervene occasionally so that the focus is not lost during the short 15 minutes.
The individual sprints are recorded on the electronic Scrum Board, scheduled and assigned to the previously agreed persons. Working with an electronic Scrum Board offers the advantage that project progress can be evaluated in real time. For example, with the help of a burn-down chart. This allows me to conveniently view the current sprints, backlogs and product increments already achieved from my workstation.
The product owner is responsible for setting priorities
The project manager assumes the role of the product owner. He or she is responsible for defining and prioritizing the backlog (worklist) and the sprints. For each sprint, our Product Owner adds the story mentioned above, which defines the content and objectives of the corresponding work package. This is often difficult in mechanical development, as opposed to software development. Complex design work, for example, cannot be broken down to a narrow sprint. Just as challenging is the determination of delivery dates for components and electronic components. Even in an agile world, long delivery times and delays cannot be ruled out.
Creating a prototype
Another challenge is the construction of the prototypes. While changes to a software product can often be carried out in a very targeted and timely manner, the reworking of a mechanical assembly is often associated with a massively higher amount of work and time. After all, a component can often only be replaced by another component after extensive dismantling and reworking. Here, the agile principles and working methods in software development are much more practical than with a mechanical product.
Information flow of central importance for the process
An essential element when working with Scrum is the regular exchange of information between the different departments and the customer. In our case Requirements Management, in particular, has led to extensive internal discussions. Typically, requirements are clearly defined and documented in the classical approach. In the Scrum methodology, however, new insights are created with each sprint, which lead to changes in the existing requirements. This resulted in an intensive dialogue with related disciplines such as Regulatory Affairs and Quality. In addition to interdisciplinary communication, the flow of information to management is also of central importance. Despite agile freedoms in the team, figures and facts regarding project progress, resource requirements and budget are demanded. Due to the Scrum methodology, however, clear answers are not always available as desired.
Conclusion: Challenges through Scrum
What I have learned from agile system development is to test functions as early as possible so that I get direct feedback on my product increments. The Scrum methodology also allows me to better focus on the content development goals during a sprint. However, planning resources and higher-level milestones is more difficult than I am used to from the classic development process. The conformal integration of the procedure in the regulated environment must also be well organized in advance and defined with the appropriate departments such as Regulatory Affairs and Quality. Furthermore, writing meaningful stories is demanding and should be done by experienced product owners. Through the explicit objectives of a sprint, customers and other stakeholders can quickly provide feedback on the basis of the product increments developed, which is immediately incorporated into the development process.
Do you want to exchange ideas with us about Scrum? Or do you have a project that you would like to launch with our support? Then get in touch with us.