Contact Company
“Agile development for hardware will never work.”
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 use Agile to reach new markets, generate new ROI, and solve problems that have left some engineers stumped for decades.
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 repeatedly, 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.
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 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 training as you go, ensuring that you’re building higher and higher quality products with each iteration.
Get Your Team to Buy-in Early
Engineers can be a stubborn bunch. Telling a team 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.
Don’t Only Pursue Agile to Get “Faster”
Agile development is often mistaken for getting 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 result of a well-established process, but it isn’t Agile’s core benefit. There are multiple benefits to adopting Agile methodologies, including more robust client and team communication, better creativity, 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.
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 consider both the specific challenges of developing hardware and the needs of your organization.
By tailoring your Agile practice to your organization’s specific needs, 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 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! Agile hardware is possible and 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?
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 guide the team as they do their development.
There’s usually more than one way to achieve what your stakeholder is trying to accomplish. Focusing on what they want to do rather than how you should do it allows the team to have more creativity and open the door to innovative ideas.
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 are 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?
These cumbersome reviews can be replaced with a two-pronged approach:
- Continuous pairing and review among your team. Any time an engineer makes a discrete bit of progress, they pull in another engineer on the team to take a look. They can even reach outside your team to pull in a subject-matter expert. The idea is to make these touchpoints continuous and a natural part of the working process. These sessions serve two purposes: they provide real-time feedback which can catch issues early, and they help disseminate design knowledge through the team.
- Keeping your stakeholder(s) constantly involved. Stakeholders should be meeting with the team daily, even just for 15 minutes. These touchpoints allow them to keep up-to-date on the latest designs, and also provide direct feedback to the team about which features are — or aren’t — important.
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 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.
The key to breaking hardware in the Agile process is to do it early and often. 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 and devastating to the team and the organization. This may sound pricey, but you’ll find it saves the organization money in the long run.
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 six 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 massive payment in the end.
There Are No Absolutes
This is just the start of the discussion about how to apply Agile development practices to hardware. Until then, remember: never is an absolute. And when you’re building hardware, nothing is ever final.
Latest IoT News
