My friend Luca Ingianni and I sat down this morning to record the first episode of The Agile Embedded Podcast, where we will talk about applying agile development and devops principles to software for embedded devices, particularly in safety-critical industries.

I had made the assumption that developing hardware is sufficiently different from software that most specific techniques from the Devops world don’t apply to hardware. In particular, I assumed that the longer lead time associated with hardware development means that fixed-cadence sprints don’t make sense.

Luca made a very interesting assertion: yes, a hardware sprint might be a slower cadence, but you can (and should) still do hardware revisions at a fixed cadence. For example, software sprints at a two-week cadence, and hardware sprints at a four-week cadence.

I pointed out that such a sprint cadence might mean that all known hardware bugs may not be able to be fixed in the next revision. Luca’s answer (paraphrased) was: *“So what? Another release is right behind it. In the meantime, you get feedback and learn from this revision. If something is painful (like doing a board spin) lean into it and do it more often.”

I’m… intrigued. Somewhat skeptical. But, more intrigued than skeptical.

Be safe out there, and happy developing.