Ask HN: How would you manage an existing software team?
5 comments
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 of it, you don't trust whether those existing developers are any good. There's a million ways to find out if they are, some of which are described in my old article at http://inter-sections.net/2007/11/13/how-to-recognise-a-good... , but you'll have to figure this one out for yourself, I guess.
If they're no good, you need good ones. If they're good, then I would suggest toning down the control/paranoia in your plan and trusting them.
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 of it, you don't trust whether those existing developers are any good. There's a million ways to find out if they are, some of which are described in my old article at http://inter-sections.net/2007/11/13/how-to-recognise-a-good... , but you'll have to figure this one out for yourself, I guess.
If they're no good, you need good ones. If they're good, then I would suggest toning down the control/paranoia in your plan and trusting them.
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-incidentally, if I do need to setup this kind of environment, do you have any recommendations on the software infrastructure I should use?
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-incidentally, if I do need to setup this kind of environment, do you have any recommendations on the software infrastructure I should use?
I'll reply here as swombat has raised the point that struck me.
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/
[2] http://github.com/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.
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/
[2] http://github.com/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.
I'm interested in your proposition - if they don't have an SVN repo and bug tracking systems they're not real developers.
To clarify: I am not partial to SVN. My key point was that if they have no SCM whatsoever, they are not worth their salt. No sensible developer would develop any application with more than 1 developer without an SCM. Few sensible developers would even develop a 1-developer app without an SCM (unless it's really just a test app/prototype to be thrown away.. and even then...).
I don't have any other major indicators, other than the ones in my article.
With respect to software infrastructure, I'd recommend using hosted solutions (github, fogbugz, etc), whichever ones you find most useful for your project.
To clarify: I am not partial to SVN. My key point was that if they have no SCM whatsoever, they are not worth their salt. No sensible developer would develop any application with more than 1 developer without an SCM. Few sensible developers would even develop a 1-developer app without an SCM (unless it's really just a test app/prototype to be thrown away.. and even then...).
I don't have any other major indicators, other than the ones in my article.
With respect to software infrastructure, I'd recommend using hosted solutions (github, fogbugz, etc), whichever ones you find most useful for your project.
> There is an existing team working on these solutions, and they say they're about 50% ready to launch.
> ... work with the developers to build a realistic set of phases and milestones in the project.
Somewhere between these two statements there's a problem.
What makes you think that they don't have a set of phases and milestones, that said phases/milestones are somehow inadequate, or that you can do significantly better right now? (I'm perfectly willing to assume that you can do better three months from now, but I'll bet that they can too.)
If they don't, you've got a huge problem. But, you haven't said anything that supports that assumption. So, why are you making it?
> ... work with the developers to build a realistic set of phases and milestones in the project.
Somewhere between these two statements there's a problem.
What makes you think that they don't have a set of phases and milestones, that said phases/milestones are somehow inadequate, or that you can do significantly better right now? (I'm perfectly willing to assume that you can do better three months from now, but I'll bet that they can too.)
If they don't, you've got a huge problem. But, you haven't said anything that supports that assumption. So, why are you making it?
For someone without experience you're doing pretty good, I've seen plenty of people approach this in the dictatorial style and fail miserably.
Asking the coders to set their own milestones and then keeping them to it has worked well for me in the past. That way it is not your deadline they have to make but their own, which goes a long way towards making people accountable.
good luck!
Asking the coders to set their own milestones and then keeping them to it has worked well for me in the past. That way it is not your deadline they have to make but their own, which goes a long way towards making people accountable.
good luck!
Thanks! I'm an IT guy at heart myself - Dilbert style management makes me break out in hives.
Appreciate the feedback on the milestones. I'm very interested in what a coder would generally consider to be best practices in a software rollout, and how to keep people interested, motivated and on track.
Any further insights or feedback would be great.
Appreciate the feedback on the milestones. I'm very interested in what a coder would generally consider to be best practices in a software rollout, and how to keep people interested, motivated and on track.
Any further insights or feedback would be great.
out of interest does the existing team work out of an office or from their own locations? And also is it their full time project?
(I have some comments to make but the specifics depends a bit on the answers to those questions)
(I have some comments to make but the specifics depends a bit on the answers to those questions)
Thanks for your reply.
Currently they're working out of an office, but I'm open to more flexible arrangements. Yes, this is their full-time project.
Currently they're working out of an office, but I'm open to more flexible arrangements. Yes, this is their full-time project.
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.
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.
Thank you for taking the time to comment.
This could even become my standard way of working with coders.
Thank you for taking the time to comment.
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
A very interesting opportunity has come along : an old client of mine has setup a small software company with 2 coders. The plan is to sell subscriptions on a SaaS basis to small businesses for common small business requirements - invoicing, expenses, timesheets, forecasts.
He wants me to manage the company, and get the product built and delivered.
I've examined the business plan, and I think the business model is workable. There are plenty of competitors in the market, but with my insight into small business, I have some unique ideas that would make for a compelling product.
My problem is that I know very little about software. I've run a few successful software projects in my old business (websites, inventory tools and so on), and I have a decent understanding of IT and business, but this would be a very new venture for me.
There is an existing team working on these solutions, and they say they're about 50% ready to launch. In reality of course, this could mean 20%.
I'm comfortable with the marketing, sales, budgeting, accounting, business side, but I'd like HN's opinion on actual product development.
My current plan for the product development is :
Have the existing code independently examined by a 3rd party with no stake in the project.
Setup a SVN Repository, and Bug Tracking systems.
If the code checks out, work with the developers to build a realistic set of phases and milestones in the project.
Hire a part-time tester to test the coder.
Give the developers plenty of space to work.
Once I'm sure they're the right guys for the job, consider some kind of share arrangement for their services to increase motivation.
Release.
Improve.
Repeat as necessary.
Am I coming at this completely the wrong way? How would you approach this challenge?