Dataworks Blog


  • Agile Software Development in Regulated Environments

    The adoption of agile software development methodologies has been a development that Dataworks have watched with particular interest.  Agile has gained wide acceptance in various domains within software development and this is being reflected with some of our customers.  The advantages include higher quality code, greater efficiency and greater agility in reacting to changing requirements.

    The adoption of agile methodologies has not been replicated in our more highly regulated clients such as those in the medical device or pharmaceutical industries.  There are various reasons for this. Agile requires a change in mindset.  There can be organisational and cultural obstacles.  With Agile the focus shifts to the customer who becomes part of the team working with the developers to choose features to be implemented over a series of short iterations.  Teams are self organised, project managers become facilitators.  Environments with relatively homogenous teams need a change in psychology to move to the open interactive environment and heterogeneous teams promoted by agile.  There is a reduced emphasis on documentation, with the code becoming self documenting. There are also associated practices and accompanying tools which personnel must become familiar with, e.g. daily team meetings, Test Driven Development (TDD), continuous integration, automated builds and retrospective assessment at the end of iterations.

    Along with the cultural changes, which can cause particular difficulty in larger organisations, one of the major concerns for companies in regulated environments is how all of this fits with the requirements of the bodies that regulate their products, for example, in the case of companies selling products in the US market, the Food and Drug Administration (FDA).  The regulations impose requirements for traceability, validation and verification on these companies in all aspects of production of products including software development.  Reduced documentation for example causes problems.  

    Many of these organisations use a V-Model methodology where the requirements are designed up front and captured in a functional specification document.  These requirements can be mapped directly to test cases in a validation protocol.  This protocol can then be executed against software once development has been completed.  Validation reports can then be generated as an output to meet the regulatory requirement. Companies have concerns as to how outputs like that can be met when using agile. The regulatory bodies do not prescribe a particular methodology for software development; they are only concerned that the required outputs are produced.  

    Another concern would be where companies need to meet the requirements of the Sarbanes Oxley act (SOX). SOX mandate a set of financial regulations on companies. This act requires companies to provide accurate financial reporting on all areas of the business, including development costs. With agile methodologies it can be difficult to provide accurate reporting on development costs.

    Agile methodologies can be aligned to meet these requirements, but some tailoring is required. If these concerns could be addressed agile development would yield similar benefits in this domain as it has in others.

  • Back to Blogs