In my article published in issue 12 of Insight magazine, I explored some of the principles and practices of Agile and how it can be applied in certain phases of medical product development at the system level.
Agile software development might be considered as the preferred way to develop software, especially for those using IEC-62304 processes and following the guidance of TIR45. Our experience at Team is that there are still challenges when doing Agile software development as part of an embedded, non-Agile system development.
Planning is one of those challenges (when is predicting the future not a challenge?). When planning software development, we often estimate the complexity of a backlog of required software features using arbitrary story point units. This is used with the velocity (story points per sprint) at which a team has burned through story points in the past to generate a so called burn-up chart. This gives us an estimate of the number of sprints likely to be needed to develop a software feature set (estimated as a total number of story points) at a given team velocity.
This approach can also be used to explore the approximate effects of increasing velocity by adding more resource or investigating ‘what if’ scenarios around the backlog and features. Using sprint duration translates story points per sprint into time. What this simple planning tool doesn’t do is bring in dependencies from other parts of the system or external factors.
In a non-Agile development, the Gantt chart is king when it comes to planning; and it’s very good at planning dependencies. At this point, true ‘Agilists’ may throw their arms up in horror, but we have found that one way to plan for dependencies that could affect software development is to bring sprints into an overall project Gantt chart.
At the moment we unfortunately have to do this manually, but it does allow planning to make sure other system elements (for example hardware or test infrastructure) are available so as not to block or delay software development.
Similarly, we can estimate when velocity may drop due to external factors (such as holidays, hardware bring-up or system availability).
This approach can lead to another challenge. In Agile, it is sometimes possible to flex the scope of what is delivered by a software development team (having a fixed velocity) and time period (each increment of software is intended to be working code).
In a non-Agile world, plans are often made to have something available at a certain time, for example, having a prototype ready for a key meeting or for a device going into clinical trial. This typically doesn’t allow for the scope of what is to be developed to be flexed.
Taking out the option of flexing the scope of software features working at a given point in time puts more emphasis on getting the backlog estimate as accurate as possible. However, backlog features are often loosely defined early in a development and an Agile approach would look to refine the definition of these features incrementally as the development proceeds.
It is therefore advisable to factor in a greater contingency for estimation error when plans extend beyond three to four sprints in our experience. This may mean planning around a reduced set of software features needed for a key point in a project or building in contingency into the velocity of software development early in the project.
Carl heads up Team’s project management group. His role involves planning and managing the successful delivery of multi-disciplinary projects to meet the needs of our clients. Carl has over 20 years’ experience in managing product development in the scientific equipment industry.
Looking for industry insights? Click below to get our opinions and thoughts into the world of medical devices and healthcare.
