Agile for Hardware

What is Agile for hardware?


Agile and Agility have different meanings in Today’s world and most of us think Agile means doing things fast. One of the most important metrics would be time to market. Are we agile if we deliver fast or do we have to rethink what I have stated above?


Speed is one aspect of agility. Reducing time to market will help you reduce quick feedback loops and provide us an opportunity to learn faster. For me, Agility means the ability to learn faster, build quick prototypes, and make critical decisions towards the end.


In most of the product development and product innovations, we are forced to make decisions upfront when we have no or less information about the decisions we make. These upfront decisions are based on some assumptions and these assumptions if proved wrong/incorrect are very costly to fix towards the end of the product development lifecycle. This issue becomes even bigger and messier when we have to design hardware and physical products. In hardware and physical products, components are too many in number, several engineering groups (mechanical, electrical, hardware, firmware) have to work together to deliver a meaningful hypothesis.

The conventional organisational design of moving people to work seems to be a huge blocker to learning from each other. Teams and individuals from various engineering departments(disciples) work in isolation leading to “handoff” waste. The ability to check the cost of production with manufacturing during the R&D prototype phase is significant feedback to develop the product design based on production economics.


The ability to work with field engineers during the prototype phase and seek feedback on the design for supportability can reduce significant costs and complexity in providing post-release support. A piece of significant knowledge in terms of real customer conditions can only be understood when the development teams interact with support teams. The ability for a product to work in the Arctic region (sub-zero temperatures) vs the Sahara Desert (hot conditions) vs Amazon forest (humid) conditions have to be tested before certifying the product. Heat, vibration, usability, product life all have to be designed and tests have to be performed before finalizing the design and rolling it out to production.  

 Three lessons I learned from my experience are :

Lesson 1: Validating integrations at the end of the Product Development process

Back in my career, I was working to reverse engineer a Japanese automotive motor. After two years of product development, the below-mentioned challenges emerged.

  1. The inconsistent motor speed at full load: efficiency
  2. Ability to run for 24 hours on full load
  3. Electromagnetic noise level
  4. Noise level with physical assembly
  5. Brush efficiency and wear out
  6. Commutator hardness
  7. Bearing efficiency; Bearing temp at full load
  8. Rotor winding design
  9. Stator (permanent magnet) assembly design
  10. The project failed at the end of 4 years


Lesson 2: Ignoring design for supportability: Lack of systems thinking

In yet another product development that I was involved, we again did a big mistake in ignoring design for supportability. The product design software was so robust that it required a physical presence of field support personnel to use specialized software to get a command prompt to run any system commands. This resulted in serious support spending eroding profits.


Lesson 3: The business of selling price, cost price, and profits

Cost price + Profit = Selling price-------->1

Selling price - profit = Cost price --------->2

Mathematically both mean the same, but in reality, they are two different worlds. Most organizations who have a monopoly of products or who do not have an even match competitor can define theory product cost price add the profits and hence defining their selling price.

However, 95% of the enterprises fall under the category of equation 2. The selling price is defined in the market and based on the selling price our profits get defined. This means that we as engineers must be in constant look to reduce the cost price. If we do not focus on reducing the cost price, it is impossible to make profits with the constant market changes and reduction in product shelf life. Unless we look at this equation and understand the harsh market reality it may be impossible to build products and make profits consistently.

 If I now reflect on this experience, I find myself surprised by asking a question

“Why were things approved before we validated our designs?

Why did we not learn about them? ”

Agility is Hardware development is the ability to run many testing cycles and manage the variability by reducing the knowledge gaps. It does not mean by saying that Agility means to remove all the variability upfront. It means that to learn as much as possible at the beginning which will enable us to make decisions later at the last responsible moment respecting the two important principles of lean namely “Develop as soon as possible and Decide as late as possible”.


Toyota showed this critical wisdom to the world by the use of its tradeoff curves.


Tradeoff curves are a visual representation of basic product and process physics and economics

  • Central concept in development at Toyota
  • Toyota uses these for everything
  • Enables to process the basic physics and economics through your eyes and not the mathematical part of your brain
  • Toyota’s primary tool to Learn and reduce Knowledge gaps


  • Communicate and Negotiate between various specialties and functions and mgt. and suppliers and mgrs. and engineers
  • Training new engineers
  • Primary tool in Design reviews
  • Like Built-in Quality, this enables Design-in-quality
  • Knowledge updated by working owner with every new Datum
  • The known pattern is Design to Test; design first and validate your design. Toyota showed both economics and knowledge is with the approach of Test to Design
  • Roots of this engineering approach were first used by Wright-Brothers in their flight designs.


Most of the Agile coaches force the hardware teams for 2-week iterations (sprints). This clearly shows their lack of experience in the hardware domain. In mechanical you have to wait for 3 to 4 weeks to develop a basic meaningful prototype. In electrical to design a small motor prototype with all the available components, it might take 2 to 3 weeks. The integration and seamless working of these heterogeneous components may take a lot of time. This is what I said Agility in Hardware is not just about speed.


Some differences between hardware and software are mentioned as below




§  Code is involved

§  Functional and NFRs

§  Architecture is important

§  Frequent System integration

§  Frequent testing is important

§  Aggregation of deliverables yields usable features over time

§  Product has more working functionality at the end of the month than it did at the beginning of the month

§  Steady evolution of functionality enables frequent stakeholder review opportunities, to drive the evolution of scope in ways that maximize value and minimize wasted effort

§  Online releases - Click of a button

§  Harder to make changes/take more time

§  Multiple disciplines involved

§  Production is costly and longer

§  Hard to change architecture down the line

§  Impossible to refactor after manufacturing

§  Aggregation of deliverables yields design for a usable product at the end of development

§  The product’s design has more elements as time passes, but the product does not work in any meaningful sense until all parts are completed and assembled

§  Stakeholder feedback loops are desirable, but more oriented towards concepts and mockups than working functionality

§  The physical place needs to be examined; release is a very different process



In short, the three pillars of Agility for hardware are

  1. Learn, learn more and enable learnings as soon as possible
  2. Capture knowledge that can be extended to new products
  3. Decide as late as possible at the last responsible moment


Keep looking for this space.. We will be coming up with Agile for Hardware in 2021. This will help you to revolutionize your product development space. Together let us build systems that are Faster, Cheaper, Good quality and make the world a better space for us to live and thrive


Subscribe to our newsletter