Agile principle 2: Welcome changing requirements, even late in development.
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:
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.
Inevitably there will 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 change.
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
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 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.
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.
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 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.
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.
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.
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.
In Part 5 and Part 6, we look at the third and seventh Agile principles.
Agile Development
Applying Agile Values to Hardware Development
Agile Principle 1: Early and Continuous Delivery of Value
Agile Principle 2: Welcoming changing requirements
Making Hardware Development More Agile
Early Learning in Hardware Development
Agile Principles 4 - 12 to Hardware Development
Guide to Kanban
Guide to Applying Agile to Hardware Development
