SAFe for Hardware: Stories and Strategies from the Field

“We’re unable to build an entire component within just two weeks… so the question becomes: what can we verify at the end of a sprint? It’s about finding the shortest path to your next learning.” — Ali Hajou

 

In this episode of SPCs Unleashed, the hosts dive into the newly released SAFe for Hardware course and use it as a springboard to explore agility in hardware more broadly. Ali Hajou, joined by Mark Richards, Stephan Neck, and Niko Kaintantzis, reflects on how Agile principles—originally inspired by hardware product development—are now circling back into engineering contexts. The group unpacks the unique challenges hardware teams face: aging technical workforces, specialized engineering disciplines, and long product lead times. Through personal stories and coaching insights, the hosts surface strategies for fostering collaboration across expertise boundaries, reframing iteration around learning, and adapting SAFe without forcing software recipes onto hardware environments.

Actionable Insights for Practitioners

1. Honor Agile’s hardware origins
Scrum was born from studies of hardware companies like Honda and 3M. Coaches can remind teams that agility is not a software-only mindset but a return to hardware’s own innovative roots.

2. Reframe what “shippable” means
Hardware teams cannot produce finished machines every two weeks, but they can deliver learning increments through simulations, prototypes, and verifiable designs.

3. Lead with humility
As Niko described, success comes from co-working with engineers rather than posturing as experts. Admitting limits builds trust and invites collaboration.

4. Shift the conversation to risk
Talking about risk reduction resonates more strongly with hardware engineers than software-centric terms like story slicing. It reframes iteration as de-risking the next step.

5. Context matters more than recipes
The SAFe for Hardware training emphasizes co-creation. Rather than copying software playbooks, practitioners should tailor practices to local constraints, supply chains, and compliance realities.

Conclusion

The conversation highlighted that agility in hardware is less about forcing software practices and more about adapting principles—short learning cycles, risk reduction, and humble collaboration—to fit the realities of physical product development. SAFe for Hardware provides a structure for that adaptation, but its real power lies in co-creating ways of working that respect both the heritage and the complexity of hardware environments.