Agile for hardware design and specifically working prototypes and sprints.

Agile development is an approach traditionally applied to software development. It was implemented many years ago and still persists as one of the main avenues to software development.  As we’ve seen the trend from traditional, mechanical products to smart, connected ones, there’s a lot more software going into smart connected products. As a result, there has been an increase in software developers, and they are bringing their own standards to the industry.

Embedded software now plays a key role in this space, especially in getting it to run on custom target electronics. Given the difficulty of that issue, it’s driving all sorts of change in all of product development. Some of that has led to the adoption of Agile practices in hardware design.

How does that relate to working prototypes and sprints? There is this concept in Agile where you break up a project into two week sprints. At the end of the sprint, you will have achieved certain objectives, satisfying or fulfilling certain requirements, and will have a certain level of working product or prototype. In the software world, this would be represented as compiled software that would actually run. Maybe it’s hacked together, but it still runs, and it’s representative of the type of functionality you want to provide and deliver at the end of the project.

The same concept applies when you implement this to hardware and systems. For example, let’s say you want to create a working hardware prototype. With the improved capabilities of 3D printing and additive manufacturing, you don’t have to go to a supplier to get any of the items you need. Instead, you can print parts for your prototype with relative ease and have something that represents your final model.

In terms of an example for systems, you’d hook up a UML model for software with a breadboard for electronics as well as actuated components and 3D printed parts. It would be the equivalent of a hacked together working prototype of a system.

One of the advantages of this kind of development revolves around the ability to have multiple prototypes to work with. If the prototype works one week but doesn’t work the next after new parts or functionalities have been added, it’s much easier to narrow down the time frame of when a failure occurred and can be easily managed and fixed.

There’s also a larger implication with Agile development and how it is much more beneficial overall. In the mechanical design and electronics industry, there’s been this move to using simulation and digital verification all along the way of development until you get to the end. At this point, you need to build a prototype then go to testing. This is done to avoid many rounds of prototype creation, as they are being simulated rather than being physically built.

The issue is that if you’re waiting and waiting and waiting to do anything physical until the end, you’re setting up pretty high stakes for the prototype and test situation. What’s interesting with the working prototypes and sprints is that you have many validations along the way until you get to that final model. The stakes are much lower. You won’t be in a situation where if this prototype breaks, it might completely derail development. No, you’ve validated along the way that what you’ve built works and have a better idea of how to fix any issues.