Use Scrum to Say Goodbye to Risk in Hardware Development

Companies who build hardware often ask if it's possible to benefit from Scrum. In order to answer this question, I need to first introduce you to my friend Risk.

Risk is a terrible friend. Risk likes to keep information about the future from me and shows up when I least expect. Risk has a very long career history in product development. I'm guessing you know Risk, too. In this article, I will explain how Risk shows up in hardware development and how Scrum can help keep him at bay.

If it's difficult, do it faster

Risk believes he's funny. Risk doesn't care if you're building software, hardware, clothing, or cookies. He doesn't care if you use Scrum or a phase-gated development process like waterfall. Without perfect knowledge of the customer, your market, or your technology, you can count on Risk showing up unannounced.

There are many types of risk to consider: If you don't know your market, you run the risk of building the wrong product. If a competitor beats you to market, you run the risk of your product not selling. And then of course there are people-related risks, such as when a team member quits, gets sick, is promoted, or just gets pulled to other projects. You also run the risk of vendors or suppliers delivering late parts or services, defective hardware, or an end product that doesn't integrate as planned. 

Scrum gets Risk out of development, though, by not only building very small features and solutions quickly, but also getting direct customer feedback before too much time has passed. The smaller the features and the shorter the time frame, the more risk is mitigated. The longer you go developing huge features or projects, more risk accumulates. This applies for any new product.

Scrum asks that you build a usable version of your product in 30 days or less, which fortunately keeps Risk busy doing other things.

But building hardware comes with its own unique challenges that often make sticking to this timeframe difficult.  These may include:

• Comprehensive architecture needs to be developed to avoid costly design changes later.
• A detailed design needs to be in place to help value engineers remove costs in part selection.
• It can take weeks or months to get a design back as a working physical prototype from 3^rd party vendors.
• Vendors may get parts back late.
• Vendors may deliver parts that do not work as they should.
• Testing cannot be done without a working prototype.
• Testing takes more than 30 days.
• Software cannot be written without target hardware.
• Hardware cannot be tested without software.

To speed up development and mitigate risk, you must find ways to solve those problems.

Let's break all the rules

If your present state is such that you cannot build anything in your environment in 30 days, how about in 45 days? How about in 90 days? 180 days?

For hardware teams, I'm a bit more forgiving when it comes to the amount of time it takes to deliver potentially-releasable increments, because let's be honest, many companies have made the 30-day timeframe impossible to do. These companies often use vendor-produced components with long wait times, which slow their ability to have prototypes made.

Rather than have a team of frustrated engineers, though, I ask the team to look for every possible way to shrink down features and lead times to eventually get to a place where 30-day incremental hardware enhancements are possible. What follows are a few ways you can do that.

Team building

Building products quickly requires a good team. Aim to build small teams of less than 10 people to keep communication flowing and dependencies removed. When you depend on another engineer working on their own schedule, or a QA engineer to test later on, you'll go much slower and find issues much later. These are the same problems software teams face, and I recommend the same solution. Bonus points if you're all in the same location with desks close to each other. To go fast you have to remove everything that makes you go slow, which sounds obvious, but it is an important reason to take inventory and make necessary adjustments.

A penny saved now will be a dollar spent later

Designing out costs too early in development can wreak havoc on teams later. The most common example I've seen is choosing a less expensive processor on a board that requires firmware development. This choice is not made for performance reasons or space concerns, but simply to save a few dollars per unit produced.

It's easy to see the extra profit that can come from saving $2.00 per board when you're shipping 500,000. But it's almost impossible to see the costs of development increase later when the less expensive processor requires firmware development in more difficult languages or frameworks.

When shopping for hardware, be sure to factor in the software tooling. To go faster, you want software languages that support modular development. You also want what's easier for engineers to read, to test, and to build automated tests. With higher quality software, you'll reduce time to market. Being late to market can cause a considerable cost of delay that will not be made up in lower costs per unit.

Rapid prototyping isn't fast enough

A huge problem I see for hardware development teams is getting prototypes built. If your design has to be sent out to produce electrical traces on a green board at one shop, then sent somewhere else to populate it with resistors, relays, chips, and capacitors, and then sent back to you for testing, it's easy to burn a month or more in every version produced.

If this is your life, I can see why you would wait until you've done many months of work before you send it off to build the prototype. But remember our mutual friend Risk? Risk doesn't care how much you did or didn't spend building the prototype. Risk loves that you have to wait four weeks to spin a new board. Risk loves to surprise us with unforeseen issues when the populated board comes back for testing.

If you want to eliminate Risk from your development process, you need to find ways to build physical prototypes sooner rather than later. This could mean building a rapid prototyping lab in-house with the help of a high-end 3D printer.

But, of course, balance the costs with the risks. Without a true understanding of what you spend every time you go back to the drawing board and delay the project further, you may think you're saving money with up-front efficiencies when you're not. Examine very closely the costs of delay every time a prototype comes back late and there are problems that require redesign, and factor this probability into your decisions to improve the speed of prototyping.

Final thoughts

Yes, you can build hardware using Scrum. Yes, it's worth using Scrum to build hardware to mitigate risk, reduce waste, respond to late coming changes, and rapidly innovate. The only question now is whether you see the benefits as being worth the effort to change how you currently design hardware products.

If you are interested in learning more about applying Scrum to hardware development, visit Responsive Advisors for more information about Professional Scrum training and certification.