One of best ways I've found to track and review work of the team is as follows:
First of all, I don't want to go to the developers, disturbing them in their work and breaking their "flow" state just to know what they are doing.
This may appear as a wish to stay remote to the real work but let's put a bit of context: for the record:
- I have access to the CVS source tree and can see what is going on from the logs.
- Every single team member runs MSN Messenger so that ideas and pieces of code can be quickly exchanged.
- We have a newsgroup server running with groups for management, programming, design, and whatever is needed at the time so that we can keep track of isssues and other discussions. (As a side effect, this usually becomes a kind of written history of the project so that newcomers can quickly pickup the context).
To avoid running meetings for hours (but I usually run one every friday PM), we have an application called 'trackingreport' (I have made a spec and a junior coder produced it with servlets and XML files, a good way to get him trained on a real problem and make him give a contribution to the team - he also was asked to make a PPT presentation for his coworkers at the team meeting).
This tracking report is a simple web page with a selector for picking up a team member and a week number.
Then you go to a page with entry groups like (I based that on the so-called 'SCRUM' meetings - this can be seen as a support tool to ease them) :
- What I've done today
- What I plan to do for tomorrow
- What got in my way
and I just ask one line of text on any entry of those groups for every development of a feature during the day (no long explanation required, if one is required, they an email should be used).
As the team manager, I am able to review the sheets remotely and take action on their blocking factors.
For the team meeting, I print the sheets printed and review them, so I am able to prize whoever performed especially good work during the week and try to find ways to reduce the expressed blocking factors (as I see my role as a team manager as a blocking factors remover, a support person coordinating the activities of the project and the holder of the vision to decide on some issues that need decision).
Sheets are reviewed at the meeting and as the time for each sheet is pretty much set, the meeting lasts a predictable time, something that developers appreciate ! It has to be noted that every single team member has access in read mode to all sheets.
At the end of meetings, we run a 'I like'/'I don't like' (sometimes, if is a "did well/do differently' one) session about the things of the week. Just as an emotional exhaust pipe. It reinforces the team cohesion since problems are spoken out and good points are shared between people. During the session, every team member can speak for 2-3 minutes about the things he/she liked during the week and the things he didn't liked during the week (like "it was good to received this information about Oracle from X" and "I didn't much appreciated the way that Y spoked to me during this event").
As a last note, on the friday morning, people are expected to release the software for the week and run a set of tests (smoke test only - full testing every 2 weeks) and stay until the release is done.
If it has to take the whole day and night, so will it be... This has led us to a significant improvement of the release procedure (nobody wants to stay late). From undefinite time in the first iterations (sometimes like 2 full days of messing around), the whole freeze-checkout-compile-test-ftp-launch-unfreeze cycle went down to less than an hour.
This has been proved to be a workable manner and appears quite agile in my view. The team members appreciated it too as far as I can see.
How do you do the tracking ?
