Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Well, the questions said itself. In my workplace those cases happen, but also, many Agile books promote working in the same workplace and being concentrated in the current project to become faster in the pace of work.

Maybe i'm not that informed about the topic, maybe is not that strict but, that's why I wanted to know what does Agile proposes in cases like those.

Anybody?

share|improve this question
1  
What do you mean by shared? Do you mean that someone can move from one team to another or that someone may be working on multiple teams at once? This would affect my answer. –  pdr Apr 6 '11 at 23:08
add comment

6 Answers

up vote 6 down vote accepted

In the Scrum methodology it merely affects estimation.

You would assign focus factor for that person based on the allocation of their time to each project.

So, if I am working on Project A and Project B equally, Project A would calculate resources like so:

Project A — Team focus factor of 70%
Sam - 10 days, 100% allocation (7 after focus factor)
Joe - 10 days, 100% allocation (7 after focus factor)
Me - 10 days, 50% allocation (3.5 after focus factor)
Total: 25 days * 70% focus factor = 17.5 projected velocity

You might also calculate focus factor separately for full-time team members and for part-time team members rather than once for the whole team, due to reduced efficiency from splitting projects. In this case, you'd use my project focus factor of 50% and multiply it by a personal allocation of 50% for 25%, or 2.5 days projected velocity.

How well this works in practice, is going to be a factor of how well you know in advance how much time a shared resource is going to spend on each project, and how well Scrum is working for you in other ways.

share|improve this answer
2  
My issue with doing it this way is that it doesn't account for task switching very well. For example, consider a 2 week (10 day) sprint. Having a developer with a 50% focus factor, where you get him/her for 5 days straight, is much different than having a developer every other hour for 10 days. The former is much more productive. An extreme example, but you get my point. –  Brook Apr 7 '11 at 13:47
    
@Brook You are just talking about focus factor (1 measurement per person), which is different than project allocation (in this case split 50/50). Focus factor is % of an ideal day that your actual day is worth. Usually it's about 70-80%, but for someone splitting projects, it would be probably be less (which I addressed in the answer). It does rely on some consistency over time. If you can't have consistency, you really shouldn't even be doing Scrum. –  NickC Apr 7 '11 at 15:45
    
the consistency part was really my point. If you've got a team where people are constantly getting pulled in 10 different directions, and you can't change that, Scrum's not going to help you. –  Brook Apr 7 '11 at 16:21
    
@Brook - it's a good point and you helped me think about it in a way I hadn't originally. It sounds like we agree. –  NickC Apr 7 '11 at 16:23
1  
@NickC This seems plausible to do. At the very least, I'm concious that team members can be changed everytime, fortunately it doesn't happen so much. The workplace remain the same always, just that the time given to the project is sometimes half the team member capacity (because the team member is doing taks from 2 different projects). But this seems proper for calculating velocity for different projects at the very least. Thanks for the reference. –  Xanathos Apr 11 at 15:05
show 1 more comment

In my experience in Scrum, velocity can only be predicted if the project & team remain the same and dedicated. If either of these things change, then you can't really use velocity calculations from previous sprints to do your estimation. You can try, but you will be off by much more than you typically would.

In general, you should definitely try to keep the team the same & dedicated at LEAST throughout a sprint, more if you can.

share|improve this answer
2  
Yes indeed! Trying to share members between project just results in all involved projects being delayed. It makes no sense splitting people like that and thinking things will be completed faster. –  Martin Wickman Apr 7 '11 at 20:49
    
+1 for common sense, You just can't assign three women to a pregnancy to get it done in three months. It makes more sense to dedicate people to a specific task. –  maple_shaft May 24 '11 at 1:34
    
I believe this is a "core pillar" of Scrum, actually. The poster seems to mix context when asking "what does Agile say in this situation" (vs Scrum) Is there an Agile (non-Scrum) answer... –  Al Biglan May 24 '11 at 3:36
add comment

In my opinion this will affect all projects very badly. It is not only matter of estimating or planning. Yes you can say that if team members are allocated to three projects and they have 33% allocation to each project you know everything you need and you are done but that is not true.

Context switching is very expensive. Also maintaining full commitment to multiple parallel projects is impossible so those 33% percents of developer time are far away from 33% when developer is assigned to only a single project.

Another place where this totally fails is communication. What happens if a team member working currently on the project A must communicate something with a team member worked on the project A yesterday but currently working on the project B? That is impediment for both of them because the first one needs information but the second is concentrated on completely different project and any question for project A just disturbs him. Scrum master from project A wants his developer to get information as fast as possible and Scrum master from project B don't want his team member to be disturbed by anything not related to the project B. If you want to avoid this you must plan all developers from the team to work on the same project within same days - that is a big complication to whole planning process and something which should be completely avoided.

You also have to plan all meetings to not collide. You must also understand that meeting is actually waste and because of that there should be minimum required number of meetings short as possible to still keep control over the process. But if you have team member working on three projects he must participate in all meetings for those three projects => three times more meetings where developer does not produce any business value.

As conclusion agile is also about reducing waste (yes it is from Lean approach) and sharing team members among teams is one of the worst failures in term of introducing waste and reducing productivity. I guess that delivered business value for 33% allocation to a single project will be equal to business value delivered from 10-16% of full time allocation. That means that developer will not only participate 1/3 time on the project but during that time his productivity will be between 1/3 to 1/2.

share|improve this answer
add comment

SCRUM is based on having a committed team without shared members, therefore you might as well be asking:

Given we have been told we must make true == false, how do we do x

If it is not SCRUM, don’t call it SCRUM!

share|improve this answer
add comment

The key question is about the team member's commitment to the project. Ideally, a team member should be totally committed to the success of the project. This doesn't mean that his time is totally dedicated to to the project, but that he's available to do whatever tasks are required for the project when is working on the project.

Often with personnel that are only part-time on a project, they are only involved for a limited scope of commitment. For instance, you may have a person that only does database optimization.

In that case, it's often best to treat that person as a "resource" instead of as a team member. The team decides how much of that resource they'll want in a particular Sprint, and the give them a very specific set of tasks to complete for the Sprint. Sometimes it's best if the Team has a particular team member responsible for that resource, and they'll do the status updates and impediment reporting for that resource in the daily Scrum.

share|improve this answer
add comment

I believe one of the core aspects of Scrum is to keep the team focused on -one- thing at a time (one project, one story, one task...)

You asked "what does Agile propose" in the situation where you can't allocate the resources to one project... You might consider trying one of:

  • Keep a big Kanban board that spans the multiple projects. As a project has a need, it gets added to the board, as people have capacity, they pull the key stories. The problem is that all projects get managed together which decreases overall predictability for any one project. That said, the individual story/Kanban elements will get pulled and developed by a focused person or team. (You might try creating smaller 4-5 person teams to pull from the Kanban board
  • Only assign committed resources. Keep a pool of dedicated resources for a project. These are protected as a team and interruptions are kept near zero. Also keep a "rapid response team" that doesn't have a backlog and doesn't have a project/product focus. As interruptions come up, the rapid response team deals with the interruptions. When they don't have interruptions, they can focus on improving the build system, adding to the automation test framework, etc. Also, they can help with code reviews/design reviews and troubleshooting tricky/nasty bugs that arise. Manage the development as if this team didn't exist. All they can do is pull in the delivery. Rotate people through this team to "keep it fresh" (people seem to like/hate being on the rapid response team...)

hope this helps!

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.