Is rotating developers on a project a good or bad idea?

Question

I'm working on a small team that will begin working on a large new project with another small team. The other team is currently working on a legacy system that they have been working on for years.

The manager has decided that the developers from my team will be rotating every few months to replace developers working on the legacy system. That way the other team will have a chance to work on the new project and have a better understanding of the new system.

I want to know the benefits and drawbacks (if any) of rotating the developers from the project every 2-3 months.

I know that this is a similar question to "Is rotating the lead developer a good or bad idea?", but that question focuses on a lead developer. This question is about rotating the entire team on and off the project (tech. lead for the new project may or may not be rotated -- I don't know yet).

Answer 1

I'm surprised that everybody thinks this is such a good thing. The authors of Peopleware (which, IMO, is still one of the precious few software project management books actually worth reading) strongly disagree. Almost the entire Part IV of the book is dedicated to this very issue.

The software team is an incredibly important functional unit. Teams need to jell to become really productive. It takes time (a lot of time) for team members to earn each others' respect, to learn each others' habits and quirks and strengths and weaknesses.

Certainly, from personal experience, I can say that after a year of working with certain people, I've learned to laugh off certain things that used to rile me up, my estimates as team lead are much better, and it's not too difficult to get the work distributed so as to make everyone happy. It wasn't like that in the beginning.

Now you might say, "Oh, but we're not breaking up the whole team, just moving a few people." But consider (a) how blindly unproductive their replacements are going to be in the beginning, and (b) how many times you'll find yourself or other teams saying, without even thinking, "I really liked X" or "This would have been easier with Y still around", subtly and unconsciously offending the new members and creating schisms within the existing team, even sowing discontent among the "old" members.

People don't do this on purpose, of course, but it happens almost every time. People do it without thinking. And if they force themselves not to, they end up focusing on the issue even more, and are frustrated by the forced silence. Teams and even sub-teams will develop synergies that get lost when you screw around with the structure. The Peopleware authors call it a form of "teamicide".

That being said, even though rotating team members is a horrible practice, rotating teams themselves is perfectly fine. Although well-run software companies should have some concept of product ownership, it's not nearly as disruptive to a team to move that entire team to a different project, as long as the team actually gets to finish the old project or at least bring it to a level they're happy with.

By having team stints instead of developer stints, you get all the same benefits you would expect to get with rotating developers (documentation, "cross-pollination", etc.) without any of the nasty side-effects on each team as a unit. To those who don't really understand management, it may seem less productive, but rest assured that the productivity lost by splitting up the team totally dwarfs the productivity lost by moving that team to a different project.

P.S. In your footnote you mention that the tech lead might be the only person not to be rotated. This is pretty much guaranteed to mess up both teams. The tech lead is a leader, not a manager, he or she has to earn the respect of the team, and is not simply granted authority by higher levels of management. Putting an entire team under the direction of a new lead whom they've never worked with and who is very likely to have different ideas about things like architecture, usability, code organization, estimation... well, it's going to be stressful as hell for the lead trying to build credibility and very unproductive for the team members who start to lose cohesion in the absence of their old lead. Sometimes companies have to do this, i.e. if the lead quits or gets promoted, but doing it by choice sounds insane.

Answer 2

I don't see much of a downside here myself. The rotation gets you:

• Cross pollination of institutional knowlege -- everyone will know the legacy project and the new one, at least in theory.
• Cross training -- different projects require different things often. You grow much more as a developer working in ugly, legacy projects than in nice, clean greenfield projects.
• Fundamentally better projects -- nothing like having a new team coming in to make you finish documentation and clean up ugly processes you are willing to live with but not publicly admit to.
• Better code -- more heads are better in most cases.
• Likely morale improvements -- variety is the spice of life. And who wants to be stuck in legacy project bug fixing / duct taping mode permanently. Also keep in mind your "new" project will become legacy at some point, do you want to be stuck there forever?

Probably the only downside is the productivity drop you get from switching places but that should only hurt bad the first go round. Afterwards both sides will have some seat time in both places and the ugly parts of the handoff will probably be better understood and perhaps solved.

Answer 3

Interestingly, in my experience we have often started our projects with this very intent. Down the line we have often failed to act on this intent due to constraints on the newer project and a belief that the cross training is too expensive.

I do always wish we had managed it though, as long term I believe it is beneficial to all parties - team, company, client & software. 2/3 months sounds like a long enough stint that there is limited risk of any serious negative impact, there is no context switching going on for the developers involved except at the changeover point at which time they can dedicate themselves to the alternative project.

A couple of possible benefits not mentioned:

• Better project management. If the project managers for both projects are on board then it is their best interests to work hard so that transition periods are not painful for either project. This is turn (depending on your setup) could yield tighter collaboration between the PMs and development teams.
• Better (proactive) documentation. If you know you're getting switched in and out of a project it is not only in the project's best interest, the companies best interest, best practice in general, but now in each developers own best interest to make life easy whilst they are bouncing around.
• The morale thing is a big deal, if your developers haven't had enough of being stuck on a legacy project, then they might not be the developers you want! If they have, switching them around and getting other developers to work on it will make them feel love for your company - they just might tidy up the bits of code they thought nobody would ever see as well. Legacy systems are often seen as second class projects which is often to their detriment, maybe this way you help change that perception to.

Answer 4

Rotation is a good thing for the company, and can be a good thing for the developers too.

There are lots of good reasons and Wyatt has mentioned many of them in his answer.

That being said, in your situation, you may find when introducing this, the developers who are moving off the newer project onto the legacy project may well not be happy, so there needs to be very clear communication why this is happening and how long it is for, and the plan going forward.

It might be good to think about not swapping the teams wholesale to start and rotating 1 or 2 devs to start with, though this might seem like singling out people for a demotion (which some people may see it).

Answer 5

Agree with Aaronaught that is very strange to see how many people just don't see downsides.. Few bad thinks, that you can point very quick - code doesn't have owner and when everyone is responsible for everything is not that good for quality. Developers aren't resources (even they are called like that very often by managers), they are people and for team is very important to know each other, rotation makes a bit chaos there. If you work for some project for longer time you will became a expert (not only in domain, but in that project), you will know where most troubles came from, who will get you best answers or maybe some more specific domain knowledge's etc. If you are new, you will need to learn all this thinks, so it will slow progress. But of course it's also good to know other practices in your organization, how other teams build and organize. It's especially good if your projects are related in some manner, for example one project is input for another (not necessary directly), so will get better understanding of big picture. And of course spreading expertise is good (if you will get time to get these knowledge's).

Answer 6

I agree with Aaronaught's top answer and I have some additions.

• People do not like to be pushed around.
• In a hierarchical business setting, people may be assigned responsibilities that are later taken away from them again. This may just be part of the job. However, the more often this happens, the less likely will these people feel responsible for anything assigned to them.
• The former point also applies to maintenance work on things the people themselves did not create. Cleaning up other people's mess (or more neutrally formulated: unfinished work) is not particularly motivating to most creating individuals.
• The philosophy "a programmer is a programmer is a programmer, they are anonymous plug-ins to be inserted into projects as needed" does not make any programmer feel appreciated or care more about the tasks assigned to him.

The perfect time to reassign anyone is when they start to get bored with what they are doing. There is nothing more to gain, everything is under control, the job is done. In these cases they will typically come forward and ask for other opportunities themselves.

Of course reality is stubborn and often there is no choice, someone may be needed elsewhere because of whatever reason. This is not necessarily bad, it can also make a person feel important and if the person is to solve some big problem, there will be credit in it for him.

Just shuffling folks around to spread knowledge is likely to increase turnover. That way knowledge will be spread, but it will be spread outside the company which is probably not the intent.

Answer 7

TL;DR Make it one team and then it's one team supporting 2 projects.

To echo @Aaronaught I think mixing teams can be problematic as it may take time to acclimate to new practices, processes, etc. If you rotate too many people to quickly the team will lose it's identity. This leads to more questions, confusion and time spent trying to make up for that identity.

On the other hand if there is a concerted effort to join the 2 teams into one team and have 1 team support 2 projects I think that works great as long as the team isn't too big. I have been part of numerous teams which support multiple projects. The closer in technology the 2 projects are, the easier the transition. In my experience the higher cost in transitioning from one project to another comes when crossing languages, client/server (GUI especially), industry (medical, web, game), or other similar lines. The trick is get different people to work on the project frequently enough to gain the benefits, but not so often that the transition cost exceeds the benefits.

Then benefits to getting more people on a project is fairly well known, as are the costs.

Answer 8

Rotation of Programmers is good thing from company point of view and developer point of view.

From a company perspective

1. Management will get to know , the strength and weakness of particular developer whether they can handle multitasking or not and adaptive to changes .
2. If some developer leaves company for some reason , company already has backup ready for future.
3. It will enhance performance of project , as many people will work on it , same thing get tested by more and more developers. (Testing resource wastage minimized)
4. All team members works in team and it will boost performance of project and in future management will get to know , what kind of team needs to be made while implementing difficult module or task.

From a developer perspective

1. It will make developer more positive as his confidence increases.
2. Developers gets better and better ideas from others team mates code and they can use those technique in future development.
3. From better ideas and suggestions from other team members productivity of developer increases.

Only one main thing , need to keep in mind that,

Rotation of Programmers should not happen very frequent. after 60% - 70% development done then only shifting will be beneficial.