Applying Agile to Hardware Development (Part 4)

In this series we look at how Agile Software Development, as defined by the four Agile Values, Twelve Principles, and many Practices, work in hardware new product development projects that involve physical components (sometimes called Integrated Product Development). We look at what applies, what doesn’t apply, why and explore optimal methods for hardware product development.

In Part 1 of this series we covered the top-3 reasons why hardware is different from software product development -- so much so that a purely Agile approach doesn’t fit well in the hardware product development world. The reasons cited were component procurement time, component cost, and the variety of skills needed on most hardware development projects.

In Part 2, we reviewed the top-level definition of Agile, the four Agile Values, and how the top-3 different conditions in hardware development change these values.

In Part 3, we started looking at how the twelve Agile Principles are impacted by the conditions of a hardware development system. We reviewed the first principle about satisfying customers through early and continuous releases.

In this part, we delve into the second Agile Principle -- welcome requirements changes -- and find clear differences between hardware and software development that necessitate a change in our approach to maximize our profits.

Agile's Second Principle

Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

Both 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 that 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.

Not only are we imperfect 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.

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 principle of Agile, and it applies in hardware, just not quite as often as it does in software. Yes – even in hardware, to maximize our profits, we need to welcome at least somechanges even late in development. Our challenges are 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.

Cost of Delay is the Key

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 this objectively, please see the series on Cost of Delay and Economic Decisions. I will summarize here.

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

Where:

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. And in hardware product development, they often increase our unit cost (COGS). The difference between hardware and software 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

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.

Implications

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 to be prepared for it.

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.

Alternative Principle for Hardware

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.

Want to learn more about Lean and Agile project managment for hardware teams?   Watch our on-demand webinar series on Lean project management.