Scrum : a good method only for teams with "full time on sprints" developers? [closed]

Question

We are a software development company. We have introduced Scrum.
The problem is that developers can’t spend full time on Scrum sprints like a lot of other companies. They have to do a lot of no-development, out of the SCRUM project tasks !
I've read that : Scrum doesn’t allow part time developers

So, what is your experience about this?
Is Scrum a good method only for teams with developers who only spend time on development tasks focused on the SCRUM sprints?

Thanks for your time

Answer 1

I am working for a company where this is an issue as well. We are trying to use Scrum, but have problems with the following:

• If there is an important support issue, we have to drop everything we do to solve that issue, ruining the sprint.
• Management comes directly to some developers with specific tasks they want to have done.
• Some developers have specific tasks they need to do once in a while (call it support on specific old products)
• Sometimes one of the developers are removed from the sprint to do an important installation.
• The teams have changed often, based on ideas of improvement from management.

With all these issues it is impossible to do Scrum by the book. The velocity for each sprint is basically worthless when the number of people on the team changes all the time.

Still I have found that you get some benefits:

• People work as a team and get inspired & empowered by that.
• The tasks that still go through the sprint are better than if Scrum/sprinting is not used at all, as the feedback cycle is so much shorter than when not doing sprints. The concensus now is that two weeks is a good time.
• Over time the velocity seems to average out after all, giving at least the ability for management to have an idea of how much work can be done over a longer period of time.

My suggestion is therefore to go for Scrum. As in my company, when management and the developers start to see some of the benefits of short cycles etc, they will start to make changes so that more of the work that is considered not a sprint task will be made into a sprint task after all. So I still see benefits of trying to do Scrum. There is no 100% correct way to do Scrum anyway, no matter how hard some books claim there is.

Answer 2

Define a focus factor, the ratio of time each developer can work on the Sprint content only. This focus factor accounts for the time you cannot work on the Sprint items (email, support, meetings ...).

At the Sprint Planning, only plan what can be achieved according to that focus factor: if the Team has 600 hours at 80%, you'll only plan 480 hours.

The initial value can be decided arbitrarily or based on what was achieved during the previous Sprint: 60 days planned and 45 days complete gives a focus factor of 75%.

Then it's all about time management, if the non-Scrum tasks are not interruptions, then it's better to have them at the same time (e.g. on Friday, every members of the team work on these other tasks, non on the Sprint tasks).

This focus factor does not need to be identical for every member of the team. This also allows having part-time member in a Team.