Specialization In Xp

We've been misunderstood (if you want to pause for a moment to cry for us, we'll understand.) There, you're back now.

One of the common practices we fight against in XP is the rigid division of labor so beloved of Taylor and the Scientific Managers (see "Taylor and Software" for more detail). The exalted Architect, the distinguished Pattern Miner, the aethereal User Interaction Specialist, the lowly Tester, the grunt Coder - these job titles have no place on an XP project.

Somehow when we say this, people seem to hear something very different that what we meant to say:

"Every programmer has to know every line of code in the whole system." The pairs swap around quite a bit, it's true. Programmers will find themselves encountering most all of the system in the course of the average month. However, that is far from saying that every programmer has to be intimately familiar with every line of code. That would be impossible, and we don't ask the impossible, just the improbable.
"There's no place for specialists." The rule is simple. During IterationPlanning any programmer can sign up for any task. "Can," not "must." Out of this simple rule, which you don't have to do anything to enforce, comes behavior that looks suspiciously like specialization. Some people will tend to work mostly in the plumbing. Others will tend to accept tasks that require specialized domain knowledge. But if someone is bored or curious, they are welcome to sign up for a task that will stretch them. When the time comes to implement the task, they will find an experienced partner. If they simply aren't suited to that kind of work, they will miss their estimates badly, you'll have one iteration that might be a bit of a mess (if you don't catch it soon enough), and they won't do that again.
"Everybody has to be the same." A team of identical people is headed for disaster. They won't spot trouble because they are all looking in the same direction. In diversity is strength, if you can avoid bloodstains. A team that works closely together will align their opinions and behavior on some things, it is true. You have to write tests. You have to integrate often. You have to refactor. Pizza toppings, however, remain a matter of individual preference (along with a few other topics).

So, we didn't say those things above, and if we did say them we were drinking, and if we weren't drinking we were confused, and if we weren't drinking or confused - we're always either drinking or confused.

Our attitude toward specialization is that it works great from unloading railroad cars full of coal with shovels, or producing lots of identical cars quickly. However, when you are working in a novelty-soaked, communication-intense industry such as ours, the temporary productivity gains of Taylorist divide-and-conquer are quickly overwhelmed by the additional risk and cost of integrating ideas. Every time you grant someone a license to start something they don't have to finish, there is a huge gap between them and the poor bastard downhill. Don't do that.

From this perspective perhaps it is fair to say that everybody does have to be the same. Everyone has matched authority and responsibility. If you are responsible for doing something, you have the authority to say how long you think it will take. --KentBeck and MartinFowler [deleted from a forthcoming XpProjectManagementBook?]

Let's see if I've got this.

The most pernicious aspect of specialization in traditional projects is the division of status that usually goes with it?

There are two risks associated with specialization: too little and people end up with jobs they can't do, XP manages this with PairProgramming and short iterations. Too much, and people lose touch with the larger project and your TruckNumber gets worse. Once again, PairProgramming and, as RonJeffries writes in CodeStewardship, "Actually in XP we discourage people gravitating [towards an area of expertise]. We recommend switching people around so that you don't get the ego involvement and you do get cross-training." So, sometimes you have to nudge people to stop them settling into local minima. ProjectSimulatedAnnealing??

moved from PlanningGame

How do you do the PlanningGame when your people have very different skill sets? For example, we have some coders who know only HTML/ASP, and some who know only C++. We're trying hard to stick to the PlanningGame, but we often find ourselves with a commitment that doesn't have enough stories that require HTML/ASP work, or one that doesn't require enough C++ work. I know PairProgramming is supposed to fix this, but do you really expect an HTML/ASP coder to learn C++ by pairing? I've thought about dividing it into two completely different commitment schedules, but the trouble is that almost all of our stories require both HTML/ASP and C++ work. --RayPingree

Are you saying that at some point either the HTML/ASP or C++ people will have nothing to do? If they are required to work together, it seems to make sense that they plan together. Someone signs up for a particular story and is responsible for hunting down a HTML/ASP or C++ coder(s) as necessary to fulfill the tasks. I'm not sure if there's anything more to this. --JasonYip

The real problem with people not having enough to do is justifying this process to upper management. Of course they want everyone to have something to do. Anyone writing paychecks would. Maybe the real problem is that we haven't yet planned more than one commitment at a time. If we knew what was going to be in the next commitment already, people could go ahead and start on that. But then that throws off the LoadFactor calculations at the end of that next iteration, because people would have been working on things before the beginning of that iteration... Don't you see how it's all unraveling? --RayPingree

I'm not so sure it unravels Ray. If a team member's role is reduced from one iteration to the next, you simply reduce his weight in the LoadFactor. If RayPingree was a full time ASP coder for I1 but spent 50% of his time on another project for I2, he is considered a one-half coder for the second I2 and the load factor is still an accurate representation of the velocity of the team. Few projects start, end, and maintain the same number of developers for the life cycle of the project. Does that sound reasonable to everyone?

Let me try to answer my own question... I don't see a way to involve resource usage in the PlanningGame unless you do it at the estimating level. So we estimate the ideal days of C++ time and the ideal days of HTML/ASP time for each story separately. We can't commit to a story until it has both kinds of estimates. Either estimate can be zero to indicate that it doesn't require that type of work. Then in planning we have a certain number of HTML/ASP ideal days in each iteration and a certain number of C++ ideal days, because we have a certain number of C++ coders and a certain number of HTML/ASP coders, and we have separate load factors for the two groups. It's still possible to get a commitment where people have nothing to do, but at least you can see it happening as you build your commitment. --RayPingree

The main thing to learn here is something about choosing an architecture that requires specialized programmers: it leads to inefficiency. Given that for some reason you like inefficiency, probably the best thing is to estimate against several dimensions of resource, as you suggest, so that cards show "3 C++" and/or "3 HTML", and compute velocity independently as well. Then presumably the customer can bring in the right amount of each. But doctor, it hurts when I do this ... --RonJeffries

A.) This is a serious barrier to adopting XP, because if it's going to happen at a company it'll happen on the first XP project they undertake, and it makes management distrust the process. B.) It's very unlikely that someone learning about XP by reading would forsee this problem. It's like how sand dunes line up either against or along with the average wind direction, depending how variable the wind is. It's a consistent rule about how the system behaves that you can't learn by studying the parts. C.) Knowing about the problem may allow you to work around it, as long as you know before your achitectural spike. --RayPingree

Boy am I glad all the commotion is about PairProgramming and OnsiteCustomer. It distracts management from thinking too hard about the PlanningGame and dismissing it out-of-hand.