Even more tipps for agile hardware development

After giving two presentations on agile hardware development, here are some more tipps for your agile hardware development projects.

“The man who moves a mountain begins by carrying away small stones.” — Confucius (Chinese philosopher)

On October 29, 2025, together with Dr. Tobias Kästner from inovex GmbH, I gave a talk on Agile Hardware Development: Status Quo at the Power of Electronics conference in Würzburg. On December 4, 2025, I held a similar talk together with Christoph Schmiedinger from Die Umsetzer GmbH at the ESE Congress for embedded software engineering in Sindelfingen (with a slightly different presentation).

In a blog series on my company alpha-board gmbhs webpage you can find all parts of our presentations. For the beautiful Ukiyo-e images, I physically manifested Google’s Gemini in an adjacent room and then forced him/her/it to paint these little pictures for me (reading some or all of P. Djeli Clark’s Dead Djinn books helps you being able to do such a thing with your LLM).

Why do we need agile hardware development?

It is important to understand that an agile approach is particularly good in certain situations. We illustrated this in the following graphic:

In which situations agile approaches fit well

If you don’t know much about what potential end-users like or want, or if you don’t know much about the technological solutions to be used (because they develop and change so fast nowadays), then agile approaches always fit well to iterate quickly through the solution space in front of you. If both are known, you can work agile, but you don’t have to. If both are uncharted territory, agile might not be particularly suitable either, because that is where chaos and dragons dwell.

Continuous Integration possible in hardware?

We learned a lot in mixed teams from how other experts from different areas work. Seeing which tools software people use, how many there are, and what can be automated with software tools — that was quite impressive for us hardware people:

• Adopt software practices (and check beforehand: tools already exist for almost everything you can think of)
• Focus on automation (via CLI: run tests, create daily documentation, versioning)
• Early error detection through early, ideally automated testing
• Design artifacts readable for everyone and up-to-date (readable for human and machine)

Configuration Management

In the past, we named and treated our versions differently, often with capital letters and such (like, say ITS074A or so). Today we rely mainly on Git:

• Manual revision numbers will become garbage at one point in the future
• Solution: Version control à la software (e.g., Git, not SVN, actually)
• we put Git-SHA1 in the copper on the PCB links directly to the correct schematic

And a note on this: open text formats for design files, such as in KiCad, are better for text-based versioning tools like git than, for example, proprietary data formats like in Altium.

For better understanding: Style Guide for Schematics

To ensure everyone in a mixed, agile team understands the schematic, for example, style guides have proven their worth. We developed one for schematics, for instance (and I already wrote about this Style Guide for Schematics here):

• Style Guides improve understanding AND beauty
• Ever looked at your own schematic 3 months later and didn’t have a clue?
• e.g., prefer multiple A4 sheets for different functionalities
• e.g., Input from the left, Output to the right
• e.g., Supply at the top, GND at the bottom
• Voltage indication: min, normal, max (Vbatt = (3.0, 3.6, 4.1) V)
• and much more BUT the team decides!

Let the team discuss their style!

Try out Open Source

Many proprietary tools are very good, logically. Nevertheless, the associated high costs of their licences and how to use them, often create “expert silos,” which immediately lead to bottlenecks in the process flow. Or companies want to fully utilize the expensive licenses, which then also creates bottlenecks. Therefore, maybe try out Open Source, which is often free of charge and sufficient for many requirements (though not always all):

• Commercial tools ➜ often inflexible
• Advantage of Open Source (OS): adaptable, extensible, and data interpretable
• Open source and lively community ➜ solutions or integrations (e.g., KiCad)
• Low-threshold access (and by the way: the older, the better documented for AI use)
• Practical example: own scripts for inserting Git-SHA1 into production data

Maybe even publish parts or a whole project as Open Source Hardware yourself? We have the impression that you learn quite a bit about what requirements others have for schematics, design, documentation, for example.

Question Maturity Models

This also seems important to us: questioning your usualy procedures if possible. This isn’t always possible, but when it is, it certainly brings value, in our experience:

• Classic maturity models (V-Model) are document-driven and often far removed from reality
• Idea: Measure maturity level “function-driven” from the user’s perspective
• Define and track standardized maturity levels for individual, modular functions
• Requires modular design where modules can realize functions independently of each other

Conclusion

Our conclusion is:

• Agile is not nice-to-have, but vital for survival in our world
• Don’t lose time ➜ start with agile hardware development today

Download the Whitepaper (in German)

This is Part 4 of our series on agile hardware development, and here’s the link to it on our blog. There you can find all articles in the series. We want to show where we see current problems in agile hardware development and what solutions we have already found to solve these. The contents are derived from a whitepaper we contributed to, which you can download here. It is a collaboration of the above mentioned authors, actually.