Mishkin Berteig says that rotating developers in and out of a support team should never be considered. I’d argue that he’s wrong, and that it’s often highly desirable and should always be considered.

In this article:

• Background. In which I outline what this is all about.
• Support rotation is desirable. In which I explain five reasons why rotating people through a support team is actually a good thing.
• Two asides. In which I get a little upset at the tone of some of some of Mishkin’s words (but only because I know he carries weight, you understand).
• When rotation is bad. In which I try to add a bit of balance.
• Summary. In which I round things off and try to make everybody happy.

So onwards…

Background

Mishkin Berteig writes about ways of handling software support — a much under-discussed issue in the public forums. But along the way he makes a comment I’d warn anyone to beware of:

A third common method is to form two separate teams: one doing new work, one doing support work. This is simple, effective, and annoying for the people on the team doing the support work! Please don’t consider a rotation system since this destroys the process of team development and makes it nearly impossible for the team doing new work to learn their capacity for the purposes of commitment.

I’d say the opposite: in many cases a rotation system is an excellent thing, is something to be strived for, and should be considered by anyone who needs to manage software support. Here’s why. I should say I’m going to blur the line between “support” and “maintenance” most of the time, here. I think that just reflects a lot of reality — support ranges from bug-fixing to minor improvements to not-so-minor improvements.

Support rotation is desirable

Let me count the ways…

1. Rotation win: Treating developers equally

Any manager wants all their developers to feel that they’re treated fairly. If support is considered different to project work (and it’s usually thought of as being less glamorous) then you won’t want a few of them consigned to the lesser work for all eternity. And they won’t want that either. Rotation into (and out of) the support team ensures everyone knows they have no greater or lesser privileges than anyone else when it comes to sharing the workload.

This issue becomes even more acute when we bring two other groups of people into the mix: contractors and new joiners. When new members or contractors join it’s so much easier to drop them into a nice, sandboxed project. They don’t need to know about all that long term legacy stuff that’s been around for ages and needs supporting. And so it becomes less likely that the longer-serving developers will ever escape the support team. Your longest serving developers — the very people who have stuck with you through thick and thin — will become those who feel most hard-done-by. Ensuring rotation through the support team evens all that out.

2. Rotation win: Maximising your team’s experience

Software development can’t be learned just by doing either project work or support work. You learn by doing both. The best developers talk not just about creating new code, but also about maintainability, and will do so from experience. Just from a general perspective people need a breadth of experience.

But that’s important, too, even at a more specific level. It’s no good writing a piece of software and they saying adios the moment it’s launched. An application arguably only begins its life when it’s released. That’s when it starts to be really used, when it meets its users, and that’s when the lessons are to be learned.

Oh, that class really doesn’t make sense after all… That design for the whizzbat component really isn’t doing us any favours… Thank goodness we designed the look-up tables as we did, we should remember to do that again.

I’ve said to individual developers before, and I’m sure I’ll say it again, the codebase has to be in a better state after you’ve touched it than before. That skill is really best developed in a support team. A developer who doesn’t experience the full lifecycle — either in general or of a particular piece of software — isn’t learning as much as they could. Rotation through the support team ensures a broader experience and better insight into their trade.

3. Rotation win: Knowledge sharing

Fascinating that Mishkin advises against rotation “since this destroys the process of team development”. I’m not sure if he’s referring to developers’ general experience or to learning about the particular software that’s coming together in the project. If he’s talking about the former then I’ve covered that above. But if he’s talking about the latter point, then team rotation is an excellent way to ensure it.

Of course rotation can happen within a team to ensure knowledge sharing. If you do pair programming, then pair rotation promotes knowledge sharing within the team. But more than that, rotation between teams shares knowledge even more widely. If you’re going to do frequent releases then that release suddenly goes into maintenance mode and needs to be supported. If you can rotate a project team member into the support team then the support team as a whole suddenly gains knowledge of the software, they can live up to their new responsibility, and individual team members can learn from the incoming developer.

4. Rotation win: Maximising internal prospects

