Do you rotate agile team members?

Question

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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.