Major medical device development is a complex and lengthy process with lead times of 3 to 7 years. Not only is the development slow, but it is often of questionable quality as well. In 2024, the US FDA attributes 30% of recalls by all medical device manufacturers to design issues.

Agile in hardware helps us address both lead time and quality issues. However, it is not a straightforward transition from software to hardware agility. The questions I get when working with Agile Hardware folks frequently remind me of the ones that I faced 20 years ago when I started with Agility in software. We look at software to find answers, but some are unique to Hardware Agile.

Let me start with people-related aspects first.

Culture

When we talk Agile, many Hardware folks tend to feel like this cat taken to a bath. Cat-parents, you sure know this.

Literally, a hardware department lead asked me, “Why am I here ?” at the start of an Agile training. By the end of the training, he was convinced enough to try implementing it in his team. Some become truly convinced, but many hardware folks tend to think of Agile as a software thing.

Sharing agile experiences from software is a good start, but it should soon be followed by tools and methods to address hardware-specific issues. Be aware that such knowledge diffusion into hardware does not always result in a positive view.

Competencies

Full-stack Software developers are common now, but not full-stack hardware developers -it’s a rare talent, if not impossible, because hardware disciplines are distinct – structural, thermal, electronics, plastics, VLSI, to name a few. The T in the T-shaped skills is rather narrow.

So, how often are you faced with a hardware team that is discipline-oriented, operating as an agile team that can pick any story off the board, or a multidisciplinary team with numerous dependencies?

The key is in creating team structures that address specific issues. For example, if you are trying to build competencies, then discipline-oriented teams are better, whereas if you are optimising for speed, then multidisciplinary teams are better suited.

Iterations

This is the most common challenge I get when working with hardware leaders and teams – “my suppliers take 4 weeks for what I can do in 2 weeks”. 

At its root, product development is uncovering a set of unknowns. Not everything needs hardware from suppliers – one can use simulation, 3D printing, green sand casting, among others.You don’t need to dismantle your supply chain, but many suppliers can deal with short turnarounds.

Hardware development is already iterative; we only need to find ways to get feedback faster.

Process

The cost of changing hardware rises exponentially fast, while software and firmware are more forgiving. For hardware, the cost of change becomes one of, if not the most important, factors.

Plan for feedback, taking into account the high cost of change, long lead times, or practically irreversible decisions, such as ASICs and large moulds, and plan low-cost change decisions around those. From my experience, the resulting roadmap will be very different from what you will see with phase-gate planning.

Medical device development may increase the constraints towards the processes used; however, there are no requirements that hinder good agile practices. Often, it is the interpretation of regulations and standards that creates hurdles to Agility.

No doubt, hardware agile has unique challenges. With right help, you can overcome those. Remember, we can adapt many solutions from software agile.