Do you know any companies that rotate developers between different projects on regular basis?

Question

I work for a smallish outsourcing company of about 30 people, nearly all of them developers. At any given moment we have 6-9 projects in development for various clients. Most of the projects are developed by 3 programmers and one tester and last around 6 months, but we have also some long-running projects lasting up to two years. We have been practicing Agile methodologies for a couple of years, and now we use Kanban more and more. Most of our developers are highly-skilled and while we have only a couple of "real TDD" practitioners, everybody does at least "test-after". We don't pair a lot, but instead rely on hallway testing and code reviews.

The problem we have encountered is that after having been acquired by a corporation, which has in the past outsourced all of it's programming work to India, we now handle multiple projects with very significant technical debt, almost all of which will probably run for quite a long time. This is a problem, because morale of the people working on those projects is very low (some people already quit), and the programmers are getting burned out quickly. It has been said that it feels like a prison sentence to be a part of those teams, especially with no end in sight for those projects.

We are looking for a way of increasing morale of the unlucky employees who have to handle the worst projects. One of our ideas is to start rotating people regularly between projects, so that even if someone ends up in a really nasty project, they know that they only have to endure this for a couple of months, and not as long as they work for our company.

We have looked into this idea before, because we think it might be a good way to improve knowledge transfer, shared code ownership and encourage pair programming, but now we have a much stronger incentive to pursue this.

I know of two companies that practice rotating people among projects: Relevance and Pivotal Labs. Relevance has posted an entry on their blog about rotating people, and Pivotal hints about it in some job offers and it was mentioned on Quora.

Do you know any other companies that apply this technique (I'm especially interested in any experience reports)? Is it a good or a bad idea in our situation?

---

EDIT:

After reading the responses, I have come to the realization, that I might have over-stressed the burnout/prison-projects angle a little bit.

In fact, as I have mentioned above, we have had the idea of rotating people regularly before, and the reason for that is that we expect this to:

1. Promote knowledge-sharing, because people who are experts in various fields (DB, JavaScript), will have chance to work with a larger subset of other employees.

2. Improve code quality through continuous code review: when a new person enters a project, it will be a fresh set of eyes looking at the code and pointing out the faults in the design/code itself.

3. Foster collective code ownership: if people are expected to rotate off the project, the code, which they wrote will be maintained by other people. In order to not be left with maintaining a completely unknown, "untouchable" piece of code written by someone else, the developers will have to share the responsibility for various parts of the system.

4. Foster pair-programming: I believe that pair-programming is a good way of developing software. In a team, which periodically welcomes new members, pair-programming is the most effective way of introducing new people. If programmers spend a lot of time pair-programming with new people, hopefully they will be more likely to pair program with other team members on normal tasks.

I am really interested in learning about other companies that have tried rotating people across projects. Has anyone worked in an environment like that or has heard about some company practicing this?

Answer 1

Without knowing how frequently you are thinking of having the regular rotation, it is hard to say what the real impact would be. But unless the projects have either a shared technology or domain (preferably both), I would actually suggest against rotating people on a regular basis. Instead, only rotate the people that have shown signs of burn-out. No matter how good your developers are, there will be some amount of re-learning when they rotate from project to project. And that can easily be just as frustrating as being stuck if it is happening too often.

And really, the rotating will only work for so long unless you address the real problems:

1. large technical debt - I would suggest tackling the technical debt problem head on. Talk to the people in charge of the budget, and point out the problems the technical debt is causing. Ask for a certain amount of budget per month to start dealing with it, and have the developers give their input on what debt is most important to tackle. If the developers are actually allowed to make some headway (even if it is just taking care of small things that are annoying them), it will help.

2. no end in sight - This may be in your control or something that you need to take to a higher level. If the feature set that the team is being asked to work on doesn't seem to have a focus, they can feel like it is just a case of churning out small bits over and over. Make sure that there is a focus to the changes being implemented, and help provide the team with milestones that mean something to them and allow them to feel like they've accomplished something. This could be as simple as focusing for a quarter on a certain type of user whose experience you want to make better, or targeting a specific section of a website to be made better. But make sure the team knows what the current goal is (and what impact they are having).

In addition to tackling those, I would take a step back and think about whether it is just the work that has changed since the acquisition by the corporation, or has the culture been impacted as well? Are the developers still feeling appreciated? Do they hear praise for their work? Do they get a chance to celebrate when a phase of one of the long-term projects does wrap up?

Answer 2

This is a benefit-cost-risk analysis where the answer will be very specific to your organization at this period in time under your current working environment and constraints.

The benefit you are seeking is a morale booster. You may also experience some unintended benefits, as well, like some performance improvement in development cause by no other reason than having new blood looking at the problem.

The cost-risk is the removal of tacit intellectual capital on a specific work stream or project every time you rotate. Ideally, your capabilities are so streamlined and under control that replacing a human resource would have no affect on performance. Sadly, that is rarely the case. Also, you have some probability that the rotation will have little to no affect on morale, but the costs still occur.

Answer 3

Companies' takeovers happens all the time. It's a matter of accept / get used to their drawbacks or search for a new company. It's not something we can choose, it just happens. When these developers joined the company, the culture was different... now, the company changed.

It's not realistic to expect no changes after a company takeover. Not on IT or anywhere else.

On a project level, is important to remember that's part of the game to have better and worse projects, and eventually someone needs to keep the "dark side" up and running.

Now, about the dev rotation suggestion: I totally agree with David, rotating peers may increase morale but you will have costs associated to it. The point is: does it worth? I think that's your real question... but, that's yours.

It's not clear, however, what's required from your team on these prison-like applications. Are they pure maintenance projects or there's room to improve things? You mention they're supposed to be run for quite a long time... so I know that there's time for improvements. Is there budget as well?

Besides, since these applications have been "inherited", is there any new hire joining the company or only the developers leaving their prior projects?

Depending on the above, I see two possible approaches for a PM:

• Opportunity approach: In case you have space to improve the applications, it's a good opportunity to train new hires, pairing them with skilled peers that would present them real-world cases of do-NOT-ever-do-it programming. There are varions of it, depending on the room / budget you have for such.

• Pessimistic / realistic approach: There's no way to improve the mess in place. All that power and knowledge your developers gathered during all those years will be wasted into clumbersome applications. They'll leave the company, eventually. Is important to remember that if that's the case, then new low-skilled hires will be required, and then we're back to the opportunity approach.

Two last things:

• Understand clearly what are the expectactions for such applications (lifecycle, demand, future replacements). Maybe, on the long run, there'll be requirements to build replacements for these applications and their business knowledge will be essential.

• Avoid shortcuts to increase team's morale. Face the problem in a wide open approach with the team, once you're aware of what's expected on such applications. When a problem is in place, you must keep everyone aware of the opportunities. If today is bad, let's focus on the promising future (if there's any).

Hope you success! Once you take your decision, please share with us the outcomes.