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 show up when I least expect. Risk has a very long career history in product development. I’m guessing you know Risk too. In this blog, 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: The risk of building the wrong product; the risk of the product not selling because a competitor beat you to the market; there is also people-risk that affect teams when a team member quits, gets sick, promoted or just get pulled to other projects. You have vendor and supplier risks delivering late parts or services, defective hardware or an end product that doesn’t integrate as planned with yours. There are many risks in product development to consider, which makes hitting a date difficult.
Scrum gets Risk out of development by building very small features and solutions quickly and 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, to keep Risk busy doing other things. Building hardware requires additional hurdles which creates unique challenges to deliver a feature in 30 days or less. This 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 to remove costs in part selection
- It can take many weeks or months to get a design back as a working physical prototype from 3rd 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
Consider the above list just a bunch of impediments. To speed up development and mitigate risk, you must find ways to solve those problems.
Scrum was modeled after the way some of the best hardware teams in the world were creating new hardware products. So if you were thinking the ideas in Scrum can’t work in hardware development, just see “The New New Product Development Game.”
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 on breaking the rule in Scrum about delivering potentially-releasable increments in under 30 days because many companies have made this impossible to do. The reason it’s impossible is that they’ll have vendor produced components with long wait times that slow their ability to have prototypes made. Rather than have a team of frustrated engineers, I relieve this constraint with the commitment that the team will begin to look for every way possible to shrink down features and lead times to eventually get to a state where 30-day incremental hardware enhancements are possible. Here 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 boards. 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 want what’s easier for engineers to read, easier to test, and easier 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 and then sent somewhere else to populate it with resistors, relays, chips and capacitors, 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 4 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 than later. This could mean building a rapid prototyping lab in-house with the help of a high-end 3D printer. Of course, balance the costs with the risks. However, 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 found 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.