Now, the theory goes that we can do this because we're generalists. After all, we're all pretty good engineers, right? We can pick up some code, understand it, and modify it to suit our changing needs. We can make new code that fits into the system. We can all code, we can all test, we can all manipulate a database! We are that good!
Except we're really not. Despite the best efforts of Gantt-chart wizards and velocity measurers, software development doesn't have a defined set of therbligs. Instead, we are all self-selecting specialists. We each have our own way of understanding a component of our system and working with it. There are some commonalities, but we're not interchangeable yet.
However convenient it may be for managers to have interchangeable resource units (that's Gantt-speak for "humans"), let's remember that's not the goal. The goal is to produce good software. To do that I don't need individual human generalists. I need a generalist team - one full of people that are good at most things and extremely good at some things. From there it's up to the team to make sure that tasks are balanced to finish on time - whether people accomplish that by doing things they're really good at, doing things they're pretty good at, or learning new skills.
So don't ask for generalization. Ask for what you really want - software. Good software. Good software when you say you're going to have it.
* Disclaimer: I don't want to point fingers at any methodology. This generalism theory is so remarkably common that it wouldn't be fair to single out any one methodology.