Don: Hey, look! Freedom's coach is talking to the ref. We'll switch to ringside and see if Peter can tell us what's going on. Peter...?

Peter: That's right, Freedom's coach is in conference with the ref. Looks like a pretty heated discussion... Now the conference is over, and Freedom's coach doesn't appear to be very happy. Coach! coach! Can you tell us what you were just talking to the ref about?

Freedom Coach: Yeah. This 4th agile principle is flawed. Everyone wants the best architectures, requirements, and designs, but self- organizing teams by themselves are insufficient to produce them. Those teams also need clear technical guidance on what constitutes good architectures, good requirements, and good designs. Without that guidance, or with poor technical guidance, the best teams in the world will just produce crap. Heck, today XP and his followers don't even know what a requirement is! How can they, or anyone, be expected to produce the "best" requirements if the methodology doesn't give them a decent clue as to what requirements are?! I was asking the ref to change the principle to read

    The best architectures, requirements, and designs
    emerge from rationally-defined products developed
    by self-organizing teams.

Even acknowledging that self-organizing teams might be useful, giving the teams clear, rational technical guidance on what to produce has to come first. Principle 4 doesn't say anything about that. It's an incomplete principle, flawed.

Peter: You lost me coach. Sure XP tells developers what to produce. For requirements, XP has User Stories, about 3 sentences that describe a customer need in enough detail to cost and plan it. And User Stories are not limited to describing the user interface, either.

Freedom Coach: That's a great example of my point, for three reasons. First, it is highly unlikely that one can plan anything accurately based on three sentences! Second, the Parnas information-hiding team stated that "Prose is the sign of an error" in a requirements document, so XP's use of sentences is fundamentally erroneous. Everyone knows that prose is ambiguous, prone to incompleteness, and unverifiable. Third, and most important of all, requirements are "the black box view of the software system," by definition. Harlan Mills' work clearly indicates this. What is a "black box view?" Mills proposed that a black box view consists of the stimulus-response behavior of the software. Also, the external interface that detects the stimuli and returns the responses is part of the black box view. That's the sole extent of a black box view, which is synonymous with requirements. To blither on about anything else under the auspices of requirements just shows XP provides poor technical guidance, which in turn leads to substandard, if not totally erroneous, work products. There is no way the "Self-organizing teams" principle is going to fix that and somehow create the "best" requirements if the technical foundation is defective.

Peter: Wow! That's pretty heavy stuff coach. What did the ref say?

Freedom Coach: He said that even if that's all true, he is powerless to change the Agile Principles. The wimp! Excuse me, the round is about to start.

Don: Thanks for that report, Peter. Yes, the contenders are moving back into the ring. XP is swinging with "Move people around". Freedom is throwing the Parnas "Fake it" thrust again. Are either of those the same as "Self-organizing teams"? Both opponents look pretty weak this time.

Howard: Could be a problem for both of them, Don. Now XP is dancing around with the "Fix XP When It Breaks" dodge.

Don: Freedom keeps going into a stance like he wants to flatten XP with a "Definition of requirements" blow, but the coach must have gotten word to him that it won't do any good with the principle worded the way it is. It would just be hitting below the belt.

Howard: Right, Don. If the principle were changed to read the way the Freedom coach suggested, Freedom's "Definition" punches could be devastating. But with the principle stating that only self-organizing teams create the best work products, Freedom's technical prowess doesn't count. It's pretty clear now why Freedom's coach conferred with the ref.

Don: Both sides are lunging and dodging, but no one is connecting.

Howard: XP doesn't seem to give the developers independent control over their organization. XP is pretty tightly managed.

Don: And Freedom doesn't address management issues at all. The "Fake it" punches are not landing home as they hit on process initiative rather than team organization.

Howard: There's the bell ending round 4.

Don: Wonder who the ref will say won this one? Pretty poor showing for both sides.

Howard: Here's the call -- a draw! No winner on principle 4!! The score is still XP 2, Freedom 1.

Don: I think the ref called that one right, Howard. Neither supports self-organizing teams well, but for the opposite reasons. XP is overly management driven, and Freedom not enough.

Howard: Right, Don. But if the principle were ever restated to emphasize the real goal of high quality architectures, requirements, and designs rather than an assumption about how best to attain them, then Freedom would probably knock XP flat on this principle.

Don: If wishes were horses, Howard.