When it comes to project management, I tend to favor the less-is-more approach. For the most part, I think teams should be self-managed and organized. I’ve never seen project managers actually add value – they merely get in the way and slow teams down. That isn’t to say that I favor cowboy engineering, I just happen to think that software developers are better equipped at managing a project than so-called project managers.
Regardless of which software development methodology and hierarchy you use, there’s 1 core practice I think every team should use: estimation and tracking. It’s a trivial exercise which can yield substantial results. It isn’t a silver bullet, but in my experience it easily outweighs all other procedures. It works equally well for small or large teams and should take less than 10 minutes a day.
What do you need to do?
The first thing you need to do is break-down tasks and assign them to people. The next thing you need to do is put an estimate, in hours or days, on each task. This can either be done together by the team (preferred) or you can let each developer estimate his or her own tasks. Finally you need to update how much time has been spent on each task as you move ahead.
All of these things can be done using a modern bug-tracker. We currently use Redmine (http://www.redmine.org/).
There are a couple things you should do to make this a painless process:
- Avoid really short (less than 0.5 days) or really long (greater than 5 days) tasks. Short tasks should be grouped up together in a way that makes sense. Long tasks should be broken down. The longer an estimate, the more likely it is to be off. It’s ok to put-off breaking down a task until the work actually starts.
- Always estimate in ideal time (as though you were working on the task without any interruption).
- If you are estimating as a group, don’t spend too much time arguing about how long something will take. If everyone is pretty close, stick with the average or majority. If even one person is really off, discuss the task in greater detail. Maybe the hold-outs will point something out that’ll make others adjust their estimates.
- If you are estimating as a group, don’t let your quiet developers be bullied by your loud developers. Similarly, don’t let junior developers get trumped by senior developers. How you handle this is up to you, but you might try having everyone write the estimate on a piece of paper. You can also count to three and have everyone show fingers, at the same time, for how many days they think it’ll take.
This tiny bit of information is actually quite useful. You can plan on releases based on actual work rather than arbitrary release dates, you can gauge if developers are busy with non-programming tasks and you can hold developers accountable.
Some developers might not like being held accountable. I have mixed feelings about it myself, but deep down I know that there’s no reason why developers shouldn’t be. I don’t mean accountable in the sense that “you go over by 1 hour and you’re fired”. There’s nothing wrong with estimates being wrong, or unexpected difficulties being encountered, or even just not having a good programming days. When such things happen the estimates need to be updated and the team might need to help each other out a little more.
This is a system, and some developers will likely try to game it. To get any value from this, the team needs to meet every day and keep itself in check. Each member must go over what he or she worked on during the previous day. This will help keep individuals honest. You can spend 1 minute per team member, have him or her log his time in front of everyone, and move on.
(I know that many methodologies have very similar, if not exact, practices).