11

I often see projects at my company that are full of part-time developers, meaning they work some % on different projects.

Additionally, management seems to be on the Agile hype train. I feel that the agile methodology does not work well with part-time developers. How do you best manage the project with things like tasking when at any time some members may run hot on their other project(s)?

Even things like making a Gantt Chart get confused in the fact that you allocate a time for a task, i.e., 4 days, but I do not know of a way to consider that those 4 man-days may be 8 calendar days.

Improve this question
2
  • Do you mean part time in the sense that they might be looking after their kids or taking time off, or do you mean full time with split attention?
    – Nathan
    Commented Mar 18, 2017 at 2:23
  • Full time w/ split attention.
    – Eugene K
    Commented Mar 18, 2017 at 2:46

4 Answers 4

Reset to default
10

Multitasking kills productivity. Task-switching costs can be deadly.

What I would suggest is to make Management aware of the costs and risks of having developers working on multiple projects simultaneously.

Even if for some magical reason task-switching did cost 0 time, why would you want to finish Project A and B in ten days, when you could instead focus on Project A exclusely, finishing it in six days and then focus on Project B exclusively, finishing it four days after that?

Improve this answer
3
  • Firstly, I fully agree with what you say. It can be complex though when you receive things like 1yr contracts w/ clients. At which point, no matter really what you do, you're going to be working on the contract for 1yr. The difference is what the end result of the project is, in terms of deliverable, and in terms of personnel improvement.
    – Eugene K
    Commented Mar 17, 2017 at 23:13
  • Split the team - have half the devs focus on project A and the other half on project B.
    – HorusKol
    Commented Mar 19, 2017 at 8:46
  • 1
    This is the correct answer. "Full time w/ split attention", ie it's within your power to have full time devs. Stop shooting yourself in the foot and we can avoid questions about how to best run marathons with a hole in your foot.
    – Nathan
    Commented Mar 21, 2017 at 10:08
2

One of the key tenants of agile (and scrum in particular) is to highlight problems in your systems. Saying a development system is agile, and people have to multitask, is a problem - so be clear in its impacts. While its tricky giving a clear answer without knowing your development methodology, some ideas are

  • If using story points, sprints and velocity - be clear in your reporting of velocity when it has been impacted by other projects. So you may report at the end of each sprint, velocity 10 -> 50% utilisation on other projects.
  • When reporting on burndown, include another factor (maybe a bar chart overlaid on the back of your graph) showing other project impacts for each sprint.
  • If using gantt charts, MS project is quite good at differentiating between Work for a task (eg 4 mandays) vs. actual start and actual finish and elapsed days - they can be rolled up and reported on.

By rolling this data up, and supplying your management overlay, you can report to upper management your progress, and what impacts multitasking has on progress.

Improve this answer
1

There are plenty of people who could be involved in an agile project that can't commit 100% - I think a lot of people get too hung up on what the ideal agile scenario would look like that is based on big development teams which ahve the opportunity to be more nimble in any event.

If some people cannot work 100% then they can still be a valid part of the velocity & team cadence. I do agree with the comments that task switching is a productivity killer. So if someone can commit to 50% or 60% of their time to the project it might be better if they work Monday to Wednesday exclusively on the project - leaving Thursday/Friday for another project or on BAU tasks.

I like the idea of the Agile hype train - the rails haven't been laid for the second half of the journey but the train is on its way, who knows if it will change course to a different town along the way!

Improve this answer
0

In my experience, the key element is not the percentage of time involved, but rather the stability of the team overall.

We ran projects in which nobody in the team had 100% of his/her time committed to the project, and it worked. It doesn't work if you have the same people available on a Monday in a week, then Wed/Thu in the following week, then not at all in another week and so on.

Aiming at a constant pace is key, and you simply can't do that if the situation keeps changing every time but, you definitely can, let's say, have a team in which everyone is involved 3 days a week, if they can work together, and focus on their sprint, and not being interrupted.

See also: https://www.infoq.com/news/2011/10/sustainable-pace-how and http://www.allaboutagile.com/the-value-of-stable-teams/

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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