Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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

share|improve this question
2  
There is a question about this at ProjectManagement StackExchange - Do you know any companies that rotate developers between different projects on regular basis? –  Spoike Sep 6 '13 at 13:11
2  
I didn't wont to make this into subjective / argumentative question by giving my personal opinion in the question. My gut feeling is that this is not a good ide, but maybe there is something that I don't know about :) –  Christian P Sep 6 '13 at 13:13
1  
What reason did the manager give when you asked him why? It's in a company's best interest to have shared knowledge about a product in case developers leave. –  dcaswell Sep 6 '13 at 13:13
1  
That's a problem. If your management is not already being completely transparent about this then it's probably a sign that they haven't thought it through at all. –  Aaronaught Sep 6 '13 at 18:30
1  
What I would suggest is that you make the intital team that starts the project composed of some current legacy devlopers and some current new project devlopers. Keep them through the porject. At the end the lagacy devlopers support the new product and the new devlopers join some other legacy developers to do the next project. That way the team is teh same through the project (Or major release) but legacy people get up to speed on what they will be supporting later. New hires shoudl generally start on legaacy unless they have some special skill you team doesn;t havea nd needs for the project. –  HLGEM Sep 11 '13 at 17:21

7 Answers 7

up vote 65 down vote accepted

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.

share|improve this answer
2  
Don't disagree entirely - however its not without its flaws - Teams can and do built empires, sometimes these crumble Productivity is not always the most important aim of a manger, who (if any good), is looking more towards the end game than other might be. –  mattnz Sep 7 '13 at 4:06
2  
@mattnz: What "end game" is there for a manager other than high productivity, employee retention, and being able to ship on time/on budget? I'm talking about ethical managers here of course, who genuinely want to do what's best for the company and aren't using the team or project as a vehicle to further their own personal career goals. A software organization wants empires - empires are stable and make money - and yes, empires can fall, but they're far less likely to fall than a house of cards. –  Aaronaught Sep 7 '13 at 4:36
2  
rotation is better than folks leaving the company entirely –  warren Sep 9 '13 at 18:43
3  
@warren: If those two options are your only ones, then the latter is almost inevitable. –  Aaronaught Sep 9 '13 at 23:34
2  
@maple_shaft: If you're understaffed, your projects will be late. Rotating developers (AKA multitasking on an organizational level) will only make the project slower. That's an indisputable, first-law-of-thermodynamics (figuratively speaking) fact, as you incur all of the same dev time plus all of the context-switching time. Speaking as both a developer and team lead, "hedging bets" is a very weak argument generally used to mask serious management and morale problems. And as for being equitable and the legacy software issue, didn't I already address that under "rotate teams instead"? –  Aaronaught Dec 17 '13 at 6:19

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.

share|improve this answer
18  
I don't see how my morale would be improved if I got "demoted" to work on the legacy system. –  Telastyn Sep 6 '13 at 13:18
3  
A couple of disadvantages are in initial development time going up and the specific other tasks of the legacy team getting lower priorities. –  Oded Sep 6 '13 at 13:19
15  
@Telastyn If my old company had rotated out of legacy work I'd still be working there. Sure it sucks to get rotated on, but it sucks even more to know you'll never be rotated out simply because they need a legacy dev. –  BeardedO Sep 6 '13 at 13:43
7  
@Telastyn and Christian and others: It is your problem if you see it as a demotion. Working on legacy systems is a challenge in and of itself that can give you incredibly invaluable experience to use to your advantage in green field development. Greenfield development really should have a lot less "cred" than it has as it is much much easier than trying to craft new features on an existing base even one without much technical debt. Brown field development is where you find the real craftsmen and women. Yes, you find them elsewhere too, but not the battle-field hardened ones. –  Marjan Venema Sep 6 '13 at 14:28
7  
@MarjanVenema - Sorry, doing some maintenance work in Cobol isn't going to advance my career. Sure, the work might need done and it might even be valuable experience - but if my manager moves me to that full time, I will have my resume out ASAP. The fact of the matter is that some developers will perceive this as a demotion, regardless of what it really is. Balancing this perception with the desire to cross-pollenate isn't my problem, it's the manager's problem; that's their job. –  Telastyn Sep 6 '13 at 14:41

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.
share|improve this answer
    
