Medical device developers face a common challenge: How to harness the best ideas from lean and agile development methods on projects that, because of their regulatory environment, appear to demand a classic waterfall approach?
It's not that the classic waterfall 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 approach has limitations. One of the first and most frustrating limitations that developers frequently encounter with the classic waterfall is its demand that Requirements be near-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, we have an eddy. We're caught in an infinite loop and we haven't even made it out of Phase 1.
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.
That's why lean and agile methods appeal: they offer 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?
At Velentium, we think that if you become too attached to any one model – even one that has “agile” in its name – you're no longer “agile” in the actual meaning of the word. Rigidly adhering to a single approach for every effort by definition cannot be flexible, speedy, and nimble.
At the same time, we are a company whose principles dictate our practices. So here's our guiding star: we take a continuous deployment approach to projects. We focus on delivering value as early as possible, and then adding value iteration by iteration until the project is completed.
Image Credit: Jason Smith
As we develop sequentially around these quadrants, the first question we 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 our process atop the classic waterfall model, it looks like this:
Image Credit: Jason Smith
It still starts with 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.
For our next post, we'll look at how Velentium's agile development philosophy manifests week-to-week.
