As a consulting development organization, we are faced with the reoccurring challenge of "selling" to our customers the value of one of our core techniques: team rotation. We find it an invaluable part of our process and our culture, but one that some customers can't understand immediately why we practice it. This is an attempt to lay out the case for team rotation as not only valuable, but invaluable, to the customer during any development process.
Relevance is an agile software development shop. That is not to say that we are a Scrum shop, or an XP shop, or any other flavor. It is that we believe strongly in some core principles, and strive every day to mold how we work to achieve maximal results. All of our processes are built around the following three ideas:
From these three principles, everything else we do can be logically derived. We have daily standups, and late-day checkins. We love checklists. We TATFT. We use CI. We work in two-week iterations, and organize stories into releasable features. We have risk assessment meetings and team retrospectives on a regular basis. We pair on damn near everything, including management tasks and client communication. And we rotate our team members, constantly.
Team rotation is one of those areas we get asked about most. “How does that help? Isn’t is just a cost to the customer? What’s the point?” These are valid questions; most software development teams are established for the life of a project, in order to create “ownership” of the problems and their solutions, and continuity from day to day. Traditionally, ownership and continuity are seen as the best way to achieve lasting velocity. Don’t believe that. Not for an instant. Only one role in your project team should be immune from rotation: the conductor (more traditionally, the project manager). There is enormous value to having continuity of the primary communication channel, such that your partners always know who to call, and who to expect on calls and at meetings. But for the implementation roles (developer, designer, etc.) rotation is a key component of creating value.
It isn’t that we don’t believe that “ownership” helps with quality and velocity. We strongly believe that. We just don’t believe that singular, isolated ownership is valuable. Or more specifically, the value doesn't justify the costs. Software developers who “own” a project are single points of failure. The coupled power and responsibility virtually guarantee a certain amount of information hoarding, making them indispensable to the project. When that occurs, velocity is negatively impacted because there is no way a single person can focus on a single problem every day for the life of a project. Because they own all the information, whenever they are unavailable, the project suffers. Sometimes greatly.
Consistently rotating team members is the only way to create shared ownership of a codebase, and more importantly, of the emotional attachment to its success. As you rotate team members through projects, you increase the shared commitment to shipping it that is so vital to good software development. What’s more useful for a customer: knowing that three of your guys are dedicated to their project forever? Or knowing that all of your guys are sharing an interest in getting it shipped?
By rotating team members through this way, you raise your bus number dramatically, buffering against things like (expected or surprise) time off, the ravages of new-school-year plagues, RubyConf, the next iPhone release, Halo Reach, and whatever other major distractions occur in the normal work week. Because so many people will have context on each of your projects, you can roll with the punches and still get people who know the code, know the customer, and know the “project culture” to carry the flag. That’s a huge risk mitigation, and customers benefit from it every day.
Finally, because of the spread ownership, when emergencies arise, there is a much higher chance that the customer will be able to reach somebody knowledgable right away. This benefit is hard to overstate. When today's project team is just three people, but the support list has twelve names on it, you know that you are going to be able to get answers quickly.
Continuity sounds great on paper; the devs build up a great deal of domain knowledge and momentum, and can tackle new challenges based on their amassed experience. In practice, there is an upper bound to this benefit; domain knowledge is definitely critical, but you can amass enough of it in a short amount of time that there is a diminishing return beyond that. And once the learning tapers off, the natural corollary tends to creep in: boredom. A bored developer is likely to pay less attention to critical details in coding and testing. It’s just natural. Rotating your people allows them to be consistently re-engaged in your partners’ problems and avoid the stagnation that a six-month project (or longer) typically engenders in its team members.
Second, continuity of development staff has an implicit assumption that all tasks in a project are created equal. That the developers assigned to the project can tackle all tasks, rise to all challenges, ship all features equally well. But if you have a strong, large and diverse team, you will necessarily have an uneven distribution of skills. Some people will be great jQuery people; others will have a security background; others will kick ass at asynchronous code. By limiting yourself to a dedicated team, however continuous it is, you will miss out on the power you gain by having a diverse team. Rotating developers allows you to take advantage of your organization's diverse skills; that gives you leverage. Without rotation, your team will operate at a least-common-denominator level of quality and velocity; every project will feature tasks that its continuously assigned team are terrible at, thus draining the project of momentum. A steady diet of rotation will usually alleviate a lot of that by allowing you to adjust to the needs of the current tasks.
Finally, by establishing rotation as a core value, you can eliminate the traditional friction between UI/UX issues and code development. UI/UX is often defined as “fuzzy”, hard to quantify or estimate, and difficult to integrate with coding teams. But by rotating designers in as half of a development pair, you can achieve two goals at once: using an existing, natural part of the process to layer in design tasks, and creating a shared culture of design and code excellence among all team members. We aren’t nearly as good at this last point as we would like, but we are trying, and noticing that exposing designers and coders to each other in direct pairing sessions has enormous payoff for the project.
#How does rotation help you, the development team?
There is a benefit to your team, as well. The obvious one is direct one-on-one skill sharing. If you couple mandatory rotation with pairing, you get a massive opportunity to have people learn from each other, on the clock, in real world situations, all the time. Your team can level up across your areas of expertise by being conscientious about how and who you rotate, and where. Understand the pairings, and ask for input, and you can create awesome learning experiences every day.
On top of that, by giving everybody on the team the expectation that they will rotate to a new project within a given window, you minimize the likelihood that they will mentally checkout of the project. I don’t know about you, but if I look at a problem space and know, without doubt, that I’ll be still working on it six months from now, some part of my brainstem tries to throttle that other part of my brain that wants to kick ass. And it is an effort to fight back. But if I know I have a limited window to kick ass within, then I’m all in and working. Rotation guarantees the opportunity for change.
#Mitigating the potential pain of rotation
The biggest potential drawback to rotating team members is that velocity can suffer. Regardless of how much shared context there is, every rotation carries the on-ramp burden with it as the developer re-integrates with the project culture, the current codebase and the current priorities of the customer. The key is to rotate thoughtfully and understand that these costs are universal. As long as they don’t surprise you, you can pay them and easily move past. A key method of preventing on-ramp friction is to only rotate half a pair at any time. The pair who stays on the project can carry some of the burden during the on-ramp period, thus dampening the friction effect. Also, communicate clearly and proactively when a rotation is going to occur so everyone knows to expect the resultant effects. As long as the entire team buys into the benefits of the practice, the costs will be easily bourn. But surprise costs are always a problem, so make sure to announce ahead of time when the rotations are occurring. With luck, the team will establish a high enough trust level that the announcements can disappear over time; this is when rotation has proven its value and your customer is no longer trying to weigh the costs vs. the benefits. Until then, be clear about your intentions and schedule.
#Conclusion
Really, rotation of team members is enormously beneficial whether you are a consulting development team or an internal shop. The major question is: how do you take advantage of it within your established practices? If your team has wanted to employ rotation for a while, but can’t find “the right time”, just mandate one. Pick a date: on Oct. 1, half the team will rotate to new projects. Constraints spur creativity. Now is the perfect time.