Adding something new and interesting to software's CategoryMethodology takes a lot of effort and experience with a wide variety of projects, many of them at least somewhat resembling yours.   Projects which just roll their own software development methodology rarely prosper, though succeeding guarantees fame!  (See ExtremeProgramming for a recent example.)
-- MarkSwanson

''Yeah, right, XP rolled their own after 60 or 90 years of combined experience.''
-----
My experience is the opposite, that successful projects roll their own methodology to suit their team and project.  My experience is interviews with several dozen OO projects, about half successful, and half failed.  May I ask where your assertion stems from?  -- AlistairCockburn
----
Every team is responsible for choosing its culture. You can copy a successful culture, blindly inherit the culture of the previous incarnation of the team, or create a new one from scratch. Each approach has advantages and disadvantages. But the team, and every member on it, is still responsible for the outcome.
----
At the WOOD conference, SteveCook (IBM UK) told us that their practice is to have a large menu of methodology components. Each project picks the items they want to apply in their particular project.  He said it works pretty well.  --RonJeffries
----
"Methodology components" - sounds like patterns in a pattern collection. You just pick the ones that apply to your context, and you've rolled your own methodology. Is that what they're doing?
-- YonatSharon
-------
I surrender!  All of the above qualify as "rolling your own" and are obviously successful strategies.  What does not work, yet is an all too frequent approach, is to decide you'll ''do your own'' but not really do the intellectual work required to create and then actually perform a complete enough methodology.  My, possibly low end, experience (with admittedly only a dozen or so projects) is that this is the most likely result of deciding to roll your own in most organizations.  --MarkSwanson
----
Easy surrender, how dissatisfying. Seriously, the point I was making was that you always "roll your own" in the sense that you choose, consciously or unconsciously, your own culture. You can't get away from this.

The point I heard you make was that people choose in the wrong way or for the wrong reasons, rejecting things that might help and accepting things that hurt. I absolutely agree with this. The solution, however, certainly isn't to just follow what some book says. That doesn't really solve the problem, it just masks it with a layer of slavish checklisting. When the project goes down, the methodology gets blamed (or the technology), and the team is no closer to addressing their own barriers than before. --KentBeck
-----
Two relatively new papers on my web site: 
Just In Time Methodology Construction (http://alistair.cockburn.us/crystal/articles/jmc/justintimemethodologyconstruction.html)
and Balancing Lightness With Sufficiency
(http://alistair.cockburn.us/crystal/articles/blws/balancinglightnesswithsufficiency.html)
are about rolling your own methodology.  Best I know how to say just yet. --AlistairCockburn
----
On CrystalClearMethodology, Alistair wrote:
''The difference between CrystalClearMethodology and ExtremeProgramming is that XP is much more disciplined, CrystalClearMethodology is much more tolerant, even sloppy-looking. I would say XP is more productive, CrystalClearMethodology more likely to get followed.''

I think that almost all formalised methodologies, XP included, have so many rules that it's not likely they will get followed, even if the team agrees that they are following it. Teams choose parts to leave out or place less emphasis on, which results in a roll-your-own anyway, whether you acknowledge it or not.
I think the future of methodologies is those like XP and CrystalClearMethodology which recognise how people work, and document best practice. 
The WaterfallModel is something that HenryFord invented, and was never really going to work for software anyway.
See also MethodologyCargoCult.

JohnFarrell
----
Seemed to me, that these ideas are close to what people in MethodEngineering have done - don't know too much about it (yet) myself, but put some pointers there.

ToniAlatalo