Q&A on the Book Agile Methods for Safety-Critical Systems

The book Agile Methods for Safety-Critical Systems by Nancy Van Schooenderwoert and Brian Shoemaker explains how agile principles and practices can be used to build quality in from the start to develop medical and other safety-critical systems.

InfoQ readers can download a sample of Agile Methods for Safety-Critical Systems.

InfoQ interviewed Van Schooenderwoert and Shoemaker about why agile is the answer to the safety, quality, and innovation needs of the safety-critical industry, applying agile for safety-critical systems, doing testing as you go and story mapping, how to meet legal and regulatory obligations when using an agile approach, and how to apply agile for increasing security.

InfoQ: What made you decide to write this book?

Nancy Van Schooenderwoert: Two things prompted me - First, it seems that everyone promotes agile for its “speed to market” which is true, but as I see it, that speed is a side-effect of putting quality first. So I wanted to elaborate on that message.  Second, I see agile getting more and more complicated these days and that bothers me. I wanted to set out our thinking from the first principles of agile, as given in the manifesto, and then present it for an audience of middle managers and senior technical people in medical device companies who may not yet be sold on agile. 

Our book is a primer meant to explain in plain language the parts of agile thinking that so many find to be counter-intuitive or paradoxical.  Real examples from our work in software, hardware, QA, and regulatory aspects help to keep the book from being too theoretical.  For me the goal is to equip readers with the understanding they need in order to exercise leadership from the role they are in right now - leadership to help their company and people reshape the organization so they become more agile. 

Brian Shoemaker: Inspiration for this book arose from the classical perceived time - quality - cost tradeoff in development of safety-critical systems. We are convinced that teams who follow an effective and flexible development approach will always outperform teams using traditional methods.

Inspiration also came from the desire to respond to the too-often-heard refrain that agile may be fine for most applications, but isn’t appropriate for safety-critical work. We’ve done safety-critical work nearly our whole careers and we consider agile methods to be the safest by far.

We've presented talks and workshops on these topics for at least nine years. In doing so, we recognized certain basic information which went beyond what we could present in a workshop, which needed to be organized in a way that would reach more than just those who could attend our workshops and courses. In addition, the publication of AAMI TIR 45 (Technical Information Report 45, from the Association for the Advancement of Medical Instrumentation) gave agile methodology a respectable foundation, but we could see that someone needed to explain the specifics of how to transition to an agile approach and use that approach to develop products. Agile Methods for Safety-Critical Systems: A Primer Using Medical Device Examplespicks up where AAMI TIR 45 left off.

InfoQ: For whom is this book intended?

Shoemaker: The main target audience is middle to upper managers, who need development to be flexible and capable of responding to changing demands. At the same time, we hope the book helps professionals with QA (quality assurance) and RA (regulatory affairs) roles understand how agile can be used in their companies.

Van Schooenderwoert: Primarily middle managers and senior technical people in medical device companies.  Senior level managers will also find it useful, especially if they need a brief, authoritative description of why agile is safer than traditional methods ***IF*** it is properly used. 

InfoQ: In your book you stated that “Agile is the answer to the safety, quality, and innovation needs of every safety-critical industry.” Why is this?

Van Schooenderwoert: Agile methods are well known for speed of development work, but our message is that the speed comes as an after-effect of paying close attention to achieving ultra-high quality without adding waste.  In the past, the thinking about reducing waste was done mainly by managers and in my past experience, they’d tend to cut the wrong things out because they weren’t tapping the ideas that technical people can bring.  

For instance, to cut the waste of too much defect troubleshooting, my early agile embedded software team built logic into our production code to detect anomalous conditions - like an “else” branch that execution should not be able to get to.  These situations are often not a bug, but will become a precondition for one later on. As a result, we averaged fewer than two bugs per month for the whole team (5 to 6 people) that made it past our unit tests.  Instead of spending 30-50% of the team’s time on defect troubleshooting, we were spending less than 1% of our time on that.  

Fewer defects has to be an improvement to safety! And the additional time that was freed up for the team was the equivalent of getting a couple additional team members for free.  So we could use that time to look for better solutions, and also to assist the other engineers with system-level troubleshooting necessary for tricky issues to get solved.

Shoemaker: Now more than ever, the demands of an industry such as medical devices, where I do most of my work, can shift rapidly, and tolerance for inconvenient or poorly thought-out designs is low. Teams doing design work in these areas need to be nimble enough to respond to changing needs, while still managing the requirements for quality, safety, and compliance. An agile approach which accounts for all these factors will always outperform a heavy, phase-gated, document-driven approach.  

InfoQ: What are the main differences when applying agile for safety-critical systems?

Shoemaker: Teams working on safety-critical systems need to address all the issues they’ve always needed to address, such as risk evaluation and management, documentation for compliance, human factors (as a key element of safety), and of course, quality. Traditional thinking has trouble fitting these design activities into an agile context - showing that “fit” was the reason for AAMI TIR 45, and for our book.

