Round 1, Businessman-developer cooperation. XP's Stand Up Meetings cannot be countered by Freedom. Round to XP.

Round 2, Developer trust. Freedom's "Fake It" principle shows more relevance than XP's Move People Around, Release and Iteration Planning, or Pair Programming. Round to Freedom.

Round 3, Sustainable development. XP's No Overtime and Iteration Planning cannot be countered by Freedom. Round to XP.

Round 4, Self-organizing teams, is not addressed well by either methodology. Tie round; no winner.

Round 5, Team tuning, is more directly addressed by XP's Move People Around and Fix XP When It Breaks than by Freedom's Metric Checklists and Separation of Technical and Management Methodology Concerns. Round to XP.

Round 6, Frequent releases, is better addressed by XP's Iteration Planning and Frequent Small Releases than by Freedom's Requirements Prioritization. Round to XP.

Round 7, Early and continuous delivery, is better handled by Freedom's Requirements Prioritization and UI prototyping than by XP's Iteration Planning and Frequent Small Releases. Round to Freedom.

Round 8, Software progress, is more directly addressed by XP's Project Velocity than by Freedom's Metric Checklists. Round to XP.

Round 9, Technical excellence, is addressed by many artifacts of both methodologies including Freedom's Object Model Tables, Abstract Interface Specs, Partial Functional Simulations, Canonical Design Architecture, Coding Style Guide, Software Decision Encapsulation, Hardware Interface Encapsulation, Definition of Design, Definition of Implementation, and Quality Requirements and XP's CRC Cards, Spike Solutions, Coding Standards, Refactor Mercilessly, and System Metaphor. However, Quality Requirements gives a decisive edge to Freedom. Round to Freedom.

Round 10, Maximizing work not done, is better addressed by Freedom's Definition of Requirements, Reusable Requirements, and Reusable Classes than by XP's Do the Simplest Thing That Will Work and Add No Functionality Early. Round to Freedom.

Round 11, Face-to-face conversation, is better handled by XP's Customer Is Always Available, Pair Programming, and Stand Up Meetings than by Freedom's Customer POC and Pair Requirements. Round to XP.

Round 12, Changing requirements, is far better met by Freedom's Definition of Requirements, Requirements Prioritization, and Requirements Encapsulation than by XP's User Stories and Release Planning. Round and match to Freedom.

Don: Thanks, Howard. The per principle score for each side is shown in the table on your screen.

                          Per Principle Score

       Agile Principle                Type        Winner  
    ----------------------------  ------ -------  -------
   1 Businessman-developer cooper mgmt            XP
   2 Developer trust              mgmt            Freedom
   3 Sustainable development      mgmt            XP
   4 Self-organizing teams        mgmt            tie     
   5 Team tuning                  mgmt            XP
   6 Frequent releases                   tech     XP      
   7 Early, continuous delivery          tech     Freedom 
   8 Software progress            mgmt            XP      
   9 Technical excellence                tech     Freedom
  10 Maximizing work not done            tech     Freedom
  11 Face-to-face conversation    mgmt            XP      
  12 Changing requirements               tech     Freedom
                                  ----   ---- 
                           Total    7  +  5  = 12

                              XP    5  +  1  =  6
                                  (71%) (14%) (50%)

                         Freedom    1  +  4  =  5
                                  (20%) (80%) (42%)


    Freedom Homepage: http://www.jreality.com/freedom/
    XP Homepage:  http://www.extremeprogramming.org/

Howard: Good summary, Don, except you forgot about those Agile Principle changes that Freedom recommended. How many were there?

Don: Right, Howard. Freedom went on record recommending changes to four of the 12 Agile Principles.

Howard: Can you summarize those for us?

Don: Sure, Howard. Freedom suggests Principle 4 be changed from

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

Freedom recommends Principle 6

    Deliver working software frequently, from a
    couple of weeks to a couple of months, with a
    preference to the shorter time scale.

be changed to address "actual customer release needs" rather than "frequent" releases.

They suggested Principle 8 be changed from

    Working software is the primary measure of progress.
to
    Working software, with accompanying customer-approved
    requirements, designs, tests, and user documentation,
    is the primary measure of progress.

Finally, Freedom recommends that Principle 11

    The most efficient and effective method of
    conveying information to and within a development
    team is face-to-face conversation.

be dropped because face-to-face conversation is not always best, so the Principle is "just plain false."

Howard: Thanks, Don. That's it, sports fans. Thanks for joining Peter, Howard and Don, the PHD team, for the First Agile Slugout.