As the year is ending, we are reflecting on a long year of researching, exercising, teaching, and experimenting with using Agile for teams developing physical products (i.e. either Physical Products, Cyber-Physical Systems, Hardware, whatever you’d like to call it). Having visited numerous of conferences, having worked with numerous clients, and having hosted various workshops, we took the time to jot down some of our thoughts and reflections about the field of Agile (for) Hardware.
The continuous misconception of Agile as a silver bullet has been advocated since the initial publication of the Agile Manifesto. While the manifesto (which is approaching its 24th birthday at the moment of writing) shares values and principles to adhere to when ‘finding your way of working’, it often has been seen as not practical or ‘guiding’ enough. Hence, the existence of methods, frameworks, and more concrete toolboxes.
Our experience is that engineers, project and product managers, line managers, and others involved in complex systems engineering require more detailed guidance on meeting structures (who is involved when), roles and responsibilities (who decides on what), and scenarios (what happens if….). We have seen a lot of frameworks, methods, and toolboxes which have proven themselves in a context (e.g. a specific industry, with specific legislator obligations) rendering them untransferable to environments in another industry. The fact of trying to ‘copy-and-paste’ ways of working has always been a head and heartache of Agilists, and is happening in the hardware industry as well. The hardware industry however, is way more diverse. The physical aspects of the Electrical Engineering competence is vastly different than the one from a Reliability Engineer, who focusses mainly on the wear and tear of materials in a range of conditions. Not taking these intricate constraints into account will render any way of working (whether you call it ‘Agile’ or not) invalid.
We still need to find a practical, follow-able, approach for finding an Agile way of working which works in the specific context with its own, unique constraints.
Upon initial contact with engineers (i.e. the team members ‘Agilists’ refer to) it was surprising how often we have been asked to ‘especially not talk about Tesla or Space X’. It seems the stories, examples, and analogies provided by consultants, teachers, or coaches often referred to startups or organizations who have been built for maximizing delivery speed from the ground up. While most hardware product companies that can benefit from an Agile way of working are established, and have been well-performing enterprises with an established brand, established manufacturing plant contracts, and audited quality procedures. Simply diverting from these is simply not possible, even if the enterprise’s board demands the change. These adjustments are reach way further than ‘lets just work in 2 or 3 week iterations’.
Sharing detailed examples of short-cycled risk-reducing learning-cycles (Scrum enthusiasts call ‘Sprints’) in a specific context might inspire teams to rethink their way of working or the way they are organized. Applying Agile in the context of hardware development is a game of compromise. Let me give a few examples:
Successful product organizations will create new generations of their products. Which means all of a sudden we have engineers working on new generation products and working on the maintenance and troubleshooting of established installed-base products. Multiply this by time and the enterprise is working on a myriad of new products and has a larger amount of products operational in the field, requiring maintenance, analysis, and decommissioning procedures.
Using the concept of stable Agile teams has many upsides (e.g. keeping knowledge together, reducing the scope of a team to become more ‘product oriented’ versus having to constantly refocus on work for another project). But the use of stable Agile teams in the context of an established enterprise also has its drawbacks. The various projects, and products still need to be served. How does the work land at the engineer who can do (part of) the work? Exactly, via a backlog of the team.
Funneling work from different projects and products into a single backlog of a team allows for cross-project and cross-product prioritization – which is great – but introduces the risk of super-fragmented work items during each iterations. Batching work as much as possible with the aim to have a ‘main focus’ during one or more iterations is a difficult, but necessary tradeoff to make. Doing this, however, does require a deep technical understanding of the various work items and requests. For the Scrum enthusiasts amongst us, this is nothing new: The Sprint Goal: an objective “that communicates why the sprint is valuable to its stakeholders” (Scrum Guide, November 2020, Schwaber and Sutherland). A main focus, knowing fully well that there is other work that is not entirely aligned to the Sprint Goal.
Ah 2025… there is so much more to explore and to learn. We are looking forward to it.
For all the Agile Hardware enthusiasts; wishing you a great 2025!
Footnotes: