Is SCRUM a good solution for our case?

The person you describe to me sounds like being strong willed, convinced of his own opinion, convinced that he is always being right. He doesnt listen.

This sounds like a personnel problem, and personnel problems imho are rarely resolved by methods / frameworks / reorganizations.

A framework like scrum migh slightly migitate the problem. For instance, if you leave him director and if you can create a scrum master and a product owner with the power to keep him out of the team, you can solve it. The scrum guide as far as i can see it provides no basis for technical interference from management, technical or otherwise. The development team is self organizing - the development team can decide to seek his advice, but he cant just drop in and tell them how to do their job, or even start endless discussions with them. The DT just needs to do its job, and should organize it the way they see fit best.

But from your post it looks unlikely that you can find a scrum master or product owner who stands up to him. If you try it, the scrum master can tackle it on management level while the DT must back him up and refuse discussions.

If actual DT could push him back, and if we all try to do SCRUM;

Can someone explain me how to make the following work:

I'm trying to figure how the Sprint Planning Meeting could be efficient if all team members are there.

I don't see the need to spend the electronics engineers time to plan the sprint related to software development.

The three PC developers are most of the time working on different software/project;
the electronics developers are working on their electronics and their work are linked to software development only after several "srpint iteration", once the "prototype V1" is reached.

By reading SCRUM I always have in mind that for us, it's like if we'll plan a sprint per team member.
I feel it's not the good way to practice SCRUM, but on the other hand it is how we are already working now.
(but without enough communication, without defined objectives per release, without enough knowledge transfer between the different developments)

Codefire,

Scrum will not solve this problem for you. Instead it will make your problems painfully transparent, for example by showing conflicts between the Scrum Master and your technical director. However, maybe transparency is just what you need - it's up to you to solve that riddle.

In regards to the question if Scrum is applicable to a team consisting of SW + mechanics + electrical engineers + firmware developers: I have done it with several companies and it does work. However, you need to manage that very differently from a "pure" software development situation. As you probably know, process circuit boards often take 6 weeks for delivery, tasks are not easily exchangeable between colleagues and the way of thinking differs amongst professions. Depending on the situation, I have seen different approaches work:

1) Doing two teams (one doing HW and electronics, one doing SW and FW). Advantage: Easy to manage, you can use average-skilled POs and Developers. Disadvantage: They never will be one team, each one focuses on their own area and you have no guarantee that the resulting product will work. The blame game is often played (it's always the others). The HW team will see no reason why to use Scrum - essentially because they will continue working exactly as they did before. At the end of the day, you will most likely be running a waterfall project with an iterating SW team.

2) Mixing both teams up and pursuing the same Sprint goal. Advantage: You have one team, great team spirit, and working products at the end of (well - almost) every Sprint. Disadvantage: You need the means to do rapid prototyping, the development must be aligned (e.g. it doesn't work if the mechanics are "done" already) and you need a reason why you pursue Scrum. Otherwise your team will not follow you. In addition, you need a highly skilled PO who is able to provide requirements that have to be solved by a combined team effort. This is hard for many people.

In essence, if you just want to "get rid" of your technical director, I would not recommend you to use Scrum as a tool to do that. It won't work just like that. Get a coach (not necessarily a Scrum-coach) instead.