Ask an Expert: Strategies for Successful Agile Hardware Development

How many engineers have I heard utter this sentiment? I may have even said it myself at some point. It’s almost a mantra among organizations that develop hardware. Many companies have been developing hardware for dozens, and in some cases, hundreds of years, and the idea that there might be a new, better way to do things can be hard to swallow. 

Believe it or not, it’s true. Agile hardware development is possible. Organizations are using Agile to reach new markets, generate new ROI, and solve problems that have left some engineers stumped for decades. Here at Very, it’s what we do best.

That said, uncertainty and skepticism of Agile development can be warranted. Many companies have tried and failed to implement Agile development practices for hardware. But if there is one lesson technology development has taught us over and over again, it’s that using the word never is a great way to get left behind.

How to Ensure Agile Hardware Development Succeeds

There’s no denying that Agile hardware development practices have had a tough go of it. Here are four strategies to ensure you’re setting your Agile process up for success.

1. Approaching Agile as a mindset, not a process

One of the critical mistakes newcomers to Agile (in both the software and hardware fields) make, is thinking that Agile is just another set of processes they can lay on top of their existing organization. Move around some furniture, take down your cubicle walls, call the recurring Monday morning meeting a “stand-up,” and you’re good to go! While these processes can be helpful, there’s more to them. 

Your best bet is to adopt Agile with the mindset that it’s a practice, not a process. As your experience unfolds, you learn, improving your practice as you go, ensuring that with each iteration you’re building higher and higher quality products

2. Get your team to buy-in early

Engineers can be a stubborn bunch. Telling a team that has been working together for years that they need to relearn the fundamental rhythm of engineering development can result in some push-back, if not open rebellion. Build in time for feedback and actively listen during the change from waterfall to Agile. Once your team can see the light, they’ll be amazed by the possibilities of Agile development.

3. Don’t only pursue Agile to get “faster”

Agile development is often mistaken as a way to get from a white sheet of paper to a piece of production hardware faster than you can today. While it is true that a mature and well-seasoned Agile team can often outpace a similar team following traditional waterfall methods, this is often not the case for a team that is still getting its bearings in a new development process. 

Speed is a fantastic end result of a well-established process, but it isn’t Agile’s core benefit. There are multiple benefits around adopting Agile methodologies, including stronger client and team communication, better ideation, and frustration reduction. Ultimately, the core concept of Agile is to net an incredible outcome by leveraging an intuitive, yet iterative, process. Speed is just the cherry on top.

4. Adapt Agile to your organization’s needs

People often assume that you can read one of the many Agile development books and adopt the structure wholesale without change. This fails to take into account both the specific challenges of developing hardware and the needs of your organization. 

By tailoring your Agile practice to the specific needs of your organization, you’ll see positive outcomes sooner, since they will more closely map to your traditional methods of hardware development. After all, a Minimum Viable Product is much different for a consumer electronics start-up than it is for a company that builds jet engines! 

Strategies for Agile Hardware Success

So, what can we do? Is Agile development for hardware doomed to be too difficult to implement?

Far from it! Here at Very, we believe that Agile hardware is not only possible, but can make the process of developing hardware more adaptable, more transparent, and, yes, maybe even faster. So how do you get it to work? We have a few ideas.

First, you need to ditch the two sacred cows of hardware engineering: pre-defined requirements and milestone reviews. 

This will not be easy. Both of these concepts are core to the traditional methods of hardware engineering. They are drilled into mechanical and electrical engineers from their first day of college and constantly reinforced throughout their careers. 

So, where to begin?

1. Focus on the what, not the how

So once you’ve tossed out your V&V matrix, what do you do? You talk to your stakeholders to get at the core of what they want the hardware to do. These features (what we would call vertical slices in Agile-speak) will be what guides the team as they do their development. 

There’s usually more than one way to achieve what your stakeholder is trying to accomplish, so by focusing on what they want to do rather than how you should do it, you allow the team to have more creativity and open the door to innovative ideas.

2. Replace milestone reviews with continuous touchpoints

Milestone reviews are another concept that is relentlessly drilled into hardware engineers. The dreaded “DRs”: SRR, PDR, CDR, DDR, MRR, TRR. Whatever your organization calls them, milestone reviews usually mean teams crunching to finish work and stressing over presenting slides to a stakeholder who may not have seen the design for months.

In short, it’s quite a time-consuming production, and I’m sure your team would be thrilled to get rid of it. Your stakeholder on the other hand will likely be less pleased. So what can you do instead of milestone reviews? 

3. Get OK with breaking hardware early and often

Another important aspect of using Agile methods with your hardware team is getting comfortable with breaking hardware-and breaking it often. 

I’m no psychologist, but I do know there is some deep-rooted part of the human brain that abhors seeing a physical object broken. In hardware engineering, broken hardware conjures terrifying specters like the Failure Review Board and Root Cause Analysis. 

Traditional hardware development programs might go months, or even years before a prototype is built and tested. A failure at that point can be expensive, as well as devastating to the team and the organization. The key to breaking hardware in the Agile process is to do it early, and often. This may sound pricey, but in the long run, you’ll find it saves the organization money.

For instance, a hardware failure after the product has already spent two years in design is catastrophic. But a failure one month into that same project can be instructive and taken in stride. 

A great real-world example of this is SpaceX. They’ve experienced some very public hardware failures. But by sticking doggedly to the mantra of testing early and often, they’ve succeeded in a way that traditional space-development organizations can only dream of. 

To implement this build, break, learn cycle, you should take advantage of the myriad of 21st-century manufacturing capabilities we have available (a topic we’ll cover in detail in another blog). You no longer need to spin up the manufacturing line or spend 6 weeks waiting for a piece of prototype hardware. In the modern world, even a complex machine part can often be obtained in a couple of days. 

Think of early prototyping as a fixed-rate mortgage and no prototyping as a balloon mortgage. You might be paying more per month with a fixed rate, but you won’t have to worry about not being able to afford that huge payment at the end.

There Are No Absolutes

This is just the start of the discussion about how to apply Agile development practices to hardware. I’ll be following up over the coming months with more details about our approach here at Very, and how we’re leveraging it to develop some of the coolest IoT hardware out there. 

Until then, just remember: never is an absolute. And when you’re building hardware, nothing is ever absolute.

KEEP READING: Find out how Very created Tattlebox’s first prototype using agile methodologies in just 15 weeks.