Recently I've been reading Alistair Cockburn's PhD thesis People and Methodologies in Software Development.  He argues that people are more important than methodology, there's no one methodology that will always be right (and there will always be new ones coming along) and that successful teams create their own methodology based on the needs of the project and the people involved.  Here are the key notes that I took while reading it.

Alistair poses three questions in his thesis:

• Will there always be new software development methodologies, or will there be a convergence at some point?
• If there is a convergence, what are the key characteristics of the methodology?  If there is no convergence, how can project teams deal with the number of methodologies
• What's the relationship between a project's methodology and the people on the project.

Here's the essence of his results:

• Yes, there will always be new development methodologies.
• The best way to deal with a large number of methodologies is to help a team understand what to consider when constructing their own methodology for each project.
• The people on a project team are a 'first order construct' and are more important than the methodology involved.  The characteristics of the team will limit any effect of a methodology.

His thesis is mainly composed of articles that he has written over the years.  Here are the summary points from these articles.

Observations on methodologies and project success
He based a lot of these findings on his own research of teams.

[When interviewing successful projects] what I find striking about these projects is that they show:

• Almost any methodology can be made to work on some project.
• Any methodology can manage to fail on some project.
• Heavy processes can be successful.
• Light processes are more often successful, and more importantly, the people on those projects credit the success to the lightness of the methodology.

And elsewhere:

I ran the seemingly odd hypothesis that if you simply put four people in a room with whiteboards and computers, give them access to the users, and have them deliver running software every month or two, they would have a high likelihood of success in delivering useful, working software. Surprisingly, this hypothesis has not yet been broken.

Methodology is irrelevant in small teams
A key concept is that one methodology can't fit all projects.  Team size is one aspect to consider:

… discussions about methodology are largely irrelevant in small-scale groups:

If the team consists of only two to three people, then the methodology as a distinct topic may be inconsequential. But as the team size grows, coordination issues become significant, and therefore more consideration must be given to the methodology.

Wayne Stevens of the IBM Consulting Group illustrated with the following anecdote:

If only a few drivers cross a large parking lot at night, when there are no other cars, it doesn't matter where they drive. The few drivers can arrange to avoid each other. As the number of cars moving through the parking lot increases, eventually it does matter. With increasing number of drivers, it becomes more important that they establish and follow conventions about parking, driving lanes, and stop signs.

How to select a methodology
When selecting a methodology, some things to keep in mind are:

• Team Size has a big impact on the methodology
  • The larger the team the larger the methodology
  • The more critical the system (the more important the lack of defects) the more important that the methodology is publicly visible.
  • Often there are two sizes that work for a project - small teams using lightweight approaches and larger teams using heavier approaches.
• The quality of the communication impacts the choice of a methodology
  • The richer the communication quality, the less need there is for bureaucracy.

People factors that contribute to a project's success
Things that impact the influence of people on a project's success:

• Communication.  The best way of communicating is face to face with a whiteboard.
• Tending to consistency.  It's important to have the discipline to keep working on a consistent way (when the natural inclination is to get sloppy over time).  This is also why high-discipline methodologies (such as XP) are considered fragile.
• Good citizenship and looking around.  Alistair's quote 'A common answer to asking why a project succeeded at all is: "A few good people stepped in and did whatever was needed to get the job done."'.  This is similar to Martin Fowler's concept of the wandering architect.
• People vary.  Methodologies need to fit the people on the team otherwise they will be rejected.

Barely sufficient methodology
Alistair looks at barely sufficient methodology.  He believe the following factors are sweet spots in these types of projects.

• Two to eight people in a room where they can communicate quickly and easily.
• Onsite customers.  The ability to get questions about the customer's requirements answered easily.
• Short increments.   Deliver a working set of software every 1 to 3 months
• Fully automated regression tests.  That give feedback as soon as possible.
• Experienced developers.  Experienced developers are much faster.

Recommendations
Every project need to develop its own custom methodology based on the characteristics of the people, the project's specific priorities and the technologies being used.  Other important criteria can include team size, geographic separation and project criticality.

It's important to have times of reflection where the team can think about how successful the methodology has been and reconsider and adjust their working conventions.