I've got long standing developers in my sprint team. They know the domain, they've been with the company 5+ years and as a team we have a pretty good burn down rate.
There are other sprint teams, some with equally knowledgeable developers and others with newer developers who are trying to get up to speed.
My manager is worried that all our eggs are in one basket and wants to rotate out one or two knowledgeable developers in exchange for the some new guys. I can see their point but can also see the problems that go with that – I'm sure there are others but these are just a few off the top of my head.
- New developer will have a much lower work rate
- New developer will bring down the work rate of at least one experienced person as they constantly ask questions.
- New developer leaves the team at the end to join another team – hopefully he'll remember what he did with us.
- New developer leaves the company – wow we wasted a whole bunch of time.
I might like to add that the organisation is struggling with agile. It was a traditional waterfall development company and still thinks in big releases and items that are "expected" to be in the release.
If you've been in a similar situation to this I'd love to know you experiences – does rotating out the team members work? Would pair programming or other methods be a better route to take?
Best Answer
One possibility: If you are concerned about loss of productivity by rotating a team member, your manager has the correct approach, and will most likely be seriously concerned (if he's any good), but not saying so.
As companies grow, they become less concerned about immediate productivity and more concerned about continuity and predictability. Issues such as business continuity, key person dependency and technical vitality come into play - the same people working closely together for many years, with no one coming or going almost always ends badly, think the red buss... or more commonly, BBoM (Big Bucket of Money) inflicting multiple casulties on the team.
High throughput at all costs is critical to survival of startups but there is a cost in both technical and non-technical debt. Consistant, repeatable, predicitible processes is more critical to established companies than pure speed. (Think tortoise and hare)
Long term, low turn over, siloed teams are a very real problem for management of larger companies. Are you transtioning from a small company to a big company - or more subtly. from a 'big small' company to a 'small big' company?
If this really is the situation, you need to decide if you really want to be seen to be resisting the changes.