Four Reasons Medical Device Companies Need Agile Development

[article]
Summary:

The waterfall style of development is so deeply engrained into the culture of medical companies that most can’t imagine anything else being used to develop software that has power over human life.

However I argue that precisely because of patient safety, medical device companies in particular need to adopt agile practices. I’ve seen too many bloated medical device project fail or limp across the finish line for causes that can be directly linked to the waterfall method. Specifically:

  1. Large Unprioritized Feature Sets. The extended detailed specification development phase prior to a waterfall project’s start tends to lead towards large lists of unprioritized features that are worked on in whatever order desired by the engineers on the project. Agile development on the other hand requires features to be prioritized and then worked on in priority order. This ensures that at the end of the project if a push comes to ship, the outstanding items are the low priority bells and whistles and not something that may affect patient safety.
  2. Bloated Architecture. The waterfall practice of trying to document and lock in a detailed design at the beginning of a project is often used by senior engineers to commit organizations to their favorite pet architecture projects. These architectures tend not to be the simplest most direct means to meet the project’s needs. Unlike the Big Up Front Design (BUFD) exercises favored by waterfall development, agile development favors lean emergent architecture concepts that recognize the fact that the best design is often not known upfront.
  3. Fragile in the Face of Inevitable Change. Waterfall projects tend to drag on even more than the average software project (see Unprioritzed Feature Sets and Bloated Architecture for some of the reasons). The long schedules mean high risk that the product developed may not meet changing market needs. When change comes to a waterfall project it’s treated as a broken promise and generates a lot of push back from engineers. Indeed the architecture built by engineering may have been built with the premise that the requirements would never change. Agile development expects changes in requirements and develops architectures and work strategies that can accommodate this change.
  4. Design Misses from Lack of Early Feedback . In a waterfall project people tend to put their faith in the specification and trust that a year or two down the line the engineers will deliver the product they imagined. There are two problems with this strategy. One is that there are many subtleties and details that can never be fully captured in a spec (if you could you could just compile the spec). The second is that it is impossible for most people (especially marketing and customers) to envision a product until it’s built and in their hands. Both of these things can lead to significant design misses. The agile methodology addresses this problem by frequent delivery of working code.

The problem with the waterfall method of development is that it is built on the following false premises:

  1. That all requirements are known up front and will never change.
  2. That it is possible before a single line of code has been written to envision in detail the one true best design that will last you through the entire project.

The agile process is built on the exact antithesis of these assumptions. It believes change is inevitable and design requires multiple iterations. We all know that once something is built it’s easy to look back and say what was good and what was bad. The waterfall method works at the exact opposite side of that experience curve and tries to get you to lock in your design and requirements at the point of maximum ignorance.

Just to be clear, it’s not that the agile method is against doing as much up front design and requirements gathering as you can. It simply recognizes that it is unlikely that this exercise will be perfect and therefore a process is required to address this reality. Specifically it time boxes the upfront blue sky period and proceeds with development on the highest priority items that

About the author

TechWell Contributor's picture TechWell Contributor

The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!