Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
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?
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.
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.
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.
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!
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.
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:
hope this helps!
