Agile 4 Hardware - Insights from Munich 2024

Dear first followers of the Agile 4 Hardware community that we are forming, and other passionate followers..

It has been such a pleasure, honor and humbling experience to be with so many of you all at the BMW World, to share the experiences of Agile 4 Hardware. We had a vision to start a community event, where it is “for agile hardware folks”, “by agile hardware folks”. The eagerness, the quality of the talks and the energy and fun that was felt throughout the day were a simple confirmation: Houston we have lift off.

?

In this small post, I would like to share the 10 insights that we captured throughout the event. Of course there is far more than 10 insights, so I would like YOU all to comment with your own 1, 2, 3 , 5, 10 or even 20 insights that you have had. With this, we hope to create a bit of a community summary of all the insights and lessons that are important for organizations and professionals that go “to the stars and beyond!”

?

The 10 insights we gathered from listening to the sessions, talking to participants and looking at the questions. I have taken the liberty of trying to bring a LEGO example for each to exemplify in a fun and simple way, forgive me for my nerdiness :-)

?

1. Modularization of product – whether it is hardware, software or both – is a key competence of hardware product development In the LEGO marble track project, each team is responsible for building a section of the track (a module). These sections must connect seamlessly with others via a simple interface, like a common slope or track connector. This modular approach allows each team to focus on their part of the track while ensuring that when assembled, the entire system works together smoothly. If one module fails, it can be adjusted without dismantling the entire track. This flexibility and separation of concerns mirror the modularization necessary in hardware development.
2. The integration game needs to up its ante – simple and cheap integrations done often OVER full integration done too late During the LEGO marble track project, teams don’t wait until their entire track module is perfect before trying to connect it to others. Instead, they perform frequent test integrations to see how their section fits and functions with the rest of the track. Small adjustments are made on the spot, ensuring alignment and functionality as they go. Waiting to connect everything only at the end could lead to major issues that are harder to fix. Frequent, simple integrations allow teams to identify and resolve problems early, much like in agile hardware development.
3. Agile for Hardware & Engineering should start with Hardware and Engineering, and use Agile as a mindset framework In this LEGO assignment, instead of enforcing strict rules on how each module should be built, the teams are encouraged to think creatively and flexibly. They use Agile principles like adaptability and rapid experimentation. Rather than imposing software-specific Agile methods, they apply the mindset to their hardware task—building and iterating on physical LEGO structures. They focus on improving their track module through feedback and testing, adapting Agile to the physical nature of their project.
4. Engineering is an empirical learning game, which needs a process that supports empiricism and learning The LEGO marble track project is full of trial and error. Teams may initially build a track module, test how the marble flows through it, and then observe that the slope is too steep or that the marble gets stuck. Based on this empirical feedback, they adjust the design, test it again, and keep iterating. This mirrors how engineering teams need processes that support constant experimentation and learning from real-world tests, not just theoretical planning.
5. Most talks conclude that Agile for Hardware and Engineering need moderate change from Agile for Software Development – evolutionary rather than revolutionary In the LEGO project, the teams don’t need to completely overhaul their existing methods for building LEGO structures to adopt Agile. Instead, they make small, incremental changes, such as testing and iterating more frequently, collaborating more closely, and integrating their modules more often. These are evolutionary steps that help them adopt Agile principles without having to abandon traditional engineering methods altogether, much like Agile for hardware doesn’t require a complete revolution.
6. Many presentations show that the success of introducing agility in hardware is about helping the people to make the change For the LEGO project to succeed, it’s not just about building great modules—it’s about the teams themselves embracing Agile ways of working. Teams need to be supported as they shift from a traditional "build once and test at the end" mindset to one where they iterate, test, and integrate frequently. Helping the participants get comfortable with these new practices, encouraging collaboration, and fostering open communication are key to their success, just as it is in hardware product development.
7. Many seem to struggle with product- and work breakdown structures, with lead times, dependencies and traditional processes as the main challenges In the LEGO marble track assignment, teams often face challenges breaking down the overall system into manageable parts. Some teams might struggle with ensuring their modules align with others due to differing lead times, or they might get bogged down by dependencies, such as waiting for another team to finish their connector before testing. This reflects how hardware teams often grapple with long lead times, complex dependencies, and the limitations of traditional processes that hinder agility.
8. Agility is an action-based mindset. Hands-on, experiment, trust, ownership are the ingredients to make a team become successful. Big plans are big threats. Dream big, act small and now In the LEGO project, teams are encouraged to start small, building and testing short sections of the marble track first rather than planning an overly complex design that might not work. They experiment hands-on, trust each other’s work, and take ownership of their modules. Instead of obsessing over a grand, perfect plan, they focus on immediate actions—building small sections, testing them with marbles, and improving them based on feedback. Dreaming big but acting small is the key to creating a successful track.
9. There is a tendency of requirements to turn into specifications too fast, leading to mediocracy, complacency, and sub-optimal solutions In the LEGO marble track assignment, if teams rush into locking down their module designs too quickly—turning basic requirements into rigid specifications—they may end up with suboptimal tracks that don’t perform well. For example, they might decide early on that a track must have a certain number of loops without testing whether the marble can handle them. By remaining flexible and open to change, teams can avoid settling for mediocre solutions and instead aim for continuous improvement as they test and learn.
10. There is a “chicken and egg” problem with specialization; it leads to long lead times and wait times, which in turn incentivize more specialization. Competence development and specialization guardbands are a necessary line organization addition to the agile organization in a complex hardware engineering environment In the LEGO project, if one team specializes only in connectors and another only in building loops, the teams may face delays as they wait for each other to finish their part. This creates bottlenecks, where too much specialization slows the overall process. To avoid this, teams are encouraged to develop cross-functional skills—learning enough about the other modules to avoid waiting too long for dependencies. Allowing some specialization is necessary, but balancing it with broader competence development ensures the project flows smoothly, just as it would in a hardware engineering environment.

?

Attached is my own presentation with the “adapted”provocations on a manifesto that is a bit more geared towards the hardware engineering space. Of course, this is not a proposal to change the manifesto, rather a thought provoking idea that may help you to explain to yourself or others what the intricacies are of Agile for Hardware development.

?

Please comment to this post with your own insights or challenges, so we can start to sum those up and create a shared view of what Agile 4 Hardware and Engineering next steps are…

PS: if you want my slides, please ping and I will send you the PDF. It should also become available in the Event App that we used!

Cheers ,

Eelco

?