Considering safety risks, documenting requirements and design, and complying with regulatory requirements are not what most web site or game app developers need to think about, so the demands on agile teams in a safety-critical environment are different from other types of work. This message - and the fact that these other activities CAN fit with an agile approach - was the reason for developing AAMI TIR 45.

Van Schooenderwoert: When I worked on projects using the old phase gate and waterfall approach, it was common to skip creating unit tests.  In fact I don’t recall ever being on a project where we did more than a token stab at it. Of course the plan said we would, but the plan said a lot of things and by the time we were a couple months into the work, reality and “on paper” were very different things. This divergence was allowed to stay hidden till almost the end of the projects. Then it would all fall apart.  Non-compliance to the plan was not an isolated thing, but was the norm for those projects - even ones that were safety-critical.  Agile calls for a demo of tested working software at regular short intervals. Sure, you can go wrong with agile, but you have to face up to it pretty fast. And the retrospective practice can help you get back on track. 

There are no shortcuts when building safety-critical systems.  Agile does not work when implemented in a superficial way and that’s because real agile practices actually deal with all aspects of software design, development and test by creating mirror communication paths among those building the product - not only the software.  This makes agile more compatible with safety-critical work than traditional methods. 

InfoQ: What are the biggest challenges for adopting agile and how can we deal with them?

Van Schooenderwoert: For people at the technical level - as I was when agile emerged around 2000 - if you haven’t got management sponsorship for agile, it’s harder but you can get a start by using the agile technical practices “under the radar”.  If you cannot get everyone in your team on board then what you can do is very limited. But you can learn enough by doing it to get yourself hired at a company that does value agile practices. 

The biggest challenge is to have a group of people with influence over the “skill siloes” who also have an understanding of the deeper thinking that underlies agile. I believe that middle managers and senior technical people are key to this. Cooperation across the typical organizational divisions is an absolute must for agile to deliver its biggest benefits. In organizations that are conscientiously moving to agile they create a team of people from across different functions to identify and guide the changes that are needed to better support agility. 

Shoemaker: Three major challenges come to mind.

1. Misconceptions about Agile. Within medical device companies, many professionals in Quality Assurance, Regulatory Affairs, and management oppose Agile adoption because they believe Agile is not acceptable for their work. Or, if they think they’re ready to accept an Agile approach, they want to know what the Agile SOP should be (as if such a thing could exist).
2. Compartmentalization (silo mentality). Too often, Agile is viewed as “that thing the software team does,” without any understanding or participation by management, other engineering groups, or marketing (among others).
3. Go-it-alone thinking. Agile can seem simple, but transitioning to an Agile approach is definitely not easy. When companies attempt the transition without the guidance of a coach, the effort can run aground for any number of reasons - either too much success in early projects, total failure because the wrong project was chosen for demonstration, or confusion because too many projects were launched at the same time. A good coach, who is aware of the industry requirements, will help teams avoid the rocks.

InfoQ: How does agile enable testing as you go, and what benefits does that bring?

Shoemaker: Frankly, a team can’t claim to be Agile unless they’re integrating and testing continuously as they develop! The benefits come not just from the testing, which will reveal system issues early before they’re painful to fix, but also from regular product demonstrations, where real users get to point out details which were missed or never brought up (again, well before a product is finalized and difficult to change).

The question is not so much about how Agile enables testing as a product takes shape, but how the team makes continuous and rapid testing possible.

Van Schooenderwoert: Often something needed by one group is hard for them to do, but easy for another group.  Consider electronics designers who need to sense how their hardware is behaving in various scenarios.  It’s expensive if they create hardware to do this, but the software team can build something and can easily change it as needed.  Agile calls for cross-functional teams, or at least more communication between different teams, and it’s this mixing of skill areas that is the most fertile soil for generating good ideas for how to test the more challenging features. 

InfoQ: How can we use story mapping for safety-critical products?

Van Schooenderwoert: What I love about Story Mapping as taught by Jeff Patton is the way it focuses on a set of sequential activities by the customer. That alone helps you avoid jarring disconnects between the features you create to support actions that are grouped together in usage. 

I also like the way you can see the growing support for an activity by looking at the set of upcoming sprints.  This encourages discussions across functional specialties that otherwise may not happen at the right time, or at all.  It’s a great way to prevent defects that “fell through the cracks”.

Another great thing a story map does is show where hardware and software stories naturally come together. Since the focus is on the product as a whole, and on building something that is viable for certain uses at each release, the story map counters the tendency to let the functional silos work too separately.  That’s a very common mistake, especially where agile change sponsorship is spotty.

So story mapping is not really different for safety-critical work: the difference is that the problems avoided might be much more serious than in other kinds of work. It’s important to understand why story mapping is so powerful and to avoid any temptations to casually skip aspects of it. 

