Joe Banks, Nov 18, 2010
In our Studio, it's common for developers to rotate between projects. Often this is by design, in order to increase shared ownership of the code, or take advantage of particular developer's specialized talent. Sometimes it is by necessity. A client may return to us in order to continue work on some "legacy" software we've had a hand in, in which the original team has moved to another project at a client site, for example.
In either case, the numerous benefits of rotation also come with a cost, and we need to accept and plan for that. It takes time for a developer to ramp up on a new codebase, or to switch context back to a familiar project and catch up on what has changed. Velocity may suffer in the short term. I've seen it suffer as I've watched new developers on a project spend way too long getting a development environment set up. I've been that developer.
Despite that pain, I've recently begun to really appreciate these ramp-up bumps and embrace them as opportunities for improvement, both for the code and the team.
Time spent setting up a development environment is time not spent delivering value to your customer. That is why we are ruthless about keeping that step as quick and simple as possible.
Dedicated, shared pairing machines that are already configured are one way to bypass the setup issue completely, and get a new team member oriented quickly. However, nothing quite brings to light inconsistencies and missing pieces like a from-scratch application deployment based only on what is checked in to source control. It exposes assumptions made about the pre-existing state of the target environment; assumptions that may not be true across the board, and wouldn't otherwise be validated until deploying the application in production. It reminds us of manual steps that have have crept into the process and need to be automated. It's the perfect time to fix these problems, and that's exactly what we do.
I'm no longer shocked if a team member takes me aside and asks if I have five (yes, five) minutes to test a clean checkout and setup of a project. The lack of production deployment issues speaks for itself.
Rotation times, as it turns out, are also great opportunities for team building and reinforcing an environment of personal safety.
New or returning team members are commonly the first to point out less than ideal pieces of code. I've noticed that they are often the most highly motivated to refactor those areas promptly, rather than learn to live with technical debt. This fresh perspective is a healthy part of the development process, however, there is the potential for it to leave the existing team feeling criticized. Conversely, the newcomer needs to feel he can voice his opinions without being attacked. There are a couple of techniques we've found particularly helpful in dealing with these issues.
First, we strive to be open about our technical debt. Honestly, our developers know where most of the bad code smells are in our projects. For various reasons we may not have addressed them yet, but we know they are there. When we are proactive about acknowledging and reviewing technical debt with new team members, criticism isn't taken personally.
We also hold retrospectives after orienting a new developer to a project. These are short, 10- to 15-minute, meetings in which we evaluate how well our current process worked at bringing that person on as a productive member of the team and what we can do to improve it going forward.
Both of these activities go a long way toward fostering a "we're in this together" mentality. It reinvigorates the drive to refactor and to make things better for the next generation.
I've been convinced that the benefits of rotating between projects outweigh the costs for a long time now. However, watching it in action on a regular basis in our Studio emphasizes that ramp-up bumps we encounter are not merely costs that need to be mitigated, but also forces for positive change.
