Part 5: Agile Hardware Development – Why It’s Important to Iterate a Design
In the Agile Manifesto, Agile Values are defined by a series of preferences:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
All of these values can be applied to the development of hardware, but as others have noted, hardware is different in procurement and changes lead times, component costs, and the diversity of disciplines working in the team. Daily stand-up meetings may not be able to include the whole team. New working deliverables can’t appear after an all-nighter. Making dramatic changes late in the game can be a lot harder because component interfaces can be more complicated.
Medical device projects face additional regulatory requirements that make it hard to adhere to some of the values. One can’t work without a plan or comprehensive documentation (at least of the final product), development contracts are required (as is vendor qualification), and adherence to defined processes is beloved in the hearts of device manufacturers (and enforced by their Quality Management Systems).
So, with all these obstacles, what parts of the Agile approach can be applied to hardware development, specifically medical device hardware? DeviceLab does the following things to implement Agile values in our work:
- We take care in establishing our project teams to select not only the right technical background, but also the right capabilities, desire, and fit with the rest of the team. We collaborate very closely in a common workspace and with frequent client contact. Our telecommunications infrastructure promotes high-bandwidth exchanges.
- Comprehensive documentation, unfortunately, is a requirement in medical devices. We can’t really value it very much, but we can be efficient about how much we do and when we do it. Lots of important design questions in a project can be answered in a Research Phase prior to invoking Design Controls, which significantly reduces paperwork. The emphasis on working product over comprehensive documentation is something we respect with a focus on the frequent delivery of working components and subsystems in a series of prototypes with ever-improving fulfillment of design requirements.
- DeviceLab believes that frequent client feedback is essential for success in our projects. We find that it’s better to have development contracts which don’t tie down requirements too much too soon, and evolve the plan as we go. We meet regularly with clients so that they know exactly what’s going on. When the client is in the loop, and trust is earned, contracts can be less prescriptive and thus more flexible. And, everyone benefits by spending less time on tracking and haggling over numbers that don’t measure success.
- QMS regulations require that all medical development projects must have a plan and that you actually use it. However, they don’t say a whole lot about just how detailed your plan must be. They do say that plans can be revised during a project and encourage you to do so. Everybody knows that things change during a development project. You change course, like choosing to do something in hardware instead of software. While the end device may look identical to the user, the development plan will be much different. The trick to balancing these competing factors lies in developing plans that acknowledge possible forks in the road and don’t contain unnecessary detail in future phases. We then make it easy to revise the plan and review it regularly as we work through the phases. For example, as we’re wrapping up the Beta Phase, we’ll update the plan for Pilot Production phase from a simplified placeholder to a real plan for the upcoming weeks or months.
It may seem like the dogma of Design Controls is incompatible with the Agile Manifesto, but it turns out that you can adopt a lot of Agile thinking in medical device development. It’s really more about teamwork and the process of doing development projects, so much of the Agile mojo is available. See the Process page on our website for more information on how we do things.
Following that line of thought, our next post is about project management specifically. We’ve done a whole lot of projects at DeviceLab, so we have a few thoughts on the matter…