PM-Clinic: Week 7 Summary
Topic: Tracking programmer's work
Compiled: 11/8/2004
The Situation:
Dear PM-clinic:
I'm a new manager of a team of programmers and testers. An argument we're having now
is over the best way to track programmer work. Since the team is newly formed (many
folks haven't worked together before) each programmer comes from a different school
of thought about how to document their estimates, track them, and update. Some folks
who've used XP (Xtreme programming) before want a non-frills, super light weight solution
(e.g. a whiteboard in the hall), while others have good experiences with custom webtools
or other development tools.
I don't want overkill, but I also don't want something that requires a ton of work
everyday. How can I track engineering assignments, track estimates, and mark track progress,
without driving myself and everyone else crazy?
- Tracking programming work (TPW) in San Jose, CA
Know why you're tracking
Stellman wrote that the three most important reasons to track projects are
- See where we are with respect to the project plan .
- to have historical data so that we can estimate when building future project plans.
- Making each individual more aware of his or her contribution to the project.
More specifically, consider how information your tracking will be used to make decisions.
Each thing you track consumes more of your time and more of your programmer's time:
it costs time to track time. So before you ask for hourly status reports, ask yourself
what decisions that data will help you
to make. If you can't think of any, don't track that particular kind of data.
Common Tools
Whiteboard in hallway: Pros: lightweight. informal. visible. Cons: not digital (no backups,
remote viewing, hard to do bulk updates, etc.)
Excel: Pros: Easy to work with, flexible, lightweight. Cons: Doesn't scale. Everything
from scratch. Single use.
MS Project: Pros: Great for big monolithic work, small # of users. Cons: High overhead
if you're a small team/small project/frequent direction changes.
BasecampHQ: Mentioned but no one offered
a review.
(There are certainly other tools, but these were the ones mentioned this week).
General advice about tools
The magic isn't in the tools. It's in 3 questions:
- Does everyone care about the schedule?
- Do they understand the system being used to track?
- Are they willing to help the team track the schedule?
If the general answer is yes to all 3, the team will help you figure out the best way
to do the tracking, and can you to overcome any deficiencies you find in tools. If the
answer is NO to one or more of these questions, you'll have problems no matter how great
the tools are.
Also, consider what format the initial project plan was created in. Tracking work should
fall out of the planning work (And part of the planning effort should be thinking about
how to run the project and track progress in a way
that increases the odds of the plan being fulfilled on time).
Tracking
There is no way around some kind of regular and repeating process. Consider what the heart
rate of the schedule needs to be: are daily schedule checks really needed? hourly? Most
of the time once a week is sufficient to catch most major problems early. Pick a Wednesday
or Friday and have a team schedule check in meeting. Whatever tool is used should be updated
before the meeting, and then team leads can review progress, ask questions, respond to
issues, etc. If this is kept short (Focus on 3 questions: what's gone better than expected?
What's gone worse than expected? What should we do to respond to things that have gone
worse?)
Meeting-averse teams can do this without the meeting: a set time every week where every
programmer agrees to update their piece of the schedule. Managers and pointy-hats can
than meet on their own to discuss progress or
project strategy.
References
Delphi estimation, a tool
for group based estimations.
This week's contributors
Neil Enns, Andrew Stellman, Gareth Howell, and Scott Berkun.
|