We are a development software 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 read on the net : 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
I don't see how Scrum doesn't allow part timers? I have been on many scrum teams and we almost always have a resource that is not full time. Or we have a resource that is split between a couple of projects. We manage this by having the developer dedicate a specified amount of time to the project and we plan around that allotted time. Most agile project management solutions allow this style of resource management.
There are many approaches for scrum, honestly I haven't seen one company that do "pure" scrum. If you will be able to organize your scrum well you may have profits from this. But you should think why you want to change your process to scrum, maby it's pointless.
I think you should try scrum and see if it was worth it.
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:
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:
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.
Although I have not the biggest mileage with SCRUM but the general rule is that when SCRUM is not working as well as it should it is usually because the sprint is too focused and the team has many tasks-responsibilities that extend beyond the sprint`s scope that are not taken into account. As such these tasks are then perceived as nuisance by team inside scrum and scrum perceived as nuisance by people left outside.
We have not yet tried SCRUM all out, however I did a few experiences here on many ways it could be implemented and the best results were when the team included people from many departments (Test, QA, Implementation, Dev, Architecture, Marketing). This implies that these persons are not full time in the team but the fact that they have tasks assigned to them in the scope of the current project means that they are usually more willing to spend the time on it.
Next biggest benefits is that it is possible to set aside some buffer time for unknowns such as spurious but critical support dev. When these occur a smaller team forms up and temporarily spins off from the main scrum to deal with the issue.
Finally things like installations, configurations etc are part of the scrum and as such are tallied with it.
Another approach that I will try next is to extend the idea so that instead of the one scrum-to-rule-them-all approach I will try to get smaller teams in place for each specific needs. The main problem with this for now is that not many people can assume the role of scrum master so right not it`s more chicken and egg.
On a more general note, I used SCRUM here but I never apply things by the book. I consider these techniques and approaches as idea buckets to draw from and experiment with to get the best possible match for our needs. However for this experimentation to work it sometimes have to be done subversively (you do scrum but never formalize that you do it). I find it the best way to soften them up to adopt new approaches and to cut more easily through the inherent change resistance we always confront ourselves with.
So far, by doing this, the workflow naturally evolves towards scrum-XP-agile-TDD type and slowly get them to shun the dreadful cascade they are so encroached in. Hopefully, in time they will realize that the grass is so much greener on my side of the fence :-)
In our team we have support tasks included in the sprint. For each sprint we make an estimate how much support time each of the products are likely to need, and add those as tasks in the sprint. That way the sprint doesn't suffer, unless the support demand is a lot higher than expected (which, of course, may affect the time reserved for support in upcoming sprints).
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.
Very good question indeed. I have seen this statement "all members must be full-time" in almost every paper, article, book etc. I have red on Scrum but yet I haven't seen any argument to why this has to be the case. In large organizations I would expect that you will have developers that do nothing else, but in small organizations it must be very common to have developers that can't commit 100% to the sprint and Scrum is designed for small teams! The focus factor should be able to handle this just as anything else.
Where I work we have had developers get pulled off project for things like support requests or the team lead has meetings about other projects so there are times where someone gets to say, "Non-project," so it is communicated that this person isn't currently contributing to the Sprint.
Efficiency comes from being able to focus on the tasks included in the sprint. It is not something another development model can work around. But developers being assigned 'other tasks' are still a reality, such as support, training, or technical pre-sales.
Support is inherently unplannable for most places. Training and pre-sales tend to be somewhat time-boxed, as in "Mr X spends N days with customer".
I suggest you try to divide the developers into two or more teams. Have the task of taking support during this sprint cycle between teams. That team should only have tasks that one can afford failing to meet. It should do its best to solve support issues without interrupting other teams.
We've seen good results with this.
It sounds like the management described aren't really on the boat with scrum. I suggest very short sprints, 1 week or so. So whenever you get a sales person or management wanting to interrupt, try them if they can wait to get their thing through and done for the next sprint that is just less than a week away. Scrum should not be something the developers are doing alone. It needs to be in the whole chain out to the customer.