There’s a corollary to rotating developers from the project team into the support team throughout the life of the project. And that’s that it prevents the situation where the project team completes the project and then stays with it for life because they’re the only ones who understand it. In that situation the team as whole changes from a project team to a support team, and worse than that, they have no variety and become the support team of just a single product. By constantly refreshing the project team you ensure that developers can see that their prospects within the organisation are maximised.

5. Rotation win: Facing up to difficult issues

The issues above are mainly benefits to developers. But there’s a benefit which is solely for the manager and the business as a whole: aiming for rotation through the support team forces the manager to face up to difficult issues, whether that’s maintainability, team motivation, or knowledge sharing. Support rotation is a concrete and visible goal. By aiming for that goal you’re aiming to confront those issues, and as long as you’ve not (visibly) achieved it you’ve not dealt with the issues. Rotation through the support team provides a visible mark of success.

A couple of asides

Two things in passing. First, I think of the knowledge sharing issue almost as an extension of extreme programming. The principle in XP is, roughly, take all the good things and turn the dial up to eleven. To me, knowledge sharing is a good thing, and rotation between teams is one way to turn that dial right up.

Second — and I’m really reluctant to raise this, but think it’s important — we’ve got to be very careful about being prescriptive. The throwaway phrase warning against rotation (“Please don’t consider a rotation system since this destroys the process of team development and makes it nearly impossible for the team doing new work to learn their capacity for the purposes of commitment”) has too many bad echoes for me of the “you call this agile?” ding-dong.

You may recall that also began with a remark posted on the Agile Advice blog. There, the author seemed to categorically refuse any interruptions to his developers’ week on the grounds that two hours’ interruption can waste the entire week. Joel O’Software countered this, suggesting that maybe, just maybe, an interruption might be okay. There were arguments both ways [1, 2, 3, etc]. In both cases — on rotation and interruptions — the impression is created that developers are revered saints who need near-religious attendance or they’ll fall to pieces. The best developers I know have their feet planted firmly on the ground, and the best businesses I know treat developers with respect not because they’re developers, but because everyone there treats everyone else with respect. It’s very rarely black-and-white when methodologies meet reality. We need to be pragmatic, not dogmatic, and we need to be seen as such.

Thank you for indulging me. Now back to our regular programming…

When rotation is bad

Yes, yes, one mustn’t be dogmatic. Rotation in and out of the support team won’t always work…

Caution: It’s disruptive

Rotation is disruptive, for exactly the reasons that Mishkin gives, so it’s got to be balanced against everything else that’s going on in the business. Rotating a developer every day is clearly going to be a bit much. But rotation can be planned to minimise disruption. The point when one iteration stops and the next starts is obviously a good opportunity. Maybe not between every iteration, but at appropriate project milestones, when people return from holiday, and so on.

Caution: It depends what “support” means

In all the above I’ve really thought of “support” as being almost synonymous with “development on a very small scale”. But it’s not always like that. In many cases software support involves telephone support, or perhaps meeting paying customers. Clearly this requires a very different (interpersonal) skillset than you’d look for otherwise in a software developer. Many developers don’t want to spend time meeting besuited customers, and in these cases you’ll end up hiring different kinds of people for different kinds of teams. Clearly here rotation isn’t going to work.

On the other hand I should say I know a few developers who do like meeting customers, and who do like solving problems on the phone. And I also know developers who like maintenance work without meeting customers because it gives them a strong sense of satisfaction to see a closed problem solved in a timespan that’s a fraction of most projects.

Caution: If you’ve already committed

There’s also one final occasion when support rotation is difficult, and that’s when you’ve promised people otherwise. Perhaps you’ve undertaken to a new recruit that “no, we won’t put you on support”. Or perhaps you’ve promised a particular client that certain individuals will stay on their project to the end. In these cases, obviously, you’ve got to honour your word.

Summary

Support is a very, very under-discussed topic, particularly in the field of Agile development where the writing tends to be about projects rather than maintenance. So Mishkin Berteig has done us all a great service by spending some time on it, and offering suggestions about how it might be managed. But there are probably more ways than even he suspects, and in particular — and against his advice — I would very strongly recommend giving serious consideration to rotating developers in and out of a support team.

It’s not easy to manage, and there reasons not to do it. But there are also plenty of very good reasons that it should be done, and hopefully the words above will encourage its wider adoption.