Don: They are both back in the ring again. XP is still a little groggy after that "Technical excellence" drubbing he took in round 9. Freedom is leaning on his momentum and delivering the first punch, a "Definition of Requirements" swing.

Howard: That sent XP reeling, but also seemed to wake him up. XP is coming back with "Do the simplest thing that can possibly work". That punch definitely hits on the principle, but barely fazed Freedom. I don't get it. That should have really knocked Freedom for a loop, but didn't. Also, what does "Definition of Requirements" have to do with "maximizing work not done," and why is that so much more effective than XP's direct Simplicity punch?

Don: Not sure, Howard. Doesn't make much sense to me either. "Maximizing work not done" is supposed to be one of XP's strong points, yet XP is definitely taking it on the chin here, too.

Howard: Now XP has gone to his "Never Add Functionality Early" punch. He's connecting on Freedom, but Freedom seems to be just shrugging these powerful punches off. Now Freedom has come back with "Reusable Requirements" and "Reusable Classes" blows. Those, too, are having more effect on XP than visa versa. By the way, what's a reusable requirement?

Don: No doubt about it. XP is taking a beating on the "Maximizing work not done" principle. This is a big surprise. I would have thought XP would trounce any other methodology here, but Freedom is drawing all the blood. Not exactly sure what a "Reusable requirement" is, but I can understand why Freedom's "Reusable" swings are so effective. Software reuse is one of the most effective ways known of "maximizing work not done" by avoiding reinventing the wheel, so to speak. If Freedom can indeed reuse requirements as well as code, that would certainly increase the power of his Reuse punch. But the stunning effectiveness of Freedom's "Definition of Requirements" punches in "maximizing work not done" is a mystery. I can't explain it, Howard. Ouch! More gashes are opening on XP.

Howard: There's the bell ending round 10. The ref is not hesitating with his decision. Round 10 to Freedom. The score is now XP 5, Freedom 4.

Don: I see it, but I still don't understand it. Peter, do you have any insight as to what just happened down there?

Peter: I have Freedom's coach here. Coach, can you explain what we just saw? Why is Freedom's "Definition of Requirements" so effective at "maximizing work not done"?

Freedom Coach: Because the black box definition of requirements means that specifying, designing and implementing the software external interface becomes your requirements process. At some point, the external interface has to be developed, there is no way around it. By recognizing this as requirements, Freedom eliminates the work other methodologies expend on fruitless things like User Stories in the name of "requirements." Not only are these things not requirements, they are not even needed. It is entirely feasible to build software without detailing its usage scenarios, but it is impossible to build software without creating an external interface. The work savings is phenomenal. For example, XP says to create 60-100 User Stories for each Release. This takes many months, yet is totally unnecessary. In the same amount of time that XP spends writing 60-100 prose stories for one Release -- and remember "Prose is the sign of an error" in requirements -- Freedom works out the details of the software interface for the entire application with the customer, implements the code for the interface, and delivers this UI Prototype to the customer so they can verify the correctness and completeness of the interface, which remember are requirements by definition. Meanwhile, XP has yet to write a line of code, and instead has a pile of unnecessary prose. Since XP only "maximizes work not done" in the context of code, they have not yet begun to save anything, while Freedom has just saved months of development time compared to XP. In short, XP addresses the principle tactically, or "in the small" at the lines of code level, while Freedom addresses it strategically, or "in the large" at the requirements definition and process level. Freedom can additionally address the principle "in the small" as XP does, but we choose not to. Freedom believes the XP rules of "Do the simplest thing that can possibly work" and "Never Add Functionality Early" are misinterpreted by literal-minded developers so often that Freedom does not recommend these rules.

Peter: Can you clarify why you think those XP rules are misinterpreted?

Freedom Coach: I'd like to, but the next round is about to start. Maybe after the match is over and we've taken XP's crown.

Peter: Ok, coach. Thanks, and good luck! Back to you, Don.

Don: Well, there you have it. Freedom totally changes the rules for requirements via its definitions, thereby categorizing XP's User Stories as "unnecessary!" And he still thinks Freedom is going to pull this out and become the new champ, Howard.

Howard: He certainly seems confident. Two rounds to go and only one point separation. Freedom could do it, Don.

Don: After the last two rounds, It's tempting to think he just might. But look at the next Agile Principle, Howard. It's management related.