Free Trial
Watch Demo

Eric Graves

Aerospace and mechanical engineer turned NPD systems engineer, Eric spends his time engineering better product develop systems, using PLAYBOOK as his tool of choice!

Search Result

Posts containing:

Applying Agile to Hardware Development (Part 2)

Eric Graves- 11/15/16 02:26 PM

We agree. Hardware product development is different than software! So when we apply Agile principles, we need a different approach.

How do you apply Agile to hardware product development?

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 2 we define Agile, the four Agile values, and how the top-3 different conditions in hardware development impact how Agile values are applied in hardware product development.

What's different about hardware vs. software product development?

Component procurement time, component cost, and the variety of skills needed on most hardware development projects are greater and represent in our opinion the top three reasons why hardware new product development is different from software. 

Let's look at how these differences impact Agile values.

The Agile values as described in the Agile Manifesto are as follows:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

As stated in the Agile Manifesto: “…while there is value in the [four] items on the right, we value the [four] items on the left more.”

Each of the eight values listed provides some benefit in software development, but often the value on the left is in conflict with the corresponding value on the right. For example, sometimes responding to change requires deviating from the plan. When in conflict, the left value is more important in software development (usually).

When I read these values, I see them as best practices - high-level best practices.

For example, it is usually better practice in software to respond to changes than to stick to the plan. This is better practice because it results in more profitable products, which is the goal.

Goals, values, principles, best practices, and system requirements are all different ways of saying pretty much the same thing at a different level. They are like floors of a building. The lower ones support the upper ones.

So, to me, best practices are simply lower-level requirements for a smooth flowing NPD system. And where there are requirements, there are usually risks. I will illustrate this point using a PLAYBOOK Requirements and Learning Map.

Requirements vary in value 

In both hardware and software development, requirements vary in value. In the figure below we show how we can indicate the importance of a requirement by where it attaches to the higher level requirement or goal.




Being a mechanical engineer, I think it helps to consider the value of the top goal as a weight being supported by the lower-level requirements, as shown below. The relative value of the lower level requirement is represented by the strength of the spring which supports the goal. The greater the value of the sub-requirement, the stronger the spring and the more weight of the goal that sub-requirement supports.




However we picture it, the Agile values indicate there is a differing value placed on each of these often conflicting requirements.

For Hardware development projects, we think it looks more like this:




Where the requirements on the right, namely process and tools, documentation, contracts, and following plans each support profitability more than they do in Software products. This is because the conditions of hardware development create different costs and risks, as depicted below. The negative impact of a cost and risk is indicated by where it is attached to the requirement.




Where there are additional costs and risks, the strength of that spring (value of that practice) is reduced. In order to support the same profits, the weight is transferred to other springs, which must be necessarily stronger. I will elaborate…

Individuals and interactions vs. process and tools

As team size and variety of skill sets increases, the number of interactions increases exponentially.

The greater the number of interactions, the greater the complexity of the system, and the more likely there will be communication breakdowns or individuals following a far-worse-than ‘best practice’ on something. As a result, development goes more slowly and company profits are reduced via Cost of Delay.

In order to combat this increasing complexity, a good framework of processes and tools which keeps everyone on the same page, in sync, using good practices, and communicating well is even more essential.

That said, most processes and tools are not very good at replacing individuals and interactions, so face-to-face, real-time communication is still often the fastest way to get something done. This is often true in hardware development as well. However, there are more people who are impacted by each piece of information, and a wider variety of backgrounds involved in the interaction. Some of these people will not be able to be present and interact when the change is made, and/or some words make less sense to people within other disciplines, so a good communication framework (processes and tools) are the best alternative. The key is to minimize the effort involved.

Working software vs. comprehensive documentation

It has been the dream of mechanical designers for over 20 years now to never need to create a drawing. We are still dreaming. Slowly, we are getting away from it, but we are still at a point where many companies rely on drawings to procure parts. This is one example of documentation we cannot yet eliminate, though we will keep working toward it.

