There has been some discussion recently on the Australian "dotnet" Mailing
List about the applicability of XP and agile development to large scale
projects.
Nick Randolf questioned someone's comment that "most of the practices won't work in large, dispersed
projects". He asked for good reasons why they would not?
I wrote in response ...
I like Barry Boehm's critical
agility discriminators:-
Size : Criticality : Dynamism :
Personnel : Culture
Size: Well-matched to small products and teams.
Reliance on tacit knowledge limits
scalability.
Criticality: Untested on safety-critical
products. Potential difficulties with simple design and lack of
documentation.
Dynamism: Simple design and continuous
refactoring are excellent for highly dynamic environments, but a source of
potentially expensive rework for highly stable
environments.
Personnel: Requires continuous presence of a
critical mass of scarce Cockburn Level 2 or 3 experts. Risky to use
non-agile Level 1B people.
Culture: Thrives in a culture where
people feel comfortable and empowered by having many degrees of freedom -
thriving on chaos.
It's now widely accepted that XP practices "must be adapted as
necessary for projects that do not fit the "small team" limits recommended by
its founders." (http://www.thoughtworks.com/bad-smells-in-xp.pdf)
Here
in Australia, efforts to implement XP as a corporate methodology or in large
projects - tend to go the way of Citect (citect.com.au). A "guru"
will preach "values" over "process", which rapidly go out the window as
processes that manage risk and offer predictability to customers and
stakeholders are re-introduced.
I think that's why there is movement away
from XP in projects unsuited to it's sweet spot, to say SCRUM, or one of the
large team variants of Crystal.