We agree. Hardware product development is different than software! So when we apply Agile principles to hardware, we need a different approach.
This series is a comprehensive review of Agile and how to apply Agile to hardware product development. We look at which Agile Principles work in hardware, which don't and why, and explore best Agile practices for hardware product development.
In this part, part 4 we delve into the second Agile principle, welcoming requirements changes. We share the reasons why change is harder in hardware product development and what we can do about it!
We've also put together an easily sharable eBook on applying Agile to hardware development.
So how can we adapt to changing requirements in a hardware world?
Agile principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Software and hardware product development teams share important attributes. It has taken us decades to realize this, but now it seems pretty obvious. These attributes are:
- we aren’t perfect
- we cannot predict the future with 100% accuracy
- and no matter how much we try, we can’t think of everything.
The fact is, we don’t know exactly what our customers’ needs are or the best way to satisfy their needs. Not only do we not know exactly what they need today, we don’t know what they will need by the time we are done developing a solution, because our customers and market are constantly changing.
As imperfect as we are in our assessment of external customer needs, we are also imperfect when it comes to understanding our internal customers’ needs. Production, sales, distributers, and field service often wish we would have done some things differently.
So in this environment, there will inevitably be late requests for changes, and our choices are to either make the change or live with the consequences of not changing - lower revenues, lower quality, higher Cost of Goods (COGS), lower profits, a bad reputation in the market, and sometimes, eventually, our company’s demise.
Often the consequences of not changing are worse than the pain and cost of changing. This gives rise to the 2nd Agile principle, welcoming changing requirements.
To maximize profit, we need to welcome at least some changes even late in development. In hardware development, our challenge is to identify these changes as early as possible, enable changes which are easier and more cost effective, and to know when to change and when not to.
Understanding the cost of delay and its impact on profit
Whether we are developing software or hardware, some changes are not worth the time and cost required to make the change. We must trade-off the costs against the value of increased sales, quality, and customer satisfaction. For an extended look at how we do make project trade-offs based on the economic impact, please see the series on Cost of Delay and Economic Decisions. Here is a high-level summary of cost of delay and economic decision making.
We can easily see the difference between changes which are worth making and those which are not by calculating the value and the cost associated with that change. Many cases can be analyzed using this simple formula for the Economic Value (EV) and ROI of a change or decision.
EV = SVS * ∆V + SPS * ∆P - COD * ∆D - UCS * ∆C - ∆E
ROI = EV / ∆E
SVS, SPS, COD, and UCS are Sales Volume Sensitivity, Sales Price Sensitivity, Cost of Delay, and Unit Cost Sensitivity, respectively. The other terms (∆x) are what we refer to as the ‘Economic Variables’.
∆V = Increase in Sales Volume (decreases are negative)
∆P = Increase in Sales Price (decreases are negative)
∆D = Launch Delay (earlier than current date is negative)
∆C = Increase in Unit Cost (decreases are negative)
∆E = Additional Project Expenses (savings are negative)
If EV is significantly positive and ROI is sufficiently high, we make the change. Otherwise, we do not.
The difference between hardware and software
The difference between hardware and software changes becomes clear when we look at this formula.
In both software and hardware, the requirements changes referred to in principle 2 almost always increase Sales Volume or Sales Price. And they almost always increase expenses. They may or may not cause a launch delay.
In hardware product development, they often increase our unit cost (COGS). The difference between hardware and software in accepting changes appears in the launch delay and unit cost factors.
Launch delay is typically larger in hardware
In cases where the product cannot be released until the change is made, that change may delay the release of an entire product. The cost of delay of software products can be quite high. Fortunately for many software companies, there is often the option to roll out the change later in a future software update, so we can avoid a large delay. We can deliver to our customers the value we have developed so far, and then deliver them additional value later.
But in hardware development, we cannot usually update our customers’ product later. When there is firmware or software involved – we can sometimes update those pieces of the product. But for changes which involve the physical components, the change more often results in a delay of the entire product.
Not only do we more often need to delay the release of our hardware product, our delays are often longer. This is a result of two, specific root causes - more limited modularity and procurement and integration time.
More limited modularity
The more modular our product the fewer pieces we need to change when a requirement changes and the faster and easier the change is. However, the more modular our product, the higher our unit cost and lower our performance (sales volume and/or price), because generally we need additional components and additional assembly time. These days especially, smaller, lighter, and cheaper is what sells, but modularity tends to make our products larger, heavier, and more expensive.
Because of the cost-and-performance-limited modularity of many hardware products, our products tend to be highly integrated. Therefore, when something needs to change, we end up needing to change a larger percentage of our product.
But that isn’t the biggest difference.
Procurement and integration time
Procurement time, in my definition, is the total time between an engineer changing the design drawing and an updated part being in-hand, ready to integrate (assemble) into our product. It usually includes drawing release, quote, purchase requisition approval, order, receive, and inspect steps. Sometimes it includes other steps such as bench test, stock, kit, and more.
Any given part change can require (rarely) days, (often) weeks, and (sometimes) months of procurement time to get our updated parts ready to integrate. Where software has at most a few minutes of time to ‘compile’ before integration, hardware teams typically have weeks.
In my definition, integration time is the time from when the part is ready for integration to when it is fully integrated and ready for test. In hardware, this is assembly time. When there are assembly problems, it includes the time it takes to solve those problems and get ‘ready to test’. This is often hours, days, or sometimes weeks. In software, system integration also exists, but is measured in minutes or hours usually, and sometimes days.
Hardware changes are typically less profitable
In summary, the time between ‘design’ and ‘test’ in hardware is necessarily larger, mostly because of the procurement time. This makes the delay we incur with hardware changes larger, which increases the cost and reduces the economic value of the change. As a result, fewer of the changes we would like to make turn out to be profitable.
Because of the lower cost of change in software development, late changes are generally more profitable and ‘welcoming change’ is more often the right thing to do. However, hardware teams are more often stuck between a heavier rock and a harder hard place. The rock is the cost of making the change and the hard place is the cost of not making it. Very often, both of these costs are high, unless we are deliberately careful early in development and are prepared for them.
How do we better prepare for change in hardware product development?
There are three keys to being prepared for changes. There are a lot of details behind these which I will need to reserve for a future series. One key is to find places to establish more modularity in our products – places which have low impact on our performance and are cost-effective. An important part of this is to create sufficient margin at the interfaces.
For example, if the height and width of our product are important, but depth doesn't matter as much, make the product a little deeper than you may think necessary and leave some room for the circuit board to grow in that direction. Often we can reduce the cost and improve the performance later, when the changes have subsided and we have greater confidence we no longer need the modularity and margin.
A second key is to establish, early, which requirements we believe are subject to change, and which components would be likely to be impacted by those changes. These potential requirements changes represent risks to our project and can be processed along with the other project risks, where identifying the impacted objects should be standard practice.
The third key is to combine the first two keys and deliberately find ways to establish modularity in those risky places where we can expect to change. Make it easier and faster to make the changes you expect you will probably need to make. It is worth a little more cost in these areas to enable fast changes.
There is a fourth key which is less about being prepared for late changes and more about avoiding them. This key is to have a good, healthy project risk management process and use it to learn earlier. Deliberately identify where the uncertainties lie, as mentioned in the second key. Then deliberately find ways to eliminate those uncertainties before you get too late into the project. A key piece of this is to take a Lean Startup approach, and get an incomplete product into the hands of some customers early and often.
And of course we must have our economic models which we can use to quickly and effectively determine which changes are worth the cost of change, and which ones are not.
Adapting Agile principles to hardware product development
I would offer a slight but important modification of this principle for use in hardware development. Instead of “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” I would say:
Enable and welcome profitable changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
We can often see potential changes early enough to enable them and make them profitable. And we can easily build economic models which help us see which changes to welcome.
It’s true. At playbook make some pretty significant claims regarding Playbook’s ability to shorten development cycles using Lean and Agile applied to hardware development. Watch the demo video, Part 1 and 2 to understand:
Part 1: Two paradigm shifting concepts around what causes late products.
After watching Part 1, have a look at Part 2 to see how Playbook uniquely solves for these problems.
Alternatively you can download the Applying Agile to Hardware eBook.
In Part 1 of this series, we share the top-3 reasons why hardware is different from software product development. As a result, we concluded that a pure Agile approach doesn’t fit well in the hardware development.
In Part 2 we look at the four Agile values, and how the top-3 different conditions in hardware development impact how Agile values are applied in hardware product development
In Part 7, we conclude the discussion of how to apply Agile to hardware product development by covering the remaining principles, 4-6 and 8-12.
Editor's note: This post was originally published in 2015 and has been updated for accuracy and comprehensiveness.