I´m starting a small business that will handle code from some companies (the famous outsourcing business). Right now, I´ve studied a little of ITIL and PMBOK, within it i found lots of details and practices about project management, but I´m afraid in taking them too serious.
And then, this question has arised: What are the REAL best practices to manage a small dev team?
I would like to hear from more experienced people, and I´m sure i can find it right here.
Thanks in advance!
Don't manage them, let them manage themselves. Unless they're idiots, but then again, if that's the case you have bigger things to worry about.
This books is short but walks through some management. It is the from the perspective of a manager that manages project teams.
I found the book interesting.
If the team is small, consider NOT using a management BestPractice.
I've found out, if you have a good and small team, it works with SCRUM, XP, even old waterfall-Models: using these managementMethods only prevents you from finding the real problems, because you'll always think, there is a problem in the organisation.
I strongly agree with SCdF's answer, and I would add:
Read Peopleware. Unless your process is absolutely horrendous, it's all about the people.
With a small team, a process needs to be simple and light.
As others have pointed out, assume the best in your people. Developers are smart and independent; don't legislate every part of their workflow. Just focus on a few foundational things:
Set up good source control, require its' use in your process
Set up a build server and require nightly (or more frequent) builds
Set up a good test environment, and require it's use
Require code reviews before check-ins
Require unit tests for at least the core functions of your application(s)
Allow programmers to work directly with customers whenever possible
Use a good bug-tracking system. Require that everything go through it. But let devs enter their own bugs, so it doesn't become a bottleneck.
With code reviews, developers will quickly arrive at a consensus on good style and best practices at the code level.
A good resource for would be managers is Manager Tools. I can't recommend this podcast highly enough.
I noted that one person said that you should let developers manage themselves. Unless the developer proves that they are self managing do not make this mistake! Most people are not good at managing themselves and need guidance and leadership which is what a manager should provide.
Don't weigh down your developers with useless time tracking tools. However, do put some good issue/bug tracking tools in place (phpBugTracker is one I prefer). There are also several good open source tools for tracking administrative changes that I would recommend looking into.
Remember to listen to your developers when they give you time and cost estimates. Track this type of information from project to project and try to improve upon it. You should be on the side of your developers because they have your back. The manager needs to stand between the developer and the client in order to act as a buffer between the two (I'm not saying that the two sides shouldn't interact, but when an issue comes up the manager should be there to handle it).
Encourage, pay for and compensate for training. It doesn't take a lot, it doesn't have to be $2K conferences, it could be a some study time, book and certification exam here and there with a small bonus for completing a certification. This includes management training for yourself!
here are your 'bibles':
a few people have said it here, hire well. i will say it again, hire well. if you get that wrong, no book, process or software can save you. i wrote a short blog article a few months back which may help: http://pm4web.blogspot.com/2008/08/hiring-programming-staff-part-1.html
check out joel on softwares twelve point test: http://www.joelonsoftware.com/articles/fog0000000043.html <- that is money in the bank. if you want guarantees, thats the closest you will get. the more of these you do, the better things will get in your company. notice that using a bug tracking system is in that list, and everyone else here is saying its a good move. it will make your life (and your crews life) much more manageable.
some people here have said 'let programmers manage themselves' - i think some detail has been missed here. programming is what programmers do best, not time/task management. if you can afford it, hire a project co-ordinator or project manager (1 per 3-5 programmers). you can often get these people to serve duel roles as a business analyst if they have a technical background.
also, if budget allows, hire one senior programmer (e.g. 5+ years coding). the rest can be 'fresh out of uni, but hungry'. a senior coder will usually cost twice as much, but he will be twice as productive. the benefit they bring is industry experience, they've been in the trenches. dont push the senior programmer to be a project manager - his value is in leading by example.
stay as lean as possible with regard to documentation and processes. that goes for unnecessary meetings too. it will be tempting at times to write documents to solve problems you encounter (i.e. "if this happens, do this..."). there is an infinite number of delimems that will befall you in software development, being able to recover fast from getting knocked down is more important then having an answer for everything.
keep in mind that money is not the only way to pay people, especially in a small company. for instance, keep the fridge stocked with water or soft-drinks (that will cost you a few $'s per week). keep a fruit bowl stocked too. ask people whats of value to them. for instance, allowing programmers to start at 10am and finish at 6pm can make an immense difference to their happiness - happy programmers = better quality work, everyone wins!
lastly, and this is absolutely up to you - be a nice guy. you can make money in business by being a hard ass, and you can make money taking the soft approach too. the difference is when you build other people up, you build yourself up too.
LM
I've been in the position where you are. I agree with the ones up here - let the people manage themselves. Help them remove obstacles on their way, buy whatever you need to buy in order to have them focus on the right things. What you should focus on is the tools between your customers and your company. Ensure that noone is in direct contact with the dev team - buy tools where the customers send in requests and bugs where you sit and filter things. Let them get a SR number in return, and use the input to prioritize and plan releases with the customers and the dev. team.
If I understand you correctly - Change Management is one of the key things you should be worried about. If you get brilliant people, things will move by themselves (make sure that the brilliant guys also make out a brilliant team TOGETHER :))
I'm late to the party, but here is a post from my blog that I maintained a little while back:
The Wolf Credo:
Respect the elders Teach the young Cooperate with the pack Play when you can Hunt when you must Rest in between Share you affections Voice your feelings Leave your mark. Del Getz and AssociatesIt’s not enough to identify objectives, FTE’s and timetables. You have to focus your team like a unit. The wolf pack is natures most effective hunting unit, but in order to become that cohesive machine there are many activities that take place. “Respect your elders”, “Corporate with the pack”, “Teach the young” doesn’t sound like cut throat competition within the team. It also doesn’t really sound like SCRUM. The pack leader is there to silence the dissent that will destroy the pack. But the pack leader is the not only role.