Helping Hardware Be Agile, Part 1

I’m writing like mad, trying to finish the program management book. I’m working on the “Integrating Hardware” chapter.

The problem is that hardware comes in several varieties:

  • Mechanical engineering
  • Silicon (part of electrical engineering)
  • FPGA (which looks like software to me)

Each component (yes, I do call these components) has a different value at different times in the product development. The program needs all of them by the end. But how do you see the product evolve? Is it even possible?

Well, yes it is possible to see a product with hardware evolve. The problem is that hardware is expensive to transition to physical form. Every time you go to physical form, you incur NRE (Non-Recurring Engineering) Expenses. If you have to fabricate a chip or board, that’s expensive. In my experience, my organizations want to fab no more than three times(prototype, pilot, real product). And, all near the end of the program.

AgileRoadmapOneQuarterHardwareThe first problem is ranking the features and organizing a product roadmap. In the book, I have a possible product, a robot arm. (None of my clients are developing robot arms, so I’m safe.) Here is the roadmap I created.

Notice that each monthly deliverable is a demo. For each of the first two months, the deliverable is component demos. The software team (OS) could show their completed software to date. The mechanical, silicon and FPGA teams would show their simulations. The simulations are separate for each component. For the third month, there is a potential joint simulation and a demo of the first prototypes.

The goal is to show every team’s work to every other team. For a complex product with hardware, the teams need to see what each other is doing, earlier rather than later.

You can try to do design by contract. It’s a great idea. My experience is it doesn’t matter what’s in the contract. The hardware is always a little different because the hardware people (mechanical and silicon) have to make tradeoffs be able to make the hardware fit the performance, footprint, or manufacturing capabilities. The earlier you can demo to each other on the program, the earlier you can see the changes.

This roadmap shows the teams what the program values first. It outlines the interdependencies. Yes, you need a product owner who either understands the interdependencies, or you need teams who can teach the product owner.

In my next post, I’ll talk about how to see the work each team does. The roadmap is insufficient for the details. The roadmap explains the big picture, and what you want to have happen. What the teams do is reality.

If you have an agile program with hardware, please comment on this post. I would love to know if this is helpful, what you do, and if you do something different what it is. Thanks.

7 Replies to “Helping Hardware Be Agile, Part 1”

  1. This process is similar to Ford’s House of Quality in which the customer and engineering rank the relative value of each component, and that ranking is compared to the competitors’ products. System requirements – gotta haves – are added to by engineering the desired components into or onto the product. The qualities of the components are defined by the customer.

    1. Chet, there are many things that worked before agile. That is one of them. The concern I have is this: how long does it take to rank? If we can rank (and if necessary, re-rank) when we have more customer or any feedback, we can use the House of Quality even better.

  2. Nice to see Agile applied to the hardware side. I assume you are aware of the WikiSpeed Project. They had some interesting insights regarding Agile hardware.

    Where I worked, we employed parts and aspects of Agile, by it really was a mix and match (traditional and Agile). These were really big hardware-software efforts, hence the mix and match life cycles.

    We did use things like the road map table in the lower levels of the large project, but we also had more formal planning (traditional) efforts using tools. So inside of a part of the project we could be agile using concepts like the road map. Where the teams had real “work” was at the Integration and Integration Test efforts. We often saw problems for the first time, when we integrated (hardware-hardware, software-hardware, and systems). Another thing we saw quite often was as the hardware became “solidified” and a problem in it was found, we hear statements like “we will fix that problem in the software”. This cause “new work” to be defined to the software teams.

    Even with all of this, we did find that doing prototype hardware as early (to the left) as possible and Agile concepts, did allow more feedback to the teams. For example, with one effort, we learned very early that the hardware had performance issues that software had to address.

    Finally, how does the table/road map work with set based design concepts? As IoT grows, these teams will face the problems of being Agile with hardware and software, since IoT can have both. Road maps-planning, strategies, design concepts, and other concepts will be needed.

    1. Jon, one of the things I love about WikiSpeed is the way they integrate test-driven ideas into hardware development. That allows for better feedback earlier. (Probably what you saw at the Integration and Test efforts you mentioned above.)

      I am reading about set-based design now. I’ll let you know 🙂

  3. “FPGA (which looks like software to me)”

    Yes, it’s very much like software from this point of view. The FPGA team at the company I’m consulting for is as agile as the SW teams (Scrum, test-driven development, unit testing, continuous integration, …). The missing piece used to be the lack of a unit testing framework for VHDL/Verilog but that has changed. We’re using VUnit ( for that. Disclaimer: I’m part of the VUnit development team

    1. Lars, I bet VUnit is helping FPGA development look more like software, in terms of iterating and incrementing. I’m glad you’re part of the VUnit development team. Carry on!

Leave a Reply