This is a guest post from Jason Swoboda, general manager of the medical device engineering firm, Velentium. It originally appeared on their blog.
Medical device developers face a common challenge: Harnessing the best ideas from the Agile methodology on projects that, because of their regulatory environment, appear to demand a classic waterfall model.
It’s not that the classic waterfall model is bad. Among other advantages, it’s a very clean way to visualize and map a complicated process. But anyone familiar with the debates surrounding development models is aware that, as with all models, the waterfall model has limitations. One of the first and most frustrating limitations that developers frequently encounter with the classic waterfall model is its demand that requirements be nearly complete before design can start.
“I can’t move forward until you deliver complete requirements,” the developer says to the end user.
“I can’t clarify requirements any further until we see a first-pass iteration of the product,” the end user responds.
“But I can’t develop an early version of the product without knowing what I’m supposed to make!”
At this point we no longer have a waterfall model; we have an eddy. We’re caught in an infinite loop and we haven’t even made it out of phase one.
The waterfall model is laid out the way it is because, when it works, it helps developers minimize waste and forestall misunderstandings. Clean labels and discrete phases should also, in theory, ease workloads for documentation, oversight, compliance transparency, and process improvement reviews. But actual conditions rarely conform to these convenient patterns. When they don’t, we’re confronted with a choice: attempt to force conditions to fit the expected pattern, however frustrating and inefficient that may be… or adapt on the fly as best we can.
Learn how to avoid common pitfalls of the Agile methodology in embedded systems by watching our webinar.
That’s why the Agile methodology is so appealing: it offers options that anticipate and prevent the bottlenecking and potential crisis points to which static development models are normally vulnerable. But which approach is right for medical device development?
Velentium believes that if you become too attached to any one model — even one that has “agile” in its name — you’re no longer “agile” by definition. Rigidly adhering to a single approach for every effort by definition cannot be flexible, speedy, and nimble.
At the same time, Velentium is also a company whose principles dictate their practices. So, here’s their guiding star: take a continuous deployment approach to projects. Focus on delivering value as early as possible, and then adding value iteration by iteration until the project is completed. They shed light on their development practices in the text and models below.
Velentium’s Iterative Development Process
As we develop sequentially around these quadrants, the first question to ask is: What’s the smallest slice of the final product we can build that contains a basic version of the most important functions of the whole? (Randy Armstrong’s “Know Your Why” is really helpful here). The answer will guide us through our first rotation. Then, as we prepare for the next turn around the spiral, we determine which of those functions would be the most valuable to expand first. What’s our next benchmark? Which additions will enable testing we can’t meaningfully conduct yet? What does the end user need to see first? What will help clarify requirements or refine project scope? If the project were unexpectedly cut short immediately after the next iteration, what would be the most valuable functionality we could implement by then? These are the questions that will guide our decision-making for what to do at the outset of each development round or sprint.
This process involves key stakeholders, to whom iterations are shown for feedback at regular intervals. Development proceeds in partnership, with open lines of communication and process transparency.
If you overlay this process atop the classic waterfall model, it looks like this:
It still starts with the requirements. We want them as complete and as clear as possible. But we don’t let compiling them exhaustively impede forward momentum, and we don’t expect them to remain static for the duration of the project. Instead, we anticipate changing needs due to evolving market conditions, new research or regulations, and clarification achieved through the development process itself.
We’ve found it’s important to chart the course as well as you can, start moving, and be ready to incorporate new data and updated information into a dynamic master plan as you go. So, in the midst of lingering unknowns on requirements, we move ahead to early design. We let design (and design feedback) inform and complete our requirements.
Then, when we move from requirements and design to implementation, what we or our clients learn during implementation may cause us to revisit requirements and design, and so forth. As we move through iterative development — always seeking to deliver value early and add value often — we loop through project phases in progressively longer loops, all the way into validation. We never want to get bogged down any individual step. At the same time, we don’t want to miss an opportunity to add value because we’ve arbitrarily “moved on” from a previous phase: we believe those decisions should be governed by project scope and cost/benefit analysis, not workflow theory.
To learn more about implementing the Agile methodology into your process, download our white paper, “Agile for the Enterprise: 5 Steps to Helping Teams Move More Effectively.”
