Playbook Logo transparent
Pillar-Agile_BG copy-1
Can Agile Values, Principles and Methods can be applied to hardware development? In part, yes! To meet the unique challenges of hardware
development, we find that some modification of Agile is required. In addition, because of its unique requirements, we conclude hardware
development is best suited to a hybrid methodology.
You can download the complete guide here
Download my eBook

Can Agile be applied to hardware development?

 

There is no doubt hardware product development projects can benefit from the application of Agile. In fact, we’ve adopted Agile practices as part of the Playbook Method. For example, holding daily stand-up (scrum) meetings, which create faster feedback loops and increase communication.

However, due to the differences of hardware product development vs. software development, we have found that hardware product development projects ideally require a hybrid approach that includes not just Agile but practices from Theory of Constraints, and Lean as well. Why?

Because hardware development is different from software development.

In this guide we begin with a review of the Agile Manifesto, its Values and principles and consider these values and principles vis-a-vis the unique constraints of hardware development. We found that some of Agile is applicable to hardware development and some of it is not.

Let’s begin by taking a look at the Principles and Values of Agile as described in the Agile Manifesto.

The Agile Manifesto

The Agile Manifesto prescribes four Agile Values and 12 Principles upon which Agile Methods are based. Let’s look at the Agile Values first, and the implications for hardware product development.

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

According to the Manifesto, Agile values the items on the left in each Value more than the items on the right. For example in Value #1, Agile values Individuals and interactions over process and tools. Interestingly, each of the Values listed above 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, when we look at Agile Value #4, sometimes responding to change requires deviating from the plan.

So, can Agile Values be applied to hardware development?

In order to answer this question, we need to look at the differences between hardware and software.

The most obvious difference between hardware and software is that hard goods cannot be undone, twisted, adapted and adjusted at the same rate, or minimal impact to cost and time as software.

Agile Product Development

The most obvious difference is that hard goods cannot be redesigned or rebuilt as quickly or as
cost effectively.

Redesigning and rebuilding of hardware often comes at a much higher cost than software.

For example, a new casing for a mobile phone cannot be quickly built and rebuilt again in the face of changing requirements. This difference is fundamental. We call it the “Hardware Effect.” Ultimately, the Hardware Effect affects the rate and cost of the “Build, Measure, Learn,” cycle. The cycle at the heart of Agile.

The “Hardware Effect” changes everything, and makes some Agile Values and Principles more applicable than others.

For example, in hardware we place similar weight on both sides of each of the Agile Values, and don’t necessarily see them as conflicting. Here’s our take on applying Agile Values to hardware development…
Read the blog series Agile for Hardware
Agile Product Development

How to apply Agile Values to hardware development

Individuals and interactions over processes and tools

Communication is critical to all development. Visibility of work, in real-time, supports early learning in the “Build, Measure, Learn,” cycle. One could argue that software teams are fraught with their own version of team complexity, comprising a number of skill sets such as marketing, design, developers and quality, not to mention personality types! However, hardware teams are typically comprised of these skills, as well as others. For example, team members that deal with molded components, optics, sheet metal, castings, cabling, piping, circuitry, assembly, research, supply chain, manufacturing, receiving/inspection, field service, quality, regulatory, configuration control, packaging, and many more.

As team size and variety of skill sets increases, the number of interactions increases exponentially, and so does the likelihood of communication breakdowns. In order to combat this increasing complexity, good processes and tools are essential for keeping everyone on the same page. That said, processes and tools cannot completely replace individuals and interactions. In hardware development we need both to achieve our goals.

Working software over comprehensive documentation

Delivering a working product and adapting to new requirements

Working hardware product is certainly of very high value. However, delivering a working product (or changing requirements) in hardware takes longer and has a higher cost than in software.

An important cause of the high cost of change is the highly integrated nature of hardware products. For example, change in hardware typically impacts multiple components and processes. Software teams have long understood modular architectures, and have been using them to limit the ripple effect of each change. Hardware teams have not yet solved the modularity problem.

