Do you believe in the Easter Bunny? Do you believe in the Tooth Fairy? I believe that *next* year is the year for a championship winning Cleveland sports team.
History is littered with famous software project failures; the Obamacare website, Heathrow airport software, defense projects like the F-35, maybe your last medical device software project... With these examples, do you believe in a predictable software process for your medical device? Hmmm...
It isn’t that the software industry does not know how to do a predictable software project that delivers a quality product on time. The various methodologies and practices that came out of the Agile Manifesto such as Scrum and Kanban lead to projects that are able to predict their outcomes reasonably well.
However, some of the ideas developed in these methodologies can be difficult for medical device software. For example, the concept of releasing a minimum viable product with frequent small, regular updates for an embedded medical device is tough. The minimum viable is usually a long (not minimal) list. Frequent updates can be difficult if there is not an easy way to upgrade. This is further compounded by long regulatory timelines.
A Process
Lets say you are given a list of required features, a target submission end date and a development process that on its surface is a waterfall process with several phase gates. Lets discuss some of the techniques from the Agile methodologies to deliver your product in a predictable way.
How High Is the Mountain
First thing, create your stories on a board. Stickies or Jira or whatever is not super important. Organize the related stories into epics. Put all of the work you need for the minimum viable product into stories. Make it as fine grained as you can but at the beginning of the project there will likely be a number of things you can’t break down to small pieces yet.
You should be able to loosely size all of the stories at this point. Some techniques folks use to represent size of work are t-shirt sizes s, m, l, xl, xxl or dog sizes Yorkie to German Shepherd to Great Dane. The idea is that people are good at relative sizes for work but not at estimating absolute time to complete. At this point you can assign relative numbers to the sizes. One technique is to use Fibonacci numbers 1, 2, 3, 5, 8 so that sizes are pretty different from one step to the next. This is an arbitrary scale. It does not mean anything on the calendar.
Definition of Done
You also need to define done for a story. My recommendation is that done includes almost everything required by IEC 62304. Software requirements and risk analysis for the story should be there to start the story, then to finish; code, unit test, code review, static analysis, updated integration test, formal verification protocol for the requirements and a passing run through of the verification. If you separate verification stories from coding stories this causes issues in my humble opinion.
Land Mine - Schedule
What happens if your project manager asks when will you be done on the calendar at this point? If you have a new team or new technology, you really can't answer. Even though you have a rough estimate of the size of the mountain, you don't know how fast you will be climbing the mountain yet. If you have a consistent team and a consistent set of work you can use this knowledge from past projects to give an estimate.
Getting Started
However you size things you will be able to get the project going at this point. Work with your stake holders to decide what are the most important tasks to do first. Possible landmine here: your stake holders want some feature for which the whole software infrastructure does not exist. My advice is to get as much of this infrastructure as possible in place before starting on the user facing feature stories. It is very difficult to get those user facing feature stories in place without the underlying support.
Time Estimates
To estimate time you need to do several weeks of consistent work to be able to establish that a Yorkie sized story takes a certain number of days. At this point, you know how long it will take to climb the mountain assuming the pace stays the same. Of course, you want to do everything you can to speed up so keep track of the Yorkie/ day speed and improve things to get it faster.
Phase Gates
The most important phase gate is when to start verification. If you follow this approach verification will start when all of the stories are complete. Based on this approach, verification will be relatively easy because you have already written the protocols and dry run them during the story flow. You now just need to do it for real. Of course, there will be issues but they likely will be small issues related to integration.
Believe
Will the project be easy, no. These steps just barely scratch the surface of all that will be required. However, if you follow these steps you will be on the road to believing in a more predictable software process. Now about that tooth fairy...
Comments