In addition, as mentioned above, with larger, multi-disciplinary teams necessary for hardware development, we can’t effectively be in the same room at the same time, so documentation of decisions and changes is typically more valuable. The list goes on, and includes documentation about the design, the factors (knowledge) driving our design decisions, and the results of those decisions. While I know it is often difficult to look at some software code and understand what the person who built it was thinking, it is often more difficult to look at a mechanical or electrical design and gain much understanding and knowledge. Knowledge is often better transferred through documentation when face-to-face transfer isn’t possible.

In addition, as we will discuss more in later posts, one of the primary challenges in applying Agile to hardware product development is the difficulty of breaking down design tasks into small, distinct, manageable chunks. One good practice to resolve this issue is to capture what we really do, daily, so we can use that to guide the breakdown and estimations the next time we do something similar. Minimizing the effort required is key here, too, which is where a tool like PLAYBOOK can really help.

Because we are considering how these values fit hardware product development, we can replace ‘Working Software’ with ‘Working Product’. A working hardware product is certainly of very high value, too, despite the increased value of good documentation. Again – we just need to be careful to keep documentation effort at a minimum, so we can focus on getting our product working. It can be minutes a day, if we have the right framework and tools.

Customer collaboration vs. contract negotiation

This is one comparison which translates most directly to hardware development. Despite our best attempts we still cannot predict the future or read our customers’ minds very well in either software or hardware. Therefore, customer feedback is essential to insuring our profitability.

That said, the cost of customer collaboration is much larger in hardware development, largely because of the cost of the parts. Good feedback often requires expensive parts so customers can see, feel, and use our product, or at least a subset of the product. Our ability to get feedback is limited by how many test units we can afford to procure and have time to move around from one customer to another. Where the latest software can easily be provided to many people across the globe at the same time, hardware is not so portable – not until we invent teleportation, anyway.

Just as valuable as minimizing the effort involved in necessary documentation is minimizing the effort, delay, and expense cost involved in collaborating with customers. While we continue to make strides to improve customer collaboration, the benefit/cost ratio (value) of collaboration is smaller because the cost is larger. The benefit still outweighs the cost until you reach the point of diminishing return which comes earlier with hardware.

Responding to change vs. following a plan

Changing hardware is more costly than changing software. The cost and procurement time required to get new parts causes delays and involves scrap or rework costs. As a result, changing plans is often costly. One of the key ‘plans’ in hardware development is the ‘build plan’ – how many units of each product iteration will we build and test. Careful coordination of this impacts our ability to get customer feedback, find issues, and accelerate our project and profits. Late changes to the number of units we will build often causes delays and increases costs.

One part of the plan which is especially costly to change is the Launch date. If our marketing and sales departments, our suppliers, and our production facilities do not know when to be ready to ramp up, costly delays will occur. There is greater value to confidence in our launch date in hardware development. As such, at least some parts of the plan (the end date) need to be sufficiently accurate, early (so they can be followed without extensive costs).

That said, certainly increased flexibility and response to change is as valuable in hardware as it is in software. Again – it just costs more. Therefore, it pays to plan a little bit more up front. We will discuss this in more detail in further posts.


While the Agile Values do apply to hardware development, there is a smaller difference in benefit between the values on the left and the right, largely because the cost of achieving the values on the left is larger and always will be.

There are necessary, unavoidable differences in hardware development which produce additional costs.

Hardware development existed long before there was software, and many paradigms in software were born in hardware development. It makes sense that the Agile Values were established to contrast how software is different from hardware. So rather than attempt to transfer Agile practices directly to hardware development, some careful consideration about what the differences are, and what works and what doesn’t, will improve our results.

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.

Watch Demo

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.

Download my eBook - Applying Agile to Hardware Development.

In the next post, we will review the 12 Agile Principles, which again are simply underlying requirements for a profitable software product development system. We will discuss specifically how each of these 12 principles applies, or doesn’t, in a profitable hardware product development system. Stay tuned for Part 3

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 3, we begin to review Agile--principle by principle--and how the principles are applied to hardware. In this post we cover the first principle, delivering continuous work.

In Part 4, we delve into the second Agile principle, welcoming requirements changes.

In Part 5 and Part 6, we examine the third and seventh Agile principles which state that working product is the primary measure of progress. 

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 2014 and has been updated for accuracy and comprehensiveness.