I think this is how it ends up in most companies. Lofty goals, but the demands of rapid turnaround and minimal immediate cost avoidance usually precludes the cross-training and cross-development due to the lost productivity of bringing someone new up to speed on a project. –  BBlake Sep 6 '13 at 13:46
2  
@BBlake Yes, unfortunately that is the case. Unfortunate, because it is very short-sighted and pretty high risk for a company to "restrict" knowledge of important systems to a lower number of people. –  Marjan Venema Sep 6 '13 at 14:31
1  
Unfortunately, most businesses, including the major worldwide bank I recently left to work elsewhere, are more interested in the bottom line for this project or week or budget cycle, than they are in planning ahead for the costs that will occur when a senior developer (such as myself) leaves. With no budget for cross training on applications only I had advanced familiarity with. Add the dozens of work hours wasted tracking down production problems that I could have solved in a couple hours because I knew the systems. Shortsighted, but that's the corporate way. –  BBlake Sep 6 '13 at 17:24
    
@Marjan:I would be willing to bet that the costs incurred by having to do cross-training on a regular basis will be far, far higher than the costs of training a new hire as needed if someone leaves. Now, if an entire team leaves, then that's a different matter. –  Dunk Dec 14 '13 at 16:36
1  
@Dunk: I don't know that it would. Cross training doesn't have to go as far as making the cross trained an expert in the field that isn't directly his/her own. It only needs to go as far as to ensure that the business wouldn't immediately be in a pickle and at risk of losing clients when the field experts leave causing the development in that field to grind to a halt. Nobody is irreplaceable, but business' do run risks when important knowledge or skills are restricted to very few people. And the costs of that risk becoming a reality can be very, very high indeed. –  Marjan Venema Dec 14 '13 at 18:20

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

share|improve this answer
    
I like the idea of swapping just 1-2 devs to begin with. That will help reduce the initial negative impact on productivity. –  superM Sep 6 '13 at 14:49
    
You are dealing with software developers, not normal people. Software developers tend to be logical. They can't be as easily manipulated as the general public by incorporating ideas such as above. Other tricks are more effective on them, (e.g. bigger monitors, faster computers) but not political chicanery as this idea is trying to do. It will be a negative to those on the new development team, no matter what. Promises of rewards (ie. see above) is about the only way to cover up the bad taste. Of course, it'll be great (at first) for the maint guys, until they realize they aren't up for it. –  Dunk Dec 14 '13 at 16:45

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

share|improve this answer
    
this post is rather hard to read (wall of text). Would you mind editing it into a better shape? –  gnat Dec 13 '13 at 22:21

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.

share|improve this answer
1  
"As long as the team isn't too big" is key here, I think; if each team has 10 people on it, a team of 20 people is most likely too big. Also, if there's any physical separation between teams (the OP doesn't specify) then it won't function as a single team and will make things more disorganized. This definitely could work, but it depends on the situation (can the teams be merged effectively) and also the management's goals (merging is more-or-less permanent, it will add more resources but won't accomplish the same ends as a project rotation). –  Aaronaught Sep 6 '13 at 21:56

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

From company prospective

  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 Developer prospective

  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.

share|improve this answer
3  
I see a lot of bald assertions being made here. Some of them have almost nothing to do with rotation ("management will get to know the strength and weakness of particular developer"?), others are either awkwardly-phrased or just don't make sense ("all team members works in team and it will boost performance of project"?). What are all of these points based on? Do you have a source? Is it personal experience? If so, what experience? Is your "company perspective" coming from experience as a manager or team lead? Have you really seen any of these things work in practice? –  Aaronaught Sep 6 '13 at 21:53
1  
Most of these proposed benefits really seem to be related to simply being on a team as opposed to being rotated between teams... –  Aaronaught Sep 6 '13 at 21:53
    
first one "Management will get to know , the strength and weakness of particular developer." is actually opposite, because it's much easier to hide your weaknesses when you are moving from one place to another, there's always more people/software to blame, why it was late, buggy, not done. –  Dainius Sep 7 '13 at 7:55
    
There's no way in h... that project performance won't be very negatively impacted. Why on earth would you believe a project's performance would be "enhanced"? –  Dunk Dec 14 '13 at 16:50

protected by World Engineer Dec 14 '13 at 16:57

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.