I've got long standing developers in my sprint team. They know the domain, they've been with the company 5+ years and as a team we have a pretty good burn down rate.

There are other sprint teams, some with equally knowledgeable developers and others with newer developers who are trying to get up to speed.

My manager is worried that all our eggs are in one basket and wants to rotate out one or two knowledgeable developers in exchange for the some new guys. I can see their point but can also see the problems that go with that - I'm sure there are others but these are just a few off the top of my head.

1. New developer will have a much lower work rate
2. New developer will bring down the work rate of at least one experienced person as they constantly ask questions.
3. New developer leaves the team at the end to join another team - hopefully he'll remember what he did with us.
4. New developer leaves the company - wow we wasted a whole bunch of time.

I might like to add that the organisation is struggling with agile. It was a traditional waterfall development company and still thinks in big releases and items that are "expected" to be in the release.

If you've been in a similar situation to this I'd love to know you experiences - does rotating out the team members work? Would pair programming or other methods be a better route to take?

Thanks for your time.

I've got long standing developers in my sprint team. They know the domain, they've been with the company 5+ years and as a team we have a pretty good burn down rate.

There are other sprint teams, some with equally knowledgeable developers and others with newer developers who are trying to get up to speed.

My manager is worried that all our eggs are in one basket and wants to rotate out one or two knowledgeable developers in exchange for the some new guys. I can see their point but can also see the problems that go with that - I'm sure there are others but these are just a few off the top of my head.

1. New developer will have a much lower work rate
2. New developer will bring down the work rate of at least one experienced person as they constantly ask questions.
3. New developer leaves the team at the end to join another team - hopefully he'll remember what he did with us.
4. New developer leaves the company - wow we wasted a whole bunch of time.

I might like to add that the organisation is struggling with agile. It was a traditional waterfall development company and still thinks in big releases and items that are "expected" to be in the release.

If you've been in a similar situation to this I'd love to know you experiences - does rotating out the team members work? Would pair programming or other methods be a better route to take?