Increasing modularity typically increases our Cost of Goods Sold (COGS), and degrades system performance including the often-important weight and size of the product. These forces counteract the benefits of modularizing. The higher our cost of change, the longer it takes to recover the cost and the longer the payback period of each new change and release. This fact alone is enough to drive the lengthening of optimal release rates. Check out our series on Cost of delay to see how to calcuate it.

The delivery of documentation is still required in hardware development. It has been the dream of mechanical designers for over twenty years now to never need to create another 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. As mentioned above, with larger, multi-disciplinary teams necessary for hardware development, documentation of decisions and changes is typically more valuable. This includes documentation about the design, the factors (knowledge) driving our design decisions, and the results of those decisions. While 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.

Customer collaboration over contract negotiation

This Value 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. That said, the cost of customer collaboration is much larger in hardware development, largely because of the cost of the parts. Getting dependable feedback from customers often requires expensive parts so customers can see, feel, and use the 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 documentation is minimizing the effort, delay, and expense 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.

Agile Principles

 

Based on these Values, 12 Agile Principles were developed.

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Business people and developers must work together daily throughout the project.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  7. Working software is the primary measure of progress.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  9.  Continuous attention to technical excellence and good design enhances agility.
  10. Simplicity — the art of maximizing the amount of work not done — is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

As you can see, the Agile Manifesto was not prescriptive in terms of implementation. The twelve Principles begin to define how to put those Values into practice, but still did not prescribe a method or process for implementation.

The development community practices several Agile Methods. These include methods such as Scrum and Kanban.
How to apply Agile principles to hardware development

How to apply Agile principles to hardware development

In terms of the Principles, most of them are directly applicable. So we will focus on the few that
need some caveats to be applied to hardware development.
Principle
2

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

As discussed, the cost of change is much higher in hardware development due to the Hardware Effect. As we may welcome changing requirements, we must balance this change with the cost of delaying our project launch.

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 appears in the launch delay and unit cost factors.

In summary, the time between ‘design’ and ‘test’ in hardware is larger. This makes the delay we incur with hardware changes larger, which increases the cost and reduces the economic value of a change. As a result, fewer of the changes we would like to make turn out to be profitable.

Principle
3

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Because of the cost of change and the constraints of hardware, the frequency with which we deliver working product is necessarily less frequent. That is not to say we can’t once again approach development in a more modular fashion and implement methods such as scrum where we are learning earlier on smaller chunks of work.

Principle
7

Working software (in this case “hardware”) is the primary measure of progress.

In hardware, learning quickly is key to success. A working product may not be possible to deliver, but we can track the rate at which we are learning. As stated above, we can also break down our work into smaller batches as well as engage in many other practices to learn earlier.

How to apply Agile methods to hardware development

Interestingly, many Agile methods can be directly applied to hardware development. Some great examples of these are the daily meetings and sprint planning. In terms of daily standup meetings, these are essential to communication, fast feedback and early learning. Since much of the work in hardware development can’t fit in a two week sprint, we need to combine both long and short term planning.

Decentralized and Rolling Wave Planning.

Decentralized planning begins with defining the overall project at a high level, and then having the team members fill in the necessary detail in the near term phases of the project. Rather than pick an arbitrary two week time frame, the teams normally plan to the next significant milestone. Then, once the project is going, the teams utilize Rolling Wave Planning to update the plans on a weekly cadence and continue to add detail as necessary.The delivery of documentation is still required in hardware development. It has been the dream of mechanical designers for over twenty years now to never need to create another 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.

Conclusion

While the Agile Values do apply to hardware development, in hardware, we don’t place as much emphasis on the Values on the left at the expense of the Values on the right. This is largely because the cost of achieving the values on the left is larger in hardware projects.

The difference in the Agile Principles is even smaller. And they were also driven by the cost and complexity of hardware projects vs software. And finally, several of the methods directly apply with little modification. Lead time, component cost, and non-homogenous work are three of the main differences between software and hardware development

We developed Playbook specifically to account form the differences in hardware projects. Besides the Agile Values and Principles mentioned here, we also embedded principles from Lean and Theory of Constraints. If you would like to see these in action, watch the demo video.
demonstration_BG.jpg

Want to try Lean and Agile project management software built specifically for the unique needs of hardware development? Watch a demonstration of Playbook.


Show me the demonstration video