I have spent some time recently navigating the differences between Agile Methods and development under a Formal Management System, ISO 13485.

I’ve spent a lot of time in and leading Scrum teams. While no group I’ve ever worked with felt like they were doing “real” Scrum, they all got the basic gist of small work increments with frequent updates among the team and stakeholders. I think this model has been useful mostly because the developers feel like they know what’s happening (or they have little excuse if they don’t), and the stakeholders feel similarly in the loop. Problems get recognized quickly and prioritizing of those vs. other goals happens regularly. Thus a project doesn’t go too far off the rails before a correction occurs.

Scrum recognizes that the requirements, and therefore design and testing, are never completely established until the stakeholder accepts the work. Up until that point everything is considered to be in flux to some extent.

Formal Management Systems on the other hand are concerned with demonstrating effectiveness. If something isn’t written down, it doesn’t exist. ISO 13485 is particularly all-encompassing with something to say about virtually every aspect of product development.

ISO 13485 (and others) also breaks development down into the phases: requirements, design, verification, validation, manufacture (it’s a manufacturing standard) with review and approval steps for each. The formality of this sequence reads like a traditional waterfall development process, and might seem jarring to an agile development group whose core tenets include “People before Process”.

One of the largest distinctions is that Agile Methods tend to be adopted voluntarily by engineering teams because they appear to provide benefits in terms of team flexibility and delivery throughput to customers. On the other hand, the only instances of Formal Management System adoption that I’ve seen are when an organization wants to demonstrate to another organization that they are using such a system. This might skew the organization motivations a bit and will almost certainly feel like a burden being placed on the development teams.

Does it need to be a burden? That’s what I’ve been working on.

Before I continue, note that I can’t guarantee anything here would be accepted by a Formal Management System audit. I’m not an expert on the interpretation of these standards (though I am certified “Competent” on ISO 13485:2016, for what that’s worth). Use your best judgment when implementing your system. Based on observation, auditors aren’t too particular about the techniques you use to achieve the requirements as long as you can justify your decisions to yourself and third parties.

Documentation

First of all, everything needs to be written down. Most engineering organizations have a wiki or other place to store written documents. If it has revision history and backups, you have met most of the document control requirements. In addition you will need an approval system and a way to observe which versions are approved and which is current.

Historically this requirement would have implied a lot more paper pushing. With electronic systems, this is little more difficult than other aspects of software engineering.

Training

In order to demonstrate that your team is competent to do the work they are doing, you’ll need to keep records of qualifications and training. Resumes are usually available on interview. Then it’s up to management to keep track of internal training and experience. Fortunately, this could be fairly light on the team depending on how you define competence and required training.

Most agile teams rely on a combination of review and regression testing to determine when things are going wrong. Training new employees usually consists of a “Getting Started” document, asking questions of the team, and relying on the review-and-test system to raise alarms when things are wrong. I believe writing this up as the process might be acceptable to a Formal Management System as long as you can show that you understand the risks.

On the other hand, you could introduce new training software that would be more at home in a multi-national corporation, drag your teams through reams of mundane slide-show courses, and definitively show that your organization meets the requirements. I think it’s clear which might grate the company culture, but this usually has the advantage of being readily demonstrable.

Requirements

ISO 13485 treats requirements gathering as a phase, but it allows for modifications provided they go through a review and approval process. Requirements modification is the normal state for an Agile team, so this could be made to fit an Agile development model.

Many Agile teams use Epics. We use Epics to represent our features and then break them down into Stories, verifiable product-change increments. Early in the Epic life-cycle, we collect a set of written requirements for the feature represented by the Epic. Thus, a list of Epics that are intended to be released is also a list of requirements.

Risk Management

This concept in the context of project management and engineering is relatively new to me. The idea of risk we have been implicitly using forever, but I had never considered making it concrete to better communicate the status of the development process and product to stakeholders parties. In retrospect, that feels like a big oversight.

Risk Management is a requirement of many Formal Management Systems, so there isn’t going to be a way around it. Given that, introducing Risk Management to our Agile development necessarily changes how our teams do things — but it can be Agile, and it definitely adds something valuable.

We implemented risk tracking by creating a new Risk ticket type in our ticket tracking system. Risks, at the moment, are analogous to Bugs that haven’t been observed. Review these periodically and raise the particularly bad risks to management, and you should have a system that conforms to at least ISO 13485.

We rolled Risk evaluation into our regular Bug evaluation cycle.

Design

Design is treated similarly to requirements and also allows for update given subsequent review and approval. Once again, design update is standard operating procedure for Agile Methods, so relevant documentation should lean on this heavily.

The collection of Stories and Risks that were produced from the Epic breakdown above are effectively our design. They list what needs to be changed, supporting documentation, how those changes should be verified, what Risks were addressed, and (more importantly) which Risks weren’t.

Manufacture

Most Agile software shops are going to be running a build server in either Continuous Integration mode. Most teams I’ve worked with have done daily full test cycles with continuous unit test cycles throughout the day.

Assuming your scripts are in good shape, this is by definition a highly controlled process. It should be relatively easy to document. Make sure you double-check that you’re verifying what you should and keep records of test results.

Review

I have been a fan of and have used lightweight changelist review for years. From over-the-shoulder to pull requests, it is a staple of Agile development. I think this fulfills a form of
manufacturing monitoring.

Review is a strength of Scrum and Agile Methods in general. Engineering teams meet and discuss issues and design changes (if necessary) daily. Stakeholders meet to discuss potential requirements regularly.

All of these group activities should satisfy the review requirements. Make sure to note that the meetings are happening, and who is present, especially when design and requirements changes are being made.

Approval

One aspect of Formal Management Systems that may seem alien to Agile teams, or at least ours, is the requirement for approval: approval of documentation, approval of requirements, approval of design, approval of release.

However, it didn’t initially occur to us that, by keeping all groups in the loop on a regular basis, we are effectively getting implied approval regularly.

How this is relevant to ISO 13485: approval of requirements changes – handled by an internal stakeholder meeting; approval of design changes – handled by the Product Owner Scrum role; release approval – handled by the internal stakeholder meeting.

The area where we haven’t been strong on approval is changes to internal procedures. Traditionally we have trusted that our team would do the correct thing when making updates and relied on the change history when things didn’t look right. After all, if someone was doing something wrong, they weren’t likely to get far without tripping over the build process.

Summary

This approach to Formal Management Systems may join with Agile Methods to make a very potent combination. The responsiveness of the company, team, and product is maintained without too much impact to the cadence of the teams.

The auditors will ultimately tell us whether this approach is acceptable, but it seems reasonable.