It all sounds good, but I would be careful about planning.
As a manager coming in from the outside, you're going to want long-range plans. What we've found is that coders are notoriously unable (along with the rest of us) to predict on a long-term basis.
That doesn't mean don't plan months and years out, but it means as far as commitment, have your programmers commit to little chunks of work at a time. Put together a big list of stuff that needs doing (but not too big, maybe 50-100 items max), then pick a time frame, like every two weeks. For each time frame, ask your programmers to commit to doing whatever they think they can from the list. At the end of the time frame, have them demo what they've done -- and fight the urge to micro-manage in the middle.
By having fixed timeboxes, a prioritized list of stuff, and giving control over commitment to the team, you can have lots of little wins over time, which is a great morale booster and also helps you spot problems much earlier than with a long-range plan.
Very interesting perspective - I've tended to work with people by doing big picture proposals with a list of deliverables, but this kind of bite-size requirements could be a great way to get a feel for the team.
This could even become my standard way of working with coders.
Look at the Wikipedia article for Scrum (development). It outlines this approach reasonably well, and is "easy" to implement (e.g. the developers will not reject this as "over process") Be agressive in terms of commitments (making and missing) and hold to the fixed timebox. I -highly- recommend a 1 or 2 week timebox (-not- 30 days) as it forces more decomposition and only has people commiting to what they really know. Do the demos. Focus on vertical slices of functionality (e.g. don't just build the breadth of the UI component, take a single button and get it working down to the DB (for example))
-force- the developers to use a CM system and as part of the retrospectives, review checkins/branching, etc. This can evaporate after you are convinced that they are using a CM system (a month or two?)
ask about unit tests (even if you know little about software) if you sense BS, then you have a real problem. If they are developing UT's as you go. This is a good sign. Your hired tester should be able to review unit test coverage breadth with you (plural).
hth
As a manager coming in from the outside, you're going to want long-range plans. What we've found is that coders are notoriously unable (along with the rest of us) to predict on a long-term basis.
That doesn't mean don't plan months and years out, but it means as far as commitment, have your programmers commit to little chunks of work at a time. Put together a big list of stuff that needs doing (but not too big, maybe 50-100 items max), then pick a time frame, like every two weeks. For each time frame, ask your programmers to commit to doing whatever they think they can from the list. At the end of the time frame, have them demo what they've done -- and fight the urge to micro-manage in the middle.
By having fixed timeboxes, a prioritized list of stuff, and giving control over commitment to the team, you can have lots of little wins over time, which is a great morale booster and also helps you spot problems much earlier than with a long-range plan.