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?

  • programmers.stackexchange.com/questions/234564/…
    – gnat
    Commented Jun 29, 2014 at 19:28
  • 4
    Why don't you ask the team and tell the manager you do so. What ever the team dreams-up is the solution.
    – rene
    Commented Jun 29, 2014 at 19:46
  • 2
    What happens to your productivity if you dont train a new developer and your 5+ yrs exp developer leaves?
    – ViSu
    Commented Jun 30, 2014 at 6:27
  • It's a valid point however the team at the moment has more than four people with 5+ years of experience. Could they all leave at once? Potentially.
    – SimonT
    Commented Jun 30, 2014 at 8:36
  • what do the team member want to do? It should be their choice!
    – Sklivvz
    Commented Jun 30, 2014 at 13:33

5 Answers 5


One possibility: If you are concerned about loss of productivity by rotating a team member, your manager has the correct approach, and will most likely be seriously concerned (if he's any good), but not saying so.

As companies grow, they become less concerned about immediate productivity and more concerned about continuity and predictability. Issues such as business continuity, key person dependency and technical vitality come into play - the same people working closely together for many years, with no one coming or going almost always ends badly, think the red buss... or more commonly, BBoM (Big Bucket of Money) inflicting multiple casulties on the team.

High throughput at all costs is critical to survival of startups but there is a cost in both technical and non-technical debt. Consistant, repeatable, predicitible processes is more critical to established companies than pure speed. (Think tortoise and hare)

Long term, low turn over, siloed teams are a very real problem for management of larger companies. Are you transtioning from a small company to a big company - or more subtly. from a 'big small' company to a 'small big' company?

If this really is the situation, you need to decide if you really want to be seen to be resisting the changes.

  • It's a well established company with a good sized development team. The company has had this knowledge risk for many years. I'm not entirely resisting the change however there is a delivery expectation for the sprint teams from the senior management hence my comment in my original post regarding big releases.
    – SimonT
    Commented Jun 30, 2014 at 8:29
  • Ah for the days where a small group of freelance staff wee the only ones who knew how the system worked, protected their positions and isolated status... and held the company to ransom with their exorbitant fees. The good old days, well, for the contractors - not anyone else.
    – gbjbaanb
    Commented Jul 11, 2014 at 15:15

"New developer leaves the company - wow we wasted a whole bunch of time."

There are a classical response to this: why if you don't invest time in the training of this developer and he decides to stay at the company?

In my opinion is a good idea that developers rotate between teams, normally this gives developers a better understanding of the company as a whole and creates a lot of learn opportunities for newer developers.

Off course the velocity of the teams change, because the velocity of a team is defined by his developers, normally a change in the team always decrease the velocity of the team. But you are investing in the training of this new developers and in the future of the company, this velocity decrease are the cost of the investment, you can't have the benefits without the cost, and every intelligent manager understand this simple fact if you talk to him in a language he can understand.

  • 1
    Subtle difference in perspectives - I believe in this case 'Velicity is currently unsustainablly high', rather than 'Velocity will be decreased by investment'. i.e. Investment is a requirement of a sustainable business, by not investing, the business is not sustainable, so velicity will, at sometime drop. The only unkowns are how much, how fast, and when.
    – mattnz
    Commented Jun 30, 2014 at 2:21
  • mattnz: Very good point. If Its a necessary investment, for survival nor for improvement, perhaps its much better to consider you actual velocity "unsustainably high" like you say. Commented Jun 30, 2014 at 14:15

New developer will bring down the work rate of at least one experienced person as they constantly ask questions.

This is a good thing, in moderation.

Every process has countless sources of friction - be it tooling-related, design-related, or whatever. Trouble is, a lot of your sources of friction you don't notice. Having someone come on board brings a set of fresh eyes, questioning everything you're doing, and giving an excellent feedback loop.

Sometimes this feedback loop will be obvious: they'll ask why you're doing X instead of Y, and Y will indeed be a better approach.

Sometimes it'll be subtler - you're getting a lot of questions about a particular module, and that's feedback that the module isn't designed well.

Yes, having a new person on the team will slow down your straight-line speed. It's also a great check on whether or not the straight line you're following is the best line to follow.


does rotating out the team members work?

Define "work".

Rotating team members sometimes spreads (good or bad) culture to the different sprint teams. Sometimes it can build teamwork between teams because people get to build friendships that didn't exist before.

  • Does it spread domain knowledge? slowly. Like months slowly.
  • Does it slow down sprint teams? Almost always. It depends on how different the teams are in work, culture and organization.
  • Does it often frustrate people and lower morale, especially for the reasons you bring up - your team being expected to maintain velocity despite this added overhead? Absolutely. This depends of course on the personalities of the people involved, the skill of your leads/management, and piles of other factors. Oh and let's not get into how well disengaged employees pick up knowledge specific to your domain...

Personally, I don't think it is ever worth it. The spread of domain knowledge is too slow, the risks are too high, and domain knowledge isn't nearly as valuable to me as it is to most managers.

If you want to foster good personal relations between teams, then you need to foster good personal relations between people. In my experience, stressing people out with change (shifting social landscapes of their team) and boss orders is not setting them up for success in that regard.

  • I think there are two perspectives to the definition of "work" here. From the management view it'll be that the developer(s) that rotate into the team(s) will pick up the knowledge quickly enough to be able to use it on the next release cycle. From my point of view it's a case of will it do what management are expecting without impacting the velocity of the existing teams to the extent that we end up not achieving what they expect us to deliver.
    – SimonT
    Commented Jun 30, 2014 at 8:48

Why should this be all negative?

New people bring new ideas and insights to the group:

  • New tools
  • Other ways of working

By having to explain the ways of your team to them, people in your team get challenged:

  • Why did we decide to do it like this?
  • Is the reason above still valid?
  • Explaining stuff to people get people out of their confort zone

And the people joining another team get challenged:

  • Learn new stuff
  • Get to know new people

It might change the dynamics in your group, giving other people a boost to take more responsability or a more senior role.

For me rotating can enrich the group as long as the number of developers with technical and domain knowledge in the group is high enough.

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.