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?
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:
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.
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.
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?