In Agile SCRUM, how do you handle even distribution of work in a sprint between "experts"?

Question

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).

Answer 1

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.

Answer 2

To some extent, there's nothing you can do if your teams are that specialized. And if you're asking from the viewpoint of a manager, there's nothing you should do, either. This is a problem for the team itself to solve.

A point to remember is that scrum tries to optimize the team, not the individual. It's perfectly fine (from a scrum perspective) for an individual to be idle. The goal is for the team as a whole to be productive, and if that means the UI guy is idle part of time time in order for the team to be productive, so be it.

As your team matures, the team itself will learn how to optimize itself to avoid having team members with nothing to do. For example, team members can learn to write tests, or they can create documentation, or tackle technical debt, or internal support, or they can be perhaps be in conversations with the product owner about upcoming requirements.

Answer 3

As a consultant, my teams similarly have members with specializations. We need to achieve high quality as quickly as possible in order to best meet our clients needs and our organization's profit margins. It is entirely valid to have team members that are specialized for optimum performance.

HOWEVER: This does not mean cross-training should not occur.

We have front-end developer specialists, but when they are busy our projects can't grind to a halt. If it looks like a .NET developer has some extra time in a sprint, they do not sit idle. They grab something they are less familiar with and use the expert as somebody they can ask questions of. Since the specialist is already working on other things (otherwise the story wouldn't be available to grab) you are not 'wasting' velocity, but are rather increasing the overall team's ability and capacity in that speciality (assuming the time for questions does not negate the increase in productivity). This is a great way to use 'idle' team members to help the overall team velocity and increase the cross-functional ability of the team.

Another option is to use idle developers to pair program, write unit tests for others, write any necessary documentation, help out the product owner with any tasks that might need doing. Remember always that ANY work that needs to be done by the team can always use an extra set of hands to make it happen faster!

Answer 4

Depending on the level of specialization you might consider some type of implementation of pair-programming. If somebody is under-utilized during a sprint, don't worry about velocity, and have them pair up with somebody who is being utilized in an area of expertise that they aren't familiar with. The obvious benefit of this being that members of your team will build skills in a wider variety of areas towards the end of everybody being capable of doing anything.

Answer 5

Silos are bad for a number of reasons. Bus factor was already mentioned. When you have narrow specialization you pay the price of hand off and integration as well.

I like the idea of "not doing anything" for you as a manager - that's the wise advice, however, there things you still need to pay attention to.

1. Priority. This seems to almost always escape from the scene when the question comes to processes (like planning, estimation etc) - processes are there to help you deliver business value, not for their own sake. Ask yourself, or better your team, how the most important thing on your backlog can be done the quickest? They will figure this out. Do not assign work to fill up the idle cycles. Instead of having idle person work on something that is small but not important, make them spend time on improving the way they deliver important value. There is always work to automate/templatize/etc.

2. Team ownership. If you actually have a team (not just hired disperse temporary consultants) work on improving the team ownership feeling in it. It's great when everyone in the team is interested in the work in progress. It is bad when one is yawning during the standup while listening to the update of others he has no interest/understanding of. Try to have the team to work on vertical slices, so that they build one end-to-end experience at a time - then, they will be more bought in all the time, and it will encourage UI guy to help with back-end and vice-versa. As already suggested XP is great to build team ownership and improve knowledge sharing.

3. Smaller stories. 21 is A LOT for an estimation. Can you make smaller vertical slices? That is a skill that your team needs to develop, and it is hard to do in the beginning. What I advocate is to play the planning poker with your fingers (1,2,3,5) if you are out fingers for the estimation value - that is a signal that story is too big to be estimated. Once you master the story creation skill, you will naturally tend towards NoEstimates movement. Simply counting stories will work the best for your velocity. Read this for drawbacks though ;)