Agile Methodologies on Large Projects
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
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.