martin fowler

The Agile Alliance is nothing more than a web site ( http://agilealliance.org/ ), a manifesto, and the personal relationships behind it. We don't expect any unified agile whatsit - because we actually think there should be many different processes for different kinds of problems.
If you're interested in XP in the Netherlands, I'd post a question to http://groups.yahoo.com/group/extremeprogramming/

------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

Open Source and XP are clearly different processes. However there is much about open source that is agile - which is why I included it in http://martinfowler.com/articles/newMethodology.html
Of course many of the XP practices can be used in open source projects. I would certainly use Continuous Integration, the testing, the refactoring....
------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

Random manual tests are a useful adjunct, but the core technique is a repeatable automated test. If you find a bug with a random manual test your first act should be to write an automated test that exposes the bug
------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

And I forgot. One of the best written documents of requirements is the acceptance tests. They are detailed, accurate, and can easily be verified.

Dont we need to be able to get all the user stories ( across release plans) together when needed? Don't index cards get misplaced? I mean, dont we need to organise the cards in [I]some[I] way?

Different projects do it different ways. Some transcribe into a spreadsheet. C3 kept the cards on the customer's desk with rubber bands to group them into iterations.

When you are ISO/SEI certified, you need to keep a record of all the project documentation and requirements doc is an important one. If these index cards ( the only carriers of the reqs) are not part of the project documentation, then what goes to the audits as a req spec?

If that's the case then you'll have to create some additional documents to satisfy the ISO folks. XP travels light and tries to eliminate unnecessary documents. If the only reason you use a document is to satisfy an auditor, that's counts as unneccessary in my book!

------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

There's definitely a change for many PMs. If the PM wants to control what everyone does, that doesn't fit with XP. XP works with a PM who is interested with keeping things running smoothly and takes the attitude that they are a peer with the rest of the group. Some people do have a problem with that. Others find it liberating.

------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

Flexi-time (which we enjoy) is pretty much incompatible with XP.

Not really. Most people that do flexi time have a sizeable overlap when others are around. And there's usually non-programming work that's okay to do solo. XP is something you adapt to a team. I don't think most XP teams would have trouble adpating to the kind of flex schedule you describe.

Working from home is a no-no.

Yes, this is much more of an issue. Not just does it get in the way of pairing, it also gets in the way of the "all in a room" nature of XP communication.

Developers with external (non-work) responcibilties (familly, life etc) stand out like sore thumbs if they stick to a 40 hour week when other team members stay late every night.

I would think XP would be better than this. Since XP is strongly against long hours - that would be better for people with a life.

------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

I would inclined to a little up front design here. Bear the following in mind.
Err on the side of simplicity.
Build little prototypes to see how things work in practice
Expect your architecture to evolve as the system evolves
Don't put in complex mechanisms that you aren't going to use in the early iterations. If you need them add them later

1&2) Certainly it's most effective to go whole hog to XP, but for most people that change is too hard. So they go gradually. Continuous Integration and Testing are good ones to start with, as is the planning process. I have no idea how to quantify the ramp up curve, but you can get paybeck from these things pretty quickly.
3)I don't reccomend using XP with more than a dozen developers, nor with a distributed team. Many of the practices are still useful, but the whole package is designed for a co-located team of up to a dozen in size.
4)I do my best, but I'm just a geek :-)
For more on this you might want to look at the XP mailing list: http://groups.yahoo.com/group/extremeprogramming/

------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

I've often said that Pair Programming would be stupid if the hardest part of programming is typing....

I'm not sure that it works well to post risks in terms of days to fix - many of the tougher risks are almost impossible to quantify that way. I like the idea of the top ten risks list (see McConnel's Rapid Development) - choose your biggest risks and rank them. Make sure you revisit the list weekly.
However it sounds like your problem is more about tasks than risks. In which case you need to estimate how long it should take to finish each task, figure out how much time you've got left, and if they don't add up figure out what needs to be deferred.
------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

Originally posted by Michael Mendelson:
Well Martin (or anyone), what about small projects? The client I mentioned in my initial post is a small organization, and I am a solo consultant, working with another developer (in yet another location).
I am not interested in implementing ALL of XP, but would like to explore SOME of its techniques which can assist my development process.
For example, how would you implement User Stories in my situation?

I would certainly use stories in your situation. Have a session with your customer asking them about the things they want the system to do. Write each wish on an index card. Spend an hour or so coming up with estimates for each card. Decide your iteration length and velocity. The units of estimation don't matter as long as they are consistent with your velocity. Come back to the customer and say something like "we can do 6 gummi bears worth of work each week. I've taken each of your wishes and estimated how many gummi bears each one is. Please arrange the cards into weeks for me so I can prioritize my work. That's your release plan. For more details see my book :-) (Or indeed poke around the various XP sites like http://www.xprogramming.com

Actually it isn't the remoteness that's the problem. The problem is that you haven't got somebody who is only concerned about business value and who isn't concerned about how you do it. You would get a better simulation if someone just said "I'll be the customer, I'll set priorities but I won't get involved in design discussions or in evaluations". At the moment Junilu is doing both, and that's what's making the simulation tricky.
The original Object Mentor article has the same problem.

------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

XP tells you to build your system in the best designed way you possibly can for your current set of functionality. Do not put in any design hooks that you aren't using now but expect to use next iteration. The rallying cry is YAGNI (You Aren't Going to Need It).
The rationale is that making the change is much easier with Continuous Integration, Testing, and Refactoring in place, the requirements will likely change by then, and you will learn more and the design you imagine now won't be the right design when you actually do it. I talk about this much more in http://martinfowler.com/articles/designDead.html
------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming

I guess it would be tricky to listen on your own :-)
All parts of XP are collaborative, but there's special emphasis on programming because it's so new to many people to do that in a collaborative way.
------------------
author of:
Refactoring : Improving the Design of Existing Code
UML Distilled, Second Edition: A Brief Guide to the Standard Object Modeling Language
Analysis Patterns : Reusable Object Models
Planning Extreme Programming