The list of blog posts I intended to write on the subject of agile development for medical devices is now complete.

As my career has moved to other positions and other industries, it’s unlikely that I will write new posts here.

I’m totally convinced that agile development is the way to go to reach true quality and safety. I hope that fellow medical device software builders will find useful guidance in these pages.

Cheers

For agile medical device designers, specifications are hard to grasp because of (yet another) contradiction between two seemingly opposite viewpoints: laconic user stories handwritten on post-its, as promoted by the agile movement, versus validated, traced, systematic requirements, as required by regulations. In this post, I’ll try to reconcile them by analyzing why specs are useful and give practical tips on how to handle them (people, lifecycle, tooling).

 

User stories are insufficient. I love user stories at the start of a project to understand the main features as input to architecture and overall project effort estimation. But they prove insufficient for implementing medical devices (where full traceability between test cases and requirements are mandatory) and systems (people from the hardware and system teams need some firm anchor points in the expected software behavior to do their job – their cycle times are so long they can’t cope with never-ending change). Formal specifications are a must-have for medical software design. They are a more detailed view of business needs than user stories (if I look at my projects numbers, the typical order of magnitude is ten requirements for one user story), and typically linked (via a traceability system) to the user story they explicit. User stories and specifications are two forms of user needs formalization that serve different purposes.

Specification team. Specification and development need different mindset and aptitudes. Good business analysts have excellent social skills: they enjoy talking, they make other people instantly feel at ease and tell the short story long, they ask redundant questions to spot contradictions, they have excellent writing skills to express complex stuff in a concise, understandable, testable manner. Developers, on the contrary, usually enjoy sitting alone in front of a computer, immersed in a delicious sea of abstraction where things are perfect and rules are absolute, in a state of intense concentration – the so-called zone – from which they reluctantly and grudgingly get out, incurring high task-switching costs. People skilled in both fields exist, but they are quite uncommon. These activities entail so different states of mind that I recommend specialization. In addition, developers are often harder to hire, thus more expensive than business analysts: scarce developer time should be used wisely.

Specifications lifecycle.

• Specifications are to be written before coding. It’s an order of magnitude cheaper to change specs than code. The idea behind specs is to see the big picture before getting into gory implementation details, spotting far-reaching consequences with high impact on design very early on. In my experience, business analysis should start two or three months before coding, to let time for the dust to settle, for people to reach consensus, for obscure details to be fully understood.
• A good technique is what one of my teams call SpecDays (as a pun to Microsoft TechDays): a little slideshow showing (hopefully with diagrams and mockups) a digest of every feature to be implemented soon, so that each team member has a basic knowledge of it.
• One developer should thoroughly analyze every spec. Developers are excellent at spotting contradictions and neglectedly dealt with edge cases. More importantly, with their knowledge of software design, developers can estimate the implementation cost of every requirement, and maybe negotiate one or two tough ones out of the spec to maximize bang-for-the-buck. Moreover, this study of the spec will greatly improve the precision of the estimation of the tasks required to implement the user story at planning poker time.
• The spec should be mature at the start of the iteration where it is implemented to avoid costly rework. But it shouldn’t be formally validated. A couple of requirements should still be allowed to change during implementation – especially if changed is asked by developers when encountering some unforeseen hardship. If marketing changed its mind about a feature during the iteration, I would tend to refuse the change request – it would need additional analysis before implementation.
• One very effective practice is challenge by functional people: as soon as a developer has something more or less working on his or her computer, the person who wrote the spec and ergonomics comes on the developer machine and plays with the app. This is a fast way to ensure that the spec was good (errors found then are late, yes, but they could be later), ensure that the developer has correctly understood it, and find a couple of bugs on the spot. All this before committing to the CI.

In medical devices, because of the need to have requirements detailed enough so they can be traced back to test cases, you might end up with a huge amount of them. For example, I have a project with about 4 000 requirements. Tooling is paramount to manage that sheer quantity. Don’t write specs in a word processor: find a good tool that can get you somewhere by providing automation facilities. For example, in Doors, my teams export traceability info to generate a traceability matrix and use custom fields and views so that there is spec reuse across projects to match the underlying reuse in code.

Another plus of specs is to be understandable by people outside the development team (marketing, technical writers, support). If you don’t write specs, be prepared to spend a lot of time repeating what the software is supposed to do.