Don: They're back at it again! XP is throwing lots of quick jabbing management punches, but this time Freedom is fighting back. Looks like Freedom is rearing back for a big technical punch. Wham!..square in the jaw with a powerful chop I've never seen before. XP is reeling from that one! XP has recovered a bit and is starting to throw those quick management punches again. Howard, tell us about those XP moves while I investigate that thunderbolt Freedom just threw.

Howard: Ok, Don. It seems XP is relying on combinations of Moving People Around, Release and Iteration Planning, and even a few Fix XP When It Breaks jabs to show that it gives developers the flexibility to get the job done without rigidity of management or planning getting in the way. But Freedom is just rolling with those punches, basically accepting them, while sneering back at XP. Peter is down at ringside. Peter, can you hear what Freedom is saying?

Peter: Yes, Howard. Freedom is taunting XP, saying that XP isn't even hitting the target. He's chiding that these XP moves are all management control related and just show that XP doesn't really trust developers to get the job done without lots of management controls. Also, the fact that the XP Map, which is XP's process chart, has to be followed rigorously is more proof of management control that gets in the developer's way. Even Fix XP When It Breaks is a controlling process that has to be followed to change the process. Freedom is really waving the red flags at XP, Howard, like a matador baiting a bull.

Howard: Oops! XP responded to all that with a Pair Programming punch. Freedom just rolled with that, too. All these management jabs don't seem to be fazing Freedom on this principle. Don, what did you find out about that big Freedom punch... better tell us now because I think he's getting ready to throw it again!

Don: Here's the scoop, Howard. Freedom is relying on a nearly-forgotten jab exhibited by Parnas in a 1986 paper called A Rational Design Process: How and Why To Fake It", Parnas claimed that rational processes are impossible to follow rigorously, so do not try. Rather, developers should be free to do whatever they need in order to produce the desired work products. The only caveat is the products they produce must be the same as would have been produced had it been possible to follow the rational process rigorously. The idea is that rational processes do not exist to control people, but to more clearly define the nature of the work products expected.

Howard: Interesting! A purely technical approach to what most of us, including XP, assume is a management problem. No wonder Freedom is just shrugging off all those XP management punches. Now let me see if I understand this -- Freedom is using it's own process chart as a technical definition mechanism, not a behavior control mechanism. Does that mean developers are free to ignore the Freedom process charts?

Don: Just so long as the work products they create are the same as what following the process rigorously would have produced. Developers can perform process steps in any sequence they desire, repeat steps in order to experiment, or even invent their own steps or processes to produce the needed work products. This only applies to the Freedom technical process, though. The companion management process still has to be followed rigorously because management processes are intended to control people. But, as we already saw, Freedom is not a management methodology, so has no management processes with which to control anyone.

Howard: Wham! Freedom just plastered XP with that punch again! XP is dazed and moving into its corner. Just in time, too, because there is the bell ending round 2.

Don: Look! Now XP is petitioning the ref. Peter, what's he saying?

Peter: This is Peter at ringside. XP is saying that Freedom shouldn't be allowed to do non-standard things like apply technical semantics to process charts to solve a management problem! Almost sounds like the same sort of ploy Freedom tried in round 1.

Howard: Yeah, and it's working about as well. The ref isn't buying this one either. He's saying that since Freedom has no people control rules, it wins the "Developer trust" principle hands down. The Parnas "Fake it" philosophy clinches the case since Freedom's process charts also do not imply lack of trust in developers but, if anything, further empowers the developers. Round 2 to Freedom. We now have a tie match -- XP 1, Freedom 1.

Don: Of course, we also know that Freedom doesn't usually operate alone, Howard. Normally, there is going to be that management methodology lurking in the background constraining the developers....

Howard: True, but remember -- this is a one-on-one bout, Don. XP versus Freedom only.

Don: Right.

Howard: You know, Don, XP could also apply the Parnas "Fake It" approach to its own process charts. That would help it stand up to Freedom on this "Developer trust" principle.

Don: It's not quite that easy, Howard. Remember XP is a combination management-technical methodology. Look at the XP Map and you'll see most of the processes are management related; they deal with things like planning sessions, stand up meetings, etc. Management charts are useless if they are not followed rigorously because their only purpose is to control people. It may, in theory, be possible to apply the "Fake It" approach to the technical part of the XP Map, but XP process charts interleave technical and management tasks so tightly as to make segregating them very difficult. It would require a big revision to XP, Howard. It's highly doubtful if XP's coaches would even consider it.

Howard: Then it sounds like Freedom is going to continue to clobber XP on the "Developer trust" principle every time they meet.

Don: It would seem so, Howard.