Shoemaker: We believe that by using story mapping, a team building a safety-critical product can effectively plan the iterations their product will go through along the way. Not only will software features show up on the map, but many hardware features can be planned as well. Because the map is visual and simple to understand, individuals in many functions - marketing, service, and management as well as engineering - can understand it and contribute to the planning process. Because the mapping process is inherently iterative, it can also adapt to changing demands as development proceeds.

Applying story mapping for safety critical development has a unique benefit - stories which mitigate safety risks can be included so that their priority stands out clearly. 

InfoQ: What can be done to meet legal and regulatory obligations when using an agile approach?

Shoemaker: A team developing a safety-critical system such as a medical device needs to recognize that managing their safety risks and documenting their work are just as important as the features they are implementing - and that the final system will not be complete unless these elements are addressed. Therefore, just as a design grows iteratively, the development team and their quality-assurance colleagues need to agree on how the associated parts can also grow by iterations. This may require a new, more granular approach to approvals. 

Mitigations for hazards are features in their own right - these can be represented on the story map as specific kinds of user stories, and each of those stories can include information which traces back to the analysis (such as an FMEA) where the hazard was identified.

If user stories are fully expressed (say, in actor - action - goal notation, with conditions of satisfaction), then the collection of these stories constitutes a user requirements document with traceability information - key requirements in the safety-critical, regulated world.  

Van Schooenderwoert: For the things you have to do for regulatory rules, make them into a value-add.  Here’s an example about documentation. In my team we asked ourselves whether a doc has to be ink-on-paper. It’s better to document tests as “executable specifications” because you can instantly tell whether the code still passes the tests! Of course that won’t take care of all documentation. For our high-level design docs, we made them do triple duty. By making a sketch of the functionality when we first discuss a portion of the architecture, that doc pays us back by helping the whole team understand. If we add notes to it when we do detail design on how to implement it and why we chose that way, it pays us back again when we need to go back to that code for some troubleshooting, or to add a change. When a new team member joins, it pays us back a third time by easing their effort to learn the codebase.  And of course we can hand it off to a tech writer when it’s time to make a version suitable for customers or others.

InfoQ: What makes cyber security important for medical devices and how can we apply agile to for increasing the security?

Van Schooenderwoert:In chapter 3 of the book we discuss the way that complacency in the medical device industry is heading for a crash with reality. Despite serious security breaches found on hospital medical devices, reliable sources tell us that industry execs are deciding to wait until there is a public outcry rather than take proactive steps!

We cannot afford to treat security as just another silo.  So much of what security professionals have been saying for years about building security in from the start can be a natural part of agile teamwork. 

Shoemaker: Cybersecurity breaches have not only given hackers access to protected health information, they have in some cases exposed device users to unauthorized access to control of their devices (examples: insulin pumps, implanted heart devices). 

Agile, in particular the iterative and flexible nature of Agile development, allows teams to check and re-check issues of safety and cybersecurity. In addition, the cross-functional nature of Agile means that engineering teams can and should work together with cybersecurity experts in the normal course of development, to ensure that secure architecture is built into the application rather than imposed from outside after the system is completely designed.

InfoQ: What's your advice for safety-critical industries that want to move towards an agile approach?

Shoemaker: Accept that the transition to Agile takes time - it’s not like flipping a switch.

Understand that Agile is a mindset, not a cookbook: every Agile transition requires tailoring to the company, the industry, and the regulatory environment.

Recognize that applying the Agile mindset will affect just about every function in the organization in some way - not just the software team.

Van Schooenderwoert: I agree with Brian and I’d just add that someone has to step up and be a leader for agile change. This cannot happen by making a policy change and sending a memo around. Unless someone leads it in a genuine way, it will not happen.  Experience has shown that it takes anywhere from 18 months to 5 years or more for very big organizations. 

As an external coach I see this all the time. In a company where the founders are there, and they dig in to really learn what agile is - that’s a good sign. In a bigger company, it might be a VP or a Director who takes initial interest and then recruits allies in neighboring silos. That can certainly work - but it’s because someone personally stands up and champions agile.  Even better if several people do!  But if they try to leave it entirely to the outside coach or to the hired consultants the way you might do if you’re simply training to get a new skill, then that’s not going to work - unless it inspires leaders inside the company to step up!

About the Book Authors

Nancy Van Schooenderwoert (@vanschoo) pioneered Agile practices for embedded systems, hardware, and safety-critical products. She is a regular presenter at Agile-related conferences worldwide, and principal coach at Lean-Agile Partners, Inc. Van Schooenderwoert is a founder and past president of Greater Boston’s premier Agile user group, Agile New England.

Brian Shoemaker (principal consultant for ShoeBar Associates) provides consulting services and training in computer system validation, software quality assurance methodology, and electronic records and signatures. His clients include companies in clinical diagnostics, medical devices, and clinical-trial data management.