Distributed Version Control and Agile Development

Traditional VCS are always about a centralized (slow?) server where every one in the team has to sync their work. For a number of reasons, this does not fit well with the dynamic, feature based nature of the agile development processes.
In an agile process you want small teams to be able to develop their features independently without breaking other teams work. Unfortunately, we all know how someone makes a change that breaks the build for everyone else (personally I try to sync as little as I can so I won't be affected by other people - not to say its a good solution).

It seems that distributed version control (DVCS) is better suited for the needs of agile teams.
A DVCS does not require a centralized server (but you will most likely have one - to hold the ultimate truth about your project). Instead, in a DVCS environment, each developer has their own private branch on their local machine.

When I'm part of a feature team I can push my changes to my buddies and can pull their changes. This way we collaborate in a peer-to-peer fashion without affecting other teams. I also argue that in such a way we're more aware of what other people are doing because we're actually aware of the changes other people do and we can review them.

When we're ready we can check in our finished feature to the centralized (possibly legacy, SVN, Perforce, Starteam, ...) repository.

Such systems already exist but don't expect a rich UI - for instance Mercurial is popular in the open source community

For a (not so long) introduction to DVCS read this: http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/

And a (longer) google talk: http://video.google.com/videoplay?docid=-7724296011317502612