Practical Thoughts on Agile Management for Hardware Development
Some Ideas on Iterative, Flexible, and Efficient Hardware Design
Hardware development has traditionally relied on linear processes, where design, prototyping, testing, and manufacturing occur in sequential phases. While this approach works for well-defined projects, it struggles to adapt when:
Requirements change mid-project.
Issues (e.g., part obsolescence) arise late in development.
Complex systems require frequent iteration and verification/validation.
Unlike software, hardware projects face challenges such as long lead times, physical constraints, costly iterations, and dependency on manufacturing. However, these challenges can be mitigated by implementing Agile principles tailored for hardware workflows. This post presents some hard-learned lessons on applying Agile to hardware development, emphasizing iterative design, modular architectures, and continuous feedback to enable faster, more flexible development cycles.
Challenges in Hardware Development
Before exploring Agile solutions, it is important to recognize the challenges specific to hardware:
Agile addresses these challenges by introducing flexible workflows, continuous testing, and frequent stakeholder input to identify issues early and adapt quickly. But it’s never just that easy. So, without further aideu, my lessons learned on bringing agile management methodology to hardware projects:
The Best of the Best Don’t (and Won’t) Live In Your Town. Embrace remote work to the greatest extent possible. Not everyone needs to touch everything all the time. Be smart about when you collaborate in the real world and when you can work remotely. Integration tests are a great time to unite people for a week or two. Geographically distributed teams can also work 24/7. When I am asleep in New York, a co-worker can incrementally improve my design in Tokyo. And when she goes to sleep, I can pick back up and keep moving the ball forward. AR/VR might also help in this regard. It’s not quite there yet, but it probably will one day. Also good for getting customer feedback; they care more about higher-level requirements like look-and-feel and system-level operations versus the minutia of detailed design work. AR/VR seems reasonable enough at this point for the purpose.
Function versus Form Factor: I once had the task of designing a power supply for a system. Conceptually, a power supply is a pretty common subsystem for many things, big and small. I built the power supply, and from an electrical perspective, it worked flawlessly. From a mechanical perspective, it weighed too much and was dimensionally too large for the space it had been given. But we didn’t know how much space it could be given until the design was much further along. So we redesigned the power supply, and it meant that we couldn’t power everything the client wanted to power, but we fit the box. But if we kept the original power supply, we could power everything, but they would have to give up the space equivalent to a few sensors and associated circuitry to make it fit. But then, the loss of that sensor equipment lowered the system's power requirements. We were in a real Catch-22! So, we had to return to the client and systems engineer to present the tradeoff. The point of all this is that in hardware,e there are tradeoffs that are much more serious than in software. Adding more bits generally doesn’t affect the weight or size. Be prepared for this back-and-forth when designing hardware.
You can Design Software Without Developing Hardware, but it’s Very Rare to Build Hardware without also Developing Software. People building a smartphone app accept they are building for a fixed set of hardware devices. They aren’t (likely) building hardware. However, when building hardware, you are likely also building software. And with it comes all the problems that come with software development. But that is a story for another day.
Don’t Let The Project Management Tool Wonks Win. I swear some teams spend more time worrying about managing their work than doing it. Management tools should aid in getting the job done, not be a chore in and of themselves. That said, because we are embracing geographically distributed teams, your tool needs to be digital and accessible from a laptop browser and an app on a smartphone and tablet.
3 Three-week sprints. With two-week sprints you will spend more time just wrestling with the management of the agile framework beast than doing value-added work. Four weeks and too much could have changed since the sprint was planned. Three weeks is the sweet spot.
First Law of Orbital Mechanics: Slow Down to Speed Up. Maintain a sustainable pace. Trying for breakneck speeds will cause burnout, and that’s unsustainable. Accept that the team needs to spend 10-15% of their time on management tasks, mostly meetings such as Sprint Design Reviews and Sprint Planning Meetings. Teams should be kept to 8 folks or less,s including non-technical staff such as scrum master and/or product owner. Want to know more about orbital mechanics? Click here. ;)
Yes AI is Coming for Our Jobs, Embrace It. I do not doubt that AI will have an effect on our design work, for better and for worse. As is true with any technological advancement, the goal should be that the tools (and yes, AI is just a tool) should do the drudgery work and free the human for the more creative work. I would be lying if I said I didn’t use AI to generate ideas. Humans, especially in teams, work better from a scratchpad idea than a blank sheet of paper. Use AI to help brainstorm initially, but always give it back to humans to massage, improve, and add creativity and innovation to concepts.
Open Source and Modular Architecture: Why Arduino succeeded, it force a form factor. On the one hand, there is an argument that it stifles future innovation. Still, standards also allow it so the fire department from Annapolis can help fight a fire in Baltimore (read more here). Put another way, don’t reinvent the wheel. And be warned, engineers always think they can build a better wheel. Don’t let pride into the design equation.
Design-Build-Test-Learn Loop. This is the meat and potatoes. This is probably why you are here. Let’s dive into what a scrum cycle should look like for hardware. A reminder for those who have just skimmed to this part. 3-week sprints. The target is no more than 10-15% of the team’s time spent on scrum/agile administrivia, which means 95-90% should be on the value-added Design-Build-Test-Learn loop. The loop starts as such:
Product Backlog Review: Review all backlog stories based on the past sprints and any changes that have arisen since the last product backlog review. Kill any that are moot. Put those that are not ready into the icebox. Bring those requirements that are ready for execution forward into the next sprint and logically move the project forward. Get a feeling for hours of effort from the team. Validate with the client. This is the time for the client to get their say. This should occur on the first day of a sprint.
Sprint Planning Meeting: Assign stories chosen to team members and have them break down the work into tasks that can be validated at the end of the sprint. Ensure that the even distribution of work and all dependencies are met and that parts are on hand during the fabrication/assembly phases. On-hand inventory is not something you think about in software agile development. Don’t be afraid to push to backlog any work that is just not ready for whatever reason. This one is meant to be for the team only so they can voice concerns without the risk of alienating the client. This should occur on the first or second day of a new sprint, depending on the complexity of the project and how much time is needed for product backlog review with the client.
Daily Standups: This is a double-edged sword for most teams. Especially with teams that have someone with a penchant for micromanagement. It’s needed so everyone has a chance to talk about what they are working towards and, more importantly, what troubles or roadblocks they are hitting. Keep these minutes to 15 minutes or less. Of course, in geographically distributed teams, you might need to account for ways for folks to achieve the goals of the daily standup but in an asynchronous manner. You might consider alternating weeks and sometimes schedule the meetings at the beginning and sometimes at the end of the workday so everyone has an equal chance of having to get up early or stay up late. Or use digital tools like a virtual sticky note board so team members in highly different time zones can provide feedback asynchronously. But seriously, 15 minutes at most!
Design-Build-Test-Learn Loop: Think of this like a sub-loop that occurs almost every day after the standup. This is where the value-added work gets done. The engineers and designers should spend time designing and building (think rapid prototyping — breadboarding circuit, 3D printing models, updating the firmware). Then, test what they have worked on to see if it meets the requirements or specifications that the component, assembly, or subsystem is expected to meet. Lastly, learn from the failures. I think we need to call learn out specifically because in a world where the notion that “fail early, fail fast” is perhaps okay with pure software development, it’s a bit problematic with hardware, if for no other reason than cost. It’s OK to fail but we need to fail smartly. We must rigorously learn from our mistakes so that when we go back to the drawing board (e.g., start the Design-Build-Test-Learn loopover), we do so in an informed manner. This means documenting test results. Getting feedback. Making informed conjectures on what to modify in the design. Understanding the 2nd and 3rd order impacts of those potential changes. Then, picking the changes that have the best chance of producing success.
Design Review: Now, in a proper scrum/agile framework, this is called the sprint review. However, I prefer design review because it puts the emphasis on the work, not the management process. We are doing a code or design review of the work to ensure compliance with requirements, specifications, standards, etc. This is for the clients to provide feedback as well to ensure we are on the right path. This is also a chance to let the team shine and show off their hard work. Your co-workers are the best line of defense against errors. That said, groupthink is accurate, and significant review milestones should have smart, external eyes to catch what the team may be blind to. Remember to reward in public. This also occurs on the last day of a sprint.
Optional: Sprint Demonstration: Some teams might have concerns about doing what is perceived as an internal design review in front of a client. Some opt to hold a separate sprint demonstration to get feedback from the client. Think about the difference between verification and validation testing. See below. Just remember this is yet another meeting taking away time from the Design-Build-Test-Learn loop where most of the value-added work gets done. So proceed with caution. See bullet #20 below to convince you NOT to got this route. ;)
Sprint Retrospective: I prefer to keep this one internal. It’s a chance for the team to air their dirty laundry and discuss what is working and what isn’t working, both technically and from a project management perspective. This also occurs on the last day of a sprint.
Test Driven Development. If from the very start, every requirement you write, every function you derive, every specification created, if it is written down from the perspective of how in the hell will I test this later, you tend to write better requirements, test plans, etc. Don’t forget the difference between verification and validation testing, too. Verification is “Did I build the system correctly (to specifications)?” versus validation, which is “Did I build the correct system (to meet customer requirements)?”
Also, Technician Driven Development. Remember after you have design and built the prototypes, eventually a factory worker is going to have to recreate your work in a distant location, a technician is going to have to service this equipment 20 years later. Remember all the people who will build, use, and maintain/repair the hardware you are building. Software is much more intimate. The idea creator also turns the idea into reality by producing source code. Once the code is written, it can be forever duplicated perfectly and for free. Not so with hardware. The idea creator eventually gives up the idea to a small army of people to bring the idea into tangible form. Even for something that is 3D printed, the STL or 3MF file might duplicate the design perfectly. Still, each printer it is printed on will have individual nuances that translate the idea into an imperfect physical representation. Keep that in mind,
Roman Space Shuttle Story. If you have never heard the story of how Roman Empire horses affected the design of the United States Space Shuttle. Go read this. The point is this. Software, more than hardware, gets to have a “tabula rasa” start; hardware rarely gets to start clean. If nothing else, things like UL and FCC certifications constrain hardware design.
Keep It Simple. Everything should be written so that an 8th grader can understand it. Requirements. Test Plans. Test reports. It’s like Einstein once said, to paraphrase, if you can’t explain it to a kid, you don’t understand it enough yet.
Build a Common Parts Library. To this day, I remember the laughter on Ralph’s face when I told my first boss I calculated I needed a 195.5-ohm resistor but didn’t see any in the supply room. Go on Mouser or Digi-Key or crack open a McMaster-Carr catalog. There is a metric shit ton of parts being made in this world. Don’t waste precious hours trying to find the best part. The best part is like the best camera; it’s the one you have on you when you see a gorgeous sunset. A common parts library cuts down on inventory, wait times, and engineers hemming and hawing over which screw is the perfect screw. However, a defined process should be in place to account for the fact that there will be times when a common part just won’t cut it, and there needs to be special procurements. Just make it the exception, not the norm.
Encourage Collaboration and Teaching: Something that really resonates with me regarding the Maker Movement is that it marries designing and building cool stuff with the need to teach and share with others what you have learned. That gets lost in traditional engineering teams. Set aside time each week for people to share or collaborate in a way that lets them let their hair down in a more risk-free environment than, say, a design review where everyone is perhaps a bit nervous. This mindset also encourages lifetime learning, which leads us to…
Cross-pollinate. Let the mechanical folks solder, and let the electrical folks turn a wrench. Let them both write some code. Engineers tend to solve problems from the perspective of their chosen disciplines. This may not always yield the best solution from a holistic perspective. Get the team outside their comfort zone so they can at least appreciate the challenges and general principles of other technical disciplines.
If possible, and I know it’s a luxury most can’t afford, have 2 or 3 teams develop prototypes at the same time as insurance. Once the customer down-selects a chosen preferred system, reallocate resources to do the work to go from prototype to production.
Embrace Desktop Manufacturing Tools That Get Out of the Way of The Engineer. Tools like 3D printers, laser cutters, and CNC mills need to do the job of getting the idea of the engineer or designer into his/her head into reality as quickly and as painlessly as possible. It’s like the desktop publishing revolution of the 1980s and 1990s when tools like PhotoShop and Apple II hit the market. They weren’t for developers. They were for artists. Desktop manufacturing is to engineers, just as desktop publishing was to artists. An engineer spending time fiddling to get his/her tools just to work properly is spending fewer hours on value-added work.
Don’t Forget About Safety. I am not saying that software development is risk-free. It’s just a lot less likely to result in injury than hardware development, especially when fabricating parts on machines or handling potentially noxious chemicals. Ensure a culture of safety is embraced. Especially with agile, where the perception is to go fast or go home.
Don’t Be Afraid to Let the Client See How the Sausage is Made: Here’s a fact. Design, engineering, fabrication, assembly, installation, maintenance, and repair are messy. It’s messy work to bring an idea into reality. Don’t be afraid of pulling back the curtain for the client. I am not saying that there needs to be 100% transparency; sometimes things like NDAs and IP can come into play, but for the most part, I’d rather have the client involved more, not less in the entire product development lifecycle.
Save Perhaps the Consumer Goods Market, Hardware Lasts A Long Time. People might update their smartphones yearly, but other markets and industries consider hardware purchase investments. They want their stuff to last. That said, component manufacturers can be fickle too, so your system needs to be designed and built to last but also to be reworked when the inevitable event of obsolescence of parts rears its ugly head.
Before We Sprint: In general, all software is going to be a thing that runs on a screen, maybe a touch interface, maybe a computer, and a mouse. Even if a piece of code runs silently on a server, there is at least a command line interface. So, in general, there are some safe assumptions with software. Hardware is not so. It can be anything. I could be building an electronic toothbrush or a military jet aircraft. And anything in between. That said, while agile is good at working in arenas with loose or evolving requirements, there needs to be some work done before sprints can start to define requirements in terms of cost, schedule, and performance expectations. Remember bullet #6 about slowing down to speed up.
Let The Team Self-Organize. In other words, throw out everything I just discussed if the team feels it won’t work and let their expertise guide you instead. People make the difference.
Let me say that again. In the end, it’s the people that matter. It’s the people that make a difference. Agile methodology, or any methodology, is only as good as the people implementing it. So what else did I miss? What are your thoughts on building hardware in an agile manner?