Where I work, we have a lot of silos of knowledge. Basically each member of the development team is the expert (and sometimes the only one that knows a thing) on certain pieces of the overall software. For example, one person might be the expert on the rendering engine of a game. Another is the guy that works on the GUI. Rarely do the two intermingle. The concern is that it doesn't make sense to have the GUI guy work on Networking stuff, when there is already someone that can (in terms of efficiency) get something done better because they are already familiar with it.This situation seems to make sprint planning difficult in SCRUM. It's quite possible that people on the team have no tasks or are seriously underutilized in a specific sprint simply because there is nothing there they are the best fit to work on. This makes calculating velocity unreliable as it will vary based on who actually gets more assignments during one sprint versus the other.How would I overcome this issue? It seems like the focus should be more on the tasks and what needs to be done and less on the specific people to work on them. I think upper management will always prefer things to be done as quickly as possible. And if they see that GUI developer estimates 21 story points on a task related to the Engine, where the Engine guy estimates 5 points, they will question why we chose 21 (The goal would obviously be knowledge sharing, but this will cause the team to work inefficiently overall).
In Agile SCRUM, how do you handle even distribution of work in a sprint between experts?
agile;scrum;planning;sprint
Where I work, we have a lot of silos of knowledge.Not good.The concern is that it doesn't make sense to have the GUI guy work on Networking stuff, when there is already someone that can (in terms of efficiency) get something done better because they are already familiar with it.Except of course that it leads to this sort of scenario or the ever present what happens if Bob gets hit by a bus? problem.How would I overcome this issue?First, upper management doesn't get to see your estimates. They don't get to see person level assignments. They should never know you picked 21 over 5. They should see that at the end of the sprint, the team got cool stuff done.Beyond that, you should cross train your people so that instead of 5 and 21 estimates you have 5 and... 15. After that, it is up to your project manager and/or team lead to make sure that your features are prioritized to space out the work. Don't line up 90 hours of renderer work as the top priority if you know the renderer expert has got 60 hours in the next sprint. It'll still happen sometimes, but managing the natural ebbs and flows of work vs. people is a common need, even with agile's focus on doing things once they're needed.