Skip to main content

Is SCRUM a good solution for our case?

Last post 12:52 pm May 30, 2013 by Dominik Maximini
3 replies
07:33 am May 29, 2013

Hi all,

I'm posting my question here, to try to reach experienced SCRUM players as this Friday I'll have to do a small SCRUM presentation to my colleagues to try to show them it is an appropriate methodology for us and the company.

Here is our context:

- small company: main business is developing measurement devices + firmware & pc software development
- Since 2 years, a team member has been elevated to "Technical Director" - by ambition, not for beeing skilled for.
This colleague has a personality incompatible with some SCRUM principles;
- he needs power
- his goal is to put his fingerprint into the development results
- he says he has the technical basics knowledge on both area while it's not true
- he camps on his point of view without taking in consideration others' point of view
- he loves spending a lot of time to discuss about "how we'll DO things"

He is a mechanical engineer and have no experience into software development or electronic.

Those facts created some conflicts between him and several team members.
The team is composed as follow:
- 3 software developers
- 2 electronics engineer (1 more will come)
- 1 mechanical engineer

1 electronics engineer has already left the company because of the problems.

Because of this, I made some research to see how we could work in a better way, and then found SCRUM.

Now, I would like to know if SCRUM could be applied for our team, which is composed by software engineer, electronics engineers and mechanical engineer.

We are both working on the same global products, but each specific area is working on its specific part.
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.
At least, not while it's building.

If the actual Technical Director (the mechanical engineer) will be there during the Sprint Planned Meeting, he couldn't resist to participate in the reflection and continue to go deeper in technical details like he loves.

Many thanks in advance for your comments.

03:24 pm May 29, 2013

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.

04:09 am May 30, 2013

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)

12:52 pm May 30, 2013


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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.