While studying a software methodologies, I often see disclaimers along the lines of "This methodology requires a mature development team."
Which development methodologies are specifically geared towards immature development teams? I'd assume this is where most teams should start.
Let's define an immature team as a team whose members haven't worked together before, are working in an unknown environment (i.e. new company), and who haven't defined their processes and controls yet.
My $0.02
It is not really the case that any methodologies are specifically geared towards immature development teams per se. However if there is a characteristic of a methodology that would be beneficial for inexperienced developers it would be "well defined process".
The reason for the disclaimer ("requires a mature development team"), and this is nearly always applied to Agile methodologies, is that they require discipline and experience (which can only be gained from working on projects and learning from mistakes) to choose the right steps and make the right choices. Mature (read: experienced) developers know when it is safe (and not safe) to cut corners that inexperienced developers might do recklessly at every turn anyway. Also experienced developers have better intuitions and make better first choices, and know how to refactor designs and code properly when required.
To recast a famous quote from Bjarne Stroustrup into matching methodologies to (in)experienced teams, you might get: "Unleash an experienced team on a methodology that allows great flexibility and they might well shot themselves in the foot, unleash an inexperienced team on the same methodology and they'll probably blow their leg off". (Apologies to Bjarne, and anyone offended by the thought of leg injuries:)
It helps to have someone who is familiar with methodologies who can pick and choose what to add when. Trying to through a full blown methodology at an inexperienced team will likely overwhelm the team. Assigning someone senior to own the process would be a good idea.
I would start with version control and continuos build processes first. These will help identify if other changes break code. Automated testing tied to the build process would be a close second. Choosing what to build and when is also critical.
Throughout all of this communication about what is working and what is not should be occuring. Change what doesn't work, and continue adding.
The tough part is to produce stuff while this is happening.
If you have code to maintain, you may want to start with a small team working on new code to develop the methodology, and spread it to the team.
The methodology should drive getting the right information to the right person when it is needed. If the methodology is getting in the way of generating working code address the problem.
Reveiw the waterfall methodologies for things that need to be considered. Review the agile methodologies for how to consider things at the right time.
I can only advise you to set the environment, start working, and your team will adjust to the chosen methodologies. Create small release cycles, and adjust the chosen methodology at the beginning of every new release cycle.
Introducing code/design reviews can be a very valuable first step. It (if introduced correctly) can develop team bonding; can lead to "egoless" programming; lead to sharing of knowledge and learning; and picking up errors early in the process, when enthusiasm can lead to major pitfalls. Like @BillThor I think version control is valuable, but would suggest that teams generally need to experience the need for it before they will whole heartedly adopt it, and that this occurs only after they have had a versioning caused problem. The element that is useful for my answer, @Bill's and @Peter's is a capacity to have mentoring available. This (ideally) would be the role of a manager with development experience, or a senior developer.
