Engineering Agility Newsletter #4: Sense and nonsense of Agile (for) Hardware

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.

We are not there, not by a long shot

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 24^th 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.

Unicorn examples will not help us further. Detailed real-life examples will.

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:

• What happens if we have multiple small teams requiring an engineer with a background in Optomechanical Engineering, but the company only employs one of these highly specialized engineers? Are we going to ask people to ‘engage into T-shaping’? Optomechanical Engineers might have spent multiple years into specializing themselves academically and professionally, and hence a background like that is not simply ‘T-shapeable’. But being able to explain the struggle of team formation with limited competence availability will help teams to define a good-enough setup.
• No need for Project Managers? Well, delegating solutioning, planning, progress and deviation management is a too large task for an engineering team. Especially if the team is developing a small module, function, or element which is part of a larger overarching system. The ‘just let the team figure it out’-mentality which has dominated and has prevailed in the Agile for Software community, has a detrimental effect on the cognitive load of an engineer in an Agile team developing a hardware product. Large hardware systems require multiple layers of synchronization; technical, architectural, supplier level, and system level integration. Our experience is that the demand on engineers is simply too high to do this without a deeply involved project leader who understands bottom-up planning and the concept of stable, self-steering teams.

Working Agile will not reduce the number of parallel projects

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.

And with that...

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!

Further reads and sources

• Another (really interesting) academic paper on the use of iterative development in a stage-gated product development context. Well done team Zuzek, Kusar, Rihar, and Berlec!
• A podcast with Paolo Sammichelli (author of Scrum for Hardware)
• AutoDesk has announced that their 'AutoDesk Fusion' suite now also supports functionality to benefit Agile Hardware teams

Footnotes: 

• Header image generated by ChatGPT. The text is old-fashioned self-written
• The mentioned companies have not paid for the promotion