Agile hardware development does not begin with a new organisation.
New roles, new teams, new planning cycles — and still the bottleneck remains. Why agile hardware development begins with understanding how value actually flows through engineering.
Background
Over the past few months, one question about agile hardware development has stayed with me.
A transformation approach I worked on was, in the end, not implemented the way we originally intended.
But one insight from it has stuck with me:
Agile hardware development does not begin with a new organisation. It begins with understanding how value actually flows through engineering.
In many transformations, the first step looks very familiar:
New roles
New teams
New meetings
New planning cycles
Existing planning formats become PI plannings. Teams work in sprints. Features get planned, dependencies are visualised and discussed regularly.
On paper, a great deal changes.
Only one decisive question sometimes goes unanswered:
Does the product actually reach the customer faster and better as a result?
With physical products in particular, that is not a trivial question. Hardware development brings longer internal and external lead times, dependencies between different engineering disciplines, and the need for genuine system integration. Research into agile hardware development describes exactly these characteristics.
The problem here is not PI planning, Scrum or SAFe.
PI planning, for instance, is meant to align teams, make dependencies visible and plan ahead together. Current SAFe guidance for hardware also goes well beyond meetings and team structures, addressing digital engineering, systems engineering and shorter learning and feedback cycles.
The problem arises when we mistake introducing a framework for transforming the engineering system.
Because before we ask how teams should be organised, we ought to understand:
How does value actually arise in engineering today?
Where does work wait?
Where do handovers occur?
Where do decisions get stuck?
Which dependencies prevent real flow?
Where do engineering changes originate — and why?
How quickly can we understand, validate and implement the impact of a change?
These questions shift the perspective.
Suddenly we are no longer optimising for everyone being as busy as possible, but for value flowing through the overall system as quickly as possible. — An important difference.
Queueing theory already shows, in principle, why maximum utilisation and maximum speed are not the same thing: the closer a system comes to its capacity limit, the more queues and lead times can grow. In lean product development, too, waiting, handoffs, rework and overload are therefore regarded as central sources of lost time.
So perhaps we should ask less often:
“How well utilised are our engineers?”
And more often:
“How long does an engineering task actually wait before it moves on?”
This is exactly where systems engineering becomes central for us — not as another role on a new org chart, but as a way of looking at requirements, functions, architecture, different engineering domains, integration and validation as one connected system.
That also matches the basic idea of systems engineering: not optimising individual parts, but understanding the overall system and, above all, the relationships between its elements.
In my view, a particularly interesting entry point for this isengineering changes.
A change often runs right across the entire company. From the requirement through to manufacturing.
Follow such a change end to end and it very quickly becomes visible where information is missing, decisions are waiting, manual handovers arise, or effects on other components are hard to determine.
Current research on MBSE shows, for example, how linked system and domain models can support impact analyses, check changes automatically and considerably shorten feedback loops — for us, that is real engineering agility:
Not moving a change through a board faster, but designing the engineering system so that it can understand, assess and implement a change faster.
This becomes particularly visible in the step fromengineer-to-order to configure-to-order.
Configure-to-order does not come about by organising developers differently. Among other things, we need to understand:
What is standard, and what is genuinely customer-specific?
How do products need to be modularised?
Which components can be reused?
Where do we need stable interfaces?
Which platform carries different product variants?
How do we make sure configuration, engineering, quality and testing work together?
Research on modular product architectures and configure-to-order shows exactly this connection between product architecture, modularisation, configuration and the transition from ETO to CTO. Product platforms and product families create the basis for deriving variants from reusable elements, instead of developing afresh for every order.
And only from that, in my view, do the organisational consequences follow.
Which teams do we need?
Where should responsibilities sit?
Which decisions must teams be able to make themselves?
How do we cut value streams?
Which KPIs encourage flow — and which still reward local optimisation?
Perhaps this is precisely where a common thinking error in agile hardware transformations lies:
We first try to build an agile organisation — and then hope that agile engineering will emerge from it.
I would reverse the order. First understand the product and the engineering flow. Let us create the technical preconditions through systems engineering, platforms, modularisation, quality and testing. Only then do we design an organisation on top of that, one which supports exactly this flow.
For me, agility is therefore less a form of organisation than a capability of the entire engineering system:
How quickly can we translate new insights and changes into validated customer value?
That is why my most important question at the start of an agile hardware transformation would still not be:
“How do we organise our teams?”
But:
“How does our engineering have to work so that these teams can actually succeed in working in an agile way?”
How do you experience this?
If, before a hardware transformation, you could examine only one thing first — the org chart, or the path of an engineering change from trigger to validated solution:
Where would you start?