Setup a SVN Repository, and Bug Tracking systems. If those two developers haven't done that yet, step 1 should be to fire them and hire real developers. I think I'd need to know more about your specific situation to help. Ultimately your success will depend on two key principles: 1) having quality developers in the team 2) giving them the right structure (including plenty of space) to work effectively From the sound…
Daniel, Thank you very much for your reply. I got some great pointers from your article, and I look forward to chatting with the developers and casually bringing up some of the points you mention. I'm interested in your proposition - if they don't have an SVN repo and bug tracking systems they're not real developers. Are there any other very clear indicators that these aren't the guys you want on your team? Co-incide…
My first question really WOULD be why are thye not using SVN. It could be they are: or perhaps using Git, Mercurial etc. (I would personally go with mercurial over anything else on a smaller team).
Or it could be that as they work in an office together they have different methods of source control between themselves.
Your first job is obviously to get some proper offsite SCM (I always recommend offsite for a small startup - that way you have a few guarantees. BitBucket (mercurial) give you one free private (hidden) repository [1] and GitHub (git) have fairly cheap plans for private repos [2]. Both of these integrate with most of the popular ticket / project management sites with little work.
Swombat is right: if they dont have any kind of control going on with their code then your looking at some bad programmers. But I would say SCM discipline is easy enough to learn: so dont automatically give up on them. Find out what their preference is (if any) and work with them on a good workflow plan for how to get the code into SCM and how to checkout and develop it from there on a day ot day basis (a common problem we have here with SCM noobs is that they tend to forget to check in at the end of the day, for example, or at lunch. Eventually leading to all manner of pain!). As it's a small office it should be easy to manage though :)
[1] http://bitbucket.org/plans/
EDIT: as an addendum I would personally ignore all the comments about adopting Agile development practices (especially things like Scrum which was specifically mentioned).
The major reason is that they simply do not work as well for you as they do for the people that "invented" the practice. Strict guidelines never work if you just implement them. Agile tends to be for teams that want to sound trendy and hip ;) it's faster just to develop your own process naturally.
Also if you leap into the office with all these new "agile" ideas you'll just be considered "management type" and probably not be greeted well by the existing team. You obviously need to bring in stuff but in as relaxed a way as possible is probably best. As it is a small team it wont take long to have a few meetings to decide the way forward - and with so few members there is not likely to be long drawn out discussions.
If you go in with some sensible stuff like SCM and workflow ideas and ask what they think of them you'l get a good response I'll bet.
Oh - and outline your role to them as clearly as possible. They might, for example, think your beign brought in to assess them and get rid of them (which in a way might be true - but best not to say that :D) rather than to manage the product so they can get on and code.
Hope that helps.