At a recent Stockholm Agile for Hardware meetup, I had a conversation that I have had many times before, in many variations. Someone from a software background asked, with genuine curiosity, why hardware teams cannot simply adopt Scrum and start delivering in two-week sprints. The question is understandable. If you have spent your career in an environment where you can deploy, test, learn, and iterate within days, the pace of hardware development can feel almost willfully slow. But the slowness is not a cultural failing. It is physics.
Hardware development operates under constraints that software developers rarely encounter. A physical prototype takes weeks to produce, not minutes to compile. A supplier lead time of twelve weeks is not unusual — it is normal. Regulatory certification for a medical device or an automotive component is not a checkbox; it is a months-long process with legal consequences. When people say that agile does not work for hardware, they are usually not rejecting the values of the Agile Manifesto. They are rejecting the naive assumption that you can copy software practices without accounting for these realities.
This is where frameworks like SAFe for Hardware become genuinely useful, not as a prescription, but as a structured way of thinking about how agile values can coexist with long cycle times and physical dependencies. SAFe brings a vocabulary for coordinating across teams, managing architectural runways, and planning in increments that respect the reality of hardware timelines. It is not perfect, and I have seen it applied badly — turned into a bureaucratic exercise rather than a tool for alignment. But when used thoughtfully, it provides a shared map for organizations where dozens of teams need to move in roughly the same direction.
Understanding constraints
The deeper insight, though, is that agile in hardware is not about making hardware teams behave like software teams. It is about understanding your constraints and optimizing within them. You may not be able to shorten a tooling lead time, but you can make better decisions about what to prototype and when. You may not be able to release a physical product every sprint, but you can integrate and test subsystems continuously so that when you do release, you have confidence in what you are shipping. The goal is not speed for its own sake. It is learning — reducing the time between making a decision and knowing whether it was the right one.
What struck me most at the meetup was the hunger for practical examples. People are tired of theoretical frameworks. They want to hear from organizations that have actually done this — that have taken a hardware product from concept to production using agile principles and can speak honestly about what worked and what did not. The success stories I have seen share a common thread: they all involved leadership that was willing to invest in the cultural change, not just the process change. Tools and ceremonies are easy to adopt. Changing how engineers collaborate across disciplines, how managers support rather than control, how organizations learn from failure — that is the real work.
I left the meetup feeling cautiously optimistic. The conversation around agile for hardware has matured considerably in the last few years. People are no longer arguing about whether it is possible. They are arguing about how to do it well. That is progress. And the fact that engineers, product managers, and leaders are showing up on a Tuesday evening to discuss it tells me that the appetite for change is real, even if the path forward is anything but straightforward.