What Makes Software Teams that Work, Work?

In pulling together some notes and reviewing some papers, I was struck by a seemingly simple question, and as I consider it, I pose it here.

Some software development teams are brilliantly successful.  Some teams are spectacular failures.  Most are somewhere in between.

Leaving the question of what constitutes a success or failure aside, I wonder what it is that results in which.

Some teams have strong process models in place.  They have rigorous rules guiding every step to be taken from the initial question of "What would it take for X?" through delivery of the software product.  These teams have strong control models and specific metrics in place that could be used to demonstrate the precise progress of the development effort.

Other teams have no such models.  They may have other models, perhaps "general guidelines" might be a better phrase.  Rather than hard-line metrics and measurement criteria, they have more general ideas.

Some teams schedule regular meetings, weekly, a few days a week or sometimes daily.  Some teams take copious notes to be distributed and reviewed.  Some teams have a shared model in place to track progress and others keep no records at all.

Some of each of these teams are successful - they deliver products on time that their customers want and use, happily.

Some of each of these teams are less successful.  They have products with problems that are delivered late and are not used, or used grudgingly because they have no option.

Do the models in use make a difference or is it something else?

Why do some teams deliver products on time and others do not?

I suspect that the answer does not lie in the pat, set-piece answers but somewhere else. 

I must think on this.