I have spent my whole career wearing multiple hats, probably mostly because of ADD or something. I do tend to get bored if I'm not doing a wide variety of things, no matter what the reason. I've been lead developer, technical support, network engineer, database administrator, product manager, business analyst, build manager, installation developer, and probably other roles. I'm not saying this for the ego stroking, but to point out that there are real world examples of generalizing specialists, and I firmly agree that it is a good thing.
Lately I've been doing a lot of installation, build, and source control work. It fits in well with my other role of leading/mentoring, because it can be interrupted fairly easily (unlike, say, trying to figure out the subleties of fixing some problems with getting NHibernate and our crappy legacy data model to play together nicely, which is the work I probably should be doing - fortunately, there are some very talented people on the team dealing with that problem (although I do get sucked in to that, too) so I can focus on helping everyone else). Since I've been reading and exploring agile development, I've come across a lot of very good resources, which I either have shared or plan to share via this blog. We've finally hit the point where the rubber hits the road - our team has embarked on using Scrum (not very well at the moment - I thought you could just implement it little by little, and while its helping keep things on track than the chaos we used to have, it isn't giving us the full benefit it could - we're working now to correct that...). Anyway, enough mental masturbation context setting...
One really awesome resource for Scrum, beyond the usual suspects, is Henrik Kniberg. His latest article on agile version control is exceptional. I had been contemplating branching for every story, and merging the story branch back into the trunk, in order to keep the trunk releasable. It aligns with one version control practice I have read about of a branch per feature, but a story is finer grained than that definition of feature, so trying to maintain that would have been a nightmare. Henrik's method is to have a branch for each Scrum team, and then merging finished stories into the trunk, which seems like MUCH less trouble. The one complication is trying to figure out what files should be merged into the trunk. I think we can accomplish this by using StarTeam Change Requests to manage what check-ins belong to each story, and migrating change requests up to the trunk.
One other thing that will make this us do is ensure that stories are independent, and our code is properly broken into classes with a single responsibility each. Otherwise, this will still be hard to manage. But that "pain" will decrease over time, as we get better at writing GOOD user stories and GOOD object-oriented code.