Это в среднем - в основном. При этом по прежнему можно видеть такие жемчужины - отрасли, где электроника (а также механика и прочая физика) имеют очень важное значение. Приведу несколько наиболее очевидных примеров:
- Космические аппараты (SpaceX, Blue Origin, etc.)
- Квантовые компьютеры (Q-Ctrl, Google, etc.)
- Лидары для беспилотного транспорта (Velodyne, Dephan-москва*, etc.)
*- кстати, именно в компании ООО "Дефан" (ссылка во втором комментарии) мы смогли успешно внедрить scrum фреймворк для RnD разработки конструкции высокочувствительного датчика.

В чем сходства и отличия разработки электроники от разработки ПО? Приведу наиболее поверхностные:
1. Различается в первую очередь скорость обратной связи от рынка/заказчиков - софтверное MVP делается быстрее. Впрочем, Илон Маск показал нам на примерах двигателя “Merlin 1А” и корпуса корабля “Starship”, что это не такая уж и великая проблема )). Плюс, CAD моделирование и 3D печать сильно сокращают это различие.
2. А что между разработчиками ПО и железа общего - так это командная работа. И там и там мы получаем существенный прирост продуктивности, если над RnD проектом работает кросс-функциональная команда разработчиков.
Как нам сократить системное отставание RnD** электроники от RnD ПО?
1. Создать современную организационную структуру (см.: agile, scrum, OKR, management 3.0, etc.)
2. Собрать кросс-функциональную команду и выстроить в ней атмосферу доверия между участниками
Разумеется, проще сказать чем сделать. Реальная орг.структура будет сильно зависеть от негласных ожиданий руководства, а в команде должны быть мотивированные профессионалы.
И эти вопросы постепенно решаются, когда в компании есть воля к изменениям (как минимум СЕО должен быть глубоко привержен идее перемен к лучшему).

Реалии перемен.
Когда в компанию по разработке электроники приходит agile-коуч/тренер/консультант/волшебник, то он всегда работает как бы между двумя берегами:
1. Рассказать о scrum, OKR и много чего нового, которое прекрасно себя зарекомендовало в разработке ПО. И столкнуться практически сразу с сопротивлением коллектива, мол это у нас не применимо, у нас особая специфика работы - и вообще, уйдите, пожалуйста (см. 3-й закон Лармана)
2. Почти тоже самое, что и в п.1, только пообещать разработчикам и руководству, что мы просто адаптируем эдакую “заморскую невидаль” (scrum, kanban, OKR) к нашим державным реалиям. Разумеется, тем самым полностью нивелируя ценность новых идей и подходов (см. 1-й закон Лармана)
Как ни странно, между этими берегами довольно много живого пространства, если смотреть под правильным углом, верить в людей а также в перемены к лучшему.

>> Кто хочет принять активное участие во внедрении гибких подходов в сферу разработки электроники - пишите в личку, будем вместе создавать активности.

**-речь идёт исключительно об RnD, производство тут пока не рассматриваем.