The agile way to ensure quality
The manufacturer that enters the market first with a product that satisfies market demands with respect to quality and functionality will typically have a large share of the market. Meeting market expectations in a very dynamic time with a lot of shifts as a result of a number of new players and technology development that constantly provides new opportunities demands a readiness to change as never before. The introduction of agile development can be the toolbox of processes and methods that contain the solution, even though the introduction of agile processes also is challenging.
“Agile is the property that is the ability to quickly adjust to changing conditions.“
Agile thinking is based on the idea that the world is unpredictable and, regardless of the thoroughness of the preparations, it is not possible to plan a way out of uncertainty. Therefore, instead of following a detailed plan based on precise requirements specifications, you choose to work based on a vision about the end product and exploit the uncertainties by learning from the changes and use this knowledge to strengthen the product.
The usability of methodology.
Agile development in itself is not a development model, but a set of frameworks and values, which, through the use of process tools such as SCRUM, are incorporated as processes. The usability of the agile methods is closely related to the complexity of technology and user requirements. The usability of agile methods is most useful when user requirements are only loosely formulated and the technology has not been tested or is very complex.
Agile processes versus regulatory requirements
The agile approach has obvious advantages. If the processes are sensibly managed, the advantages can be reduced time-to-market and better quality while, at the same time, meeting the demands of the market. Companies that work in heavily regulated industries, such as medical devices, are aware that legislation and standards make demands on establishing and maintaining the traceability between requirements and products, and that clear, appropriate documentation for the creation of the product is crucial and the most important proof that the development took place with a suitable level of control.
Requirements for traceability through the individual development steps in a development project could make you think of plan-driven or sequential models, such as the V model or waterfall model, which in a regulatory context might appear to be the obvious choices because they provide a logical flow in the work and documentation – also even if agile methods have been used in delimited parts of the development.
Say what you want to do and show what you have done
The regulatory requirements do not require the use of a specific development cycle. Therefore, the agile methods can be used in compliance with both legislation and standards without jeopardizing the regulatory approval.
Seen from a regulatory point of view, traceability through the different development stages is important and the introduction of agile processes is not at all the same as removing all structure. When agile processes are used, the rule of thumb – ‘Say what you want to do and show what you have done’ is probably even more important than is the case with more plan-driven models. This can especially be related to the requirement for traceability based in the requirements, and if the requirements change frequently, the documentation must also be updated frequently. It is precisely the traceability requirement that fits well in the iterative and agile process because the requirements are documented on an ongoing basis throughout the individual iterations.
Quality is a question of mindset
Quality is only a measurable entity if quality objectives have been defined. Ensuring quality, on the other hand, is to just as great a degree a question of mindset in the development organisation and the adjustment of processes.
Working with agile processes in a regulatory context has as a prerequisite that there is a certain maturity, which in this connection must be regarded as being the organisation’s ability and will to deliver quality. The mature organisation has incorporated and follows well-defined processes and does so because it makes sense and not just because there are regulatory requirements for documentation and traceability.
What is difficult is finding the optimal balance between regulatory requirements and agility, which are defined in the agile manifesto1, which, based on software development, describes how to optimise development processes so that it is possible to change requirements for the product until late in the course of development in order to deliver the product that is actually needed by the users.
Agile practices, such as task boards, burn-down charts, sprint backlogs, stand-up meetings, continuous integration and user stories can all be integrated using traditional approaches. However, the success rate depends on the maturity of the development organisation and the introduction of agile practices and processes should, therefore, be a well-considered decision.
When agile processes are introduced to a regulated environment, the greatest challenge is typically management of expectations between the involved parties. The maturity of the organisation – and especially the relationship between the quality assurance department and the development department, so that both parties can learn from each other and work together on the changes and adjustments that are required until the agile practices have matured, have great significance for the rate of success.
A valuable reference is AAMI TIR452 entitled ‘Guidance on the use of agile practices in the development of medical device software’. The guidelines seek to find synergy between the structured documentation and the agile processes. The guidelines provide both conceptual and practical guidelines for establishing agile processes in accordance with the standard for Medical device software – Software life cycle processes, IEC 623043.
The FDA’s recognition of agile methods by including TIR45 in the list of recognized consensus standards in January 2013 is an important step on the way to disseminate agile methods for software development when developing medical devices.
Implementing agile processes
Maturity and optimised processes are a prerequisite for implementing a full-scale agile set-up, but in any case, the level of agility must be balanced with regard to the specific products that are to be developed. Therefore, it is necessary to look at the total set-up – and especially the interrelationship between hardware development, software development and testing, where synchronisation is often a challenge and where change management is particularly important.
Implementation of agile development techniques.
When implementing agile processes in the development of software for medical devices or as medical devices, the following steps would be good to take:
- Clarify the connections between agile practices and regulatory requirements and make sure they are maintained.
- Address any gaps and deal with them appropriately.
- Establish a strategy for introducing agile processes. With a clear strategy, it will be easier to keep the implementation ‘on track’ and make decisions during implementation, particularly if the development organisation is to mature at the same time. TIR 45 provides inspiration for establishing a strategy for implementation at medical equipment manufacturers.
- Establish independent reviews of the documentation to ensure that the requirements for documentation have been met.
- Carry out assessments of the individual project’s suitability for completion by using agile processes.
Opportunities and pitfalls
The introduction of agile processes and an agile mindset provides opportunities for optimising the development processes and reaping the benefits of time-to-market, and increase quality and meet market demands better. The transition to agile development is full of pitfalls and therefore the implementation must take place carefully, so that the agile processes, methods and tools are used where they make sense and in a well-managed transition in which there is an awareness that it is not just the replacement of some tools, but also a change of mindset that is taking place among all of the parties involved.