In the next three posts we discuss Agile principles and how to apply the principles in hardware development. In this post we look at delivering continuous value.
Agile principles
As a software company, our development processes use many of the best practices of Agile. To be clear, I think Agile is great for software development. Especially when we include under the Agile label the many enhancements which have been added over the years, such as Kanban and Definition of Done.
Agile is great for software because Agile values and principles were generated by software developers for software development. As a result, they are software focused. They were never intended to be applied to hardware product development which involves physical components. So we must look carefully at how they fit this different application, or we may cause more problems than we solve.
Agile principles adapted for hardware
Because of the clear presence of software in the Agile principles, I’ve provided alternate wording for our look at their application to hardware development. I’ve replaced the word ‘software’ with ‘products’ and ‘developers’ with ‘engineers’.
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable products.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working products frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and engineers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within an engineering team is face-to-face conversation.
- Working product is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, engineers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity--the art of maximizing the amount of work not done--is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Let’s look at each of these, starting at the top.
Agile Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable product.
In other words, our priority is to focus primarily on delivering valuable products to customers early and continuously.
When I read this, I see only one word which doesn’t exactly fit many cases of hardware development. I bet you know which word I am talking about.
Certainly, we can all agree that every product development company benefits greatly(profits) from having satisfied customers, and this only comes from delivery of value. And we can all agree that the earlier you deliver it, the greater the profits. (see posts on Cost of Delay.)
It is the continuous part of this principle which is not necessarily optimal for most hardware products.
Interested in understanding more Lean-Agile Principles? Check out our free Lean-Agile training on Playbook Academy such as Rolling-Wave Planning, Applying Agile to Hardware and Critical Chain Project Management.
Even among the most advanced product development companies, continuous delivery is rarely found to be the most profitable option. For example, over the four years of iPad sales, there have been only five different models, although the operating system has undergone more frequent updates. Toyota releases new models annually.
What are some of the root causes which result in less frequent releases becoming more profitable?
What is the cost of change in hardware development?
We can calculate the profit we expect from every new product, every new release of the product and every change to the product. In order for our business to be sustainable and profitable, on average, changes must pay us back more than what they cost.
Every change costs us something. In software, the cost of change includes labor to make the change, and where tests and releases aren’t yet automated, it costs time (money) to test and release that change. We often need to update training documents or videos, write release notes, and various other activities with each change.
In hardware, changes include the same costs as for software, plus additional costs. For example, for most changes there is cost in our supply chain for labor and materials involved in changing the manufacturing or inspection processes and tooling. For example, mold tooling for a new plastic injection part often costs many thousands of dollars. It can take weeks of sales of units made with these parts to pay for this tool alone. Then there are other parts’ tools, assembly tooling, inspection tooling, and test tooling.
As another example, in medical device development many changes involve hours, days, weeks or years of additional time and delay due to the regulatory approvals required. Most electrical devices must be re-certified by UL, CE, or some other regulatory body for some changes. The list of additional costs goes on.
Hardware products are highly integrated in nature
Another additional important cause of a higher cost of change is the highly integrated nature of hardware products. For hardware products, changes typically impact multiple (often many) components and processes. Software teams have long understood and been building modular architectures which limit the ripple effect of each change. Object Oriented Programming was born in the ‘50s.
Hardware teams have not yet solved the modularity problem because of the forces which push us away from increased modularity. Increasing modularity typically increases our Cost of Goods Sold (COGS), and degrades system performance including the often-important weight and size of our product. These forces counteracts the benefits of modularizing and pushes us back again toward costlier changes.
We will discuss modularity more in the next post, but the point is that the cost of change in hardware is typically much greater than it is in software. The higher our cost of change, the longer it takes to recover this cost and the longer the payback period of each new change and release. This, alone, is enough to lengthen optimal release rates. But that is not all…
Component cost (COGS) typically consumer 30% of product revenue
COGS of hardware products typically consume at least 30% of our product revenue (not including the capital costs of tooling). In most companies, this percentage is much higher. With increased COGS comes decreased profits from each unit. We have to sell more units in order to pay for the cost of development and change. This further lengthens the payback period and our optimal release cycle.
This is evidenced in our calculations for Cost of Delay for a new product release. When material costs are high and margins are low, the Cost of Delay is low. Because we make less profit on each unit, delaying that profit costs us less. As the value of releasing a new product early gets smaller and smaller, continuous delivery becomes less and less valuable.
The optimal release cycle for hardware
Cost of change has a large impact on the ability of software companies to deliver product continuously as well. The only systems which can effectively be delivered continuously are the ones where testing and release activities are automated. These companies have effectively reduced the cost of change far enough that continuous delivery is profitable. In software, by eliminating a primary root cause of change costs, it looks more like this.
Modularity still has an impact on the cost of change in software, but the impact can be low enough that continuous release of new product is profitable.
In hardware, the cost of modularity is larger, and the other costs are still present, so it looks more like this:
The root causes of Cost of Goods Sold and a higher cost of change is a fact of life in hardware products, and always will be. Rather than attempt to break the laws of physics, we should try to use them to our advantage. We cannot simply strive for continuous release. Instead, we must determine our optimal release cycle.
Certainly, great benefit can be realized by driving down the cost of change, and we will continue to find better ways to do so. However, along the way we must also find the optimal release rate. The more frequent the releases, the greater the sales, and the greater the costs as well. We need to strike the right balance in order to realize the greatest profits.
Agile principles adapted for hardware development
I would offer an alternative to the first principle which establishes (almost) as great a benefit in hardware as frequent customer releases do in Agile.
Rather than “Our highest priority is to satisfy the customer through early and continuous delivery of valuable products,” the alternative for hardware development might be:
Our highest priority is to satisfy the customer through early through continuous delivery of value.
The fact that it is not usually profitable to release hardware products continuously to customers does not preclude us from developing the product more continuously (in smaller batches).
For example, we often encounter companies developing a whole family of products at the same time. Even when we show them how de-batching the development of the items in the family will result in a faster completion of the entire family, it is often the case that those early products will not be released until the later ones are completed. The need to release the suite of products together is often driven by events such as Trade shows, Annual Sales Meetings, Christmas, and simply the end-of-the-quarter rush in production, among others reasons. While sometimes it is better to de-batch the release of products in a family, sometime it is not.
However, even though we may not benefit from releasing new products to customers continuously, we almost always do benefit from striving to deliver value to our organization on a continuous basis. However, the definition of value must change from being singularly focused on customers receiving products. Instead, the delivery of continuous value comes from continuous reduction of project risk.
When we strive for continuous delivery of value, we learn to de-batch our development processes. We de-batch our learning into more frequent and extensive testing, and we de-batch our Phase Gates into more individualized major milestones. The more continuous (de-batched) our risk burn-down, the faster the product development system will flow, and the earlier and more profitable our eventual product release will be.
Side note from my soapbox
Some people consider Gantt charts an indicator of an evil un-continuous waterfall process, which is thought of as the antithesis of Agile. However, it is not the Gantt Chart which is evil. It is the fact that, with traditional project management tools, we are forced to build plans that a single person can manage. Even then it is difficult to change the plans.
This results in less detail in the project plan (as one project manager is limited in their ability to manage more than a few hundred tasks), which pushes us toward large development batches. It is the large development batches which are evil. Gantt charts can be instrumental in continuous delivery of value to an organization and customer, as long as they aren’t overly simplified and batched into a few iterations.
In Part 4, we delve into the second Agile Principle : welcoming requirements changes. There we find clear differences between hardware and software development that necessitate a change in our approach to maximize our profits.
Related articles
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 Applying Agile to Hardware Development
Guide to Kanban
