views:

253

answers:

12
+4  Q: 

Progress Reports

I'm not talking about the kind you get in college, but rather implementing progress reports on the Job for developers.

My thoughts in organizing a development team is encouraging and, to some extend, requiring regular progress updates were developers would report on what they did in the last hour or few hours and how long tasks took. Below I listed a few of the pros that come to my mind

  • Allowing me to go back and see were I might have made a mistake and allow myself a starting point when working to solve a problem that I created.
  • Gives teams a good understanding of were they are on the project and regular updates
  • For future projects, the ability to go back and see how long a certain task took and create an accurate estimate
  • Encouraging a greater amount of communication among a team

What I would not want to see happen is it become a way for breathing down a developers back, and I think it could easily become a distraction if one felt pressured submit updates every hour.

  • What are you thoughts?
  • Pros and Cons.
  • Have you ever experienced this first hand? How did it make you feel?
+10  A: 

Every hour is too frequent. That many interruptions will decrease productivity, and increase developer frustration. I would suggest looking into the Scrum methodology, they have a "daily scrum" meeting, every morning where you update the team on your progress the previous day and planned work for the current day. It has worked well for me, it might work for you.

Scrum also includes the concept of story and task cards where you estimate time, and eventually come back to see how far off your estimates were. This give s you a "focus factor" that you can use to help increase the accuracy of future estimations.

Check out this PDF Scrum and XP from the Trenches for a good read about it.

ctcherry
A: 

The scrum methodology handles this pretty well. You have short daily meetings to report progress and obstacles. It allows everyone to be caught up without being bogged down by the minutia.

DaveK
A: 

Look up Scrum, it is an agile approach that defines everything you want to do and works great for our team (as well as many others I have read about).

NotDan
A: 

Agile scrum actually enforcing this. We are following VSTS Scrum methodology and project template to track all Task/Bug etc. and we can easily set a field for the time reporting(Which we are thinking of implementing soon) So that the final data will be so useful for the organization to asses the people for appraisal. If they lack some expertise we can easily find that out with this close tracking. But the practicality of this is a big ?

Jobi Joy
+1  A: 

Progress Reports every few hours are overkill. If you're working using source control you can get a great deal of mileage out of keeping track of your checkins and setting a standard for your developers to comment on any commit/checkins that they do. In this way you're not badgering them (and incurring very expensive context switches) but you're allowing them to stay in their flow while still being able to monitor progress.

Depending on how sophisticated your source control is, you can correlate tasks to commits/checkins which is additional granularity for keeping track of estimates.

David in Dakota
+3  A: 

This is yet another example where Project managers fail to understand their role. Scrum is not an answer, nor any other doctrine. Why on earth would you, in any organization and to better support or be part of a decision, need hourly reports? are you workers fish? do they have no more than 60 minutes of recollection, needing you to troll on by "hey Jeff... how is it going?"... completely mind-exhausting line of thought killer forceps-driven pause "wazup patcouch22?... whom I seen 59 minutes ago..."

And what if you understood, to the infinitely detail, what went wrong with the last slip... will the exact same derailments happen on your next project? Even if it did, do you understand the robotization required to avoid all forms of slipage/error/progress?

Be humans... be helping humans, for crying out loud! there are no miracle mathematically structured ways to achieve high-levels of productivity... just heuristics. Read The Mythical Man Month and others... it's not so much on poor management techniques, it's about accidents and because we're dealing with humans.

The best and team-productivity enhancing thing I've done (when I'm "just" a PM): keep my staff well fed, well slept, with regular schedules, and offer them my "ask me your dumbest question, I'll only answer IFFFF I'm 10000% sure of the answer". Shield them from the pressures above, solve for them the problems below, make sure they know you're there for punching-bag duty.

jpinto3912
+2  A: 

I'd avoid status reports all together, but if you must use them, make them no more frequent than weekly. Good developers are more like artists than laborers. They produce great work in creative spurts and not with clock-work regularity. If you require frequent status reports, they'll feel unnecessary pressure which will actually make them less happy, less creative, and ultimately less productive.

C. Dragon 76
+4  A: 

Usually, requiring status reports more frequently than once per day will get you a lot of Office Space TPS Report comments. Any benefit you will see in more project data will quickly be out-weighed by low morale and general team malaise.

Try asking for updates on a regular (maybe daily) basis. Don't ask for formal, written reports, that's your job as PM to produce those for your boss. Developers have development work to do. Try not to burden them with managerial tasks.

Pragmatic Agilist
A: 

I'd nix the status reports if you can. Although it sounds like a good idea it sends the message that you're trying to manage the people, and not focusing on the best way to get the work done. From what I've seen, people seem to work best when you describe some of the work that needs to get done and then give them plenty of room, then offer yourself as a resource. I'd think something like hourly reports would be tough on everyone, including you.

A quick morning meeting (similar to scrum) can be helpful - if anyone is hung up it becomes apparent pretty quickly since they're saying the same thing each day. It also gives other people the opportunity to step up and offer to help, which you can always privately note if you wish or if you've got a boss that likes the idea of reviews.

inyourcorner
+2  A: 

We use twitter.com for team updates. I ask my team to tweet when they start a task, midway through a task, and when they finish the task and start a new one. This way:

  1. I know what they are up to fairly frequently and I don't need to barge into their office and always ask, 'What are you working on?'
  2. If a developer goes silent for too long I can go and offer help.
  3. Developers can ask for help easily without barging in on another developer
  4. The character limit in Twitter ensures updates are short, and do not require a lot of time to create.

We all set our accounts to private accounts to ensure no one outside of our group gets our tweets. We've been using it for a better part of two months...it has really opened up to me what my guys are doing without being intrusive.

ben
A: 

Everything about leading a team is scheduling, motivation, prioritization, and conflict management.

I get my team together every Monday morning before we start work to chat about their work.

We talk about what we accomplished the previous week, and what we're looking forward to getting done the upcoming week.

On top of that, we each bring up something we did (usually code-related) that was really exciting in some way. Some piece of code that just worked; A napkin sketch of an idea for a new app; A new technology that could enrich the rest of the team;

There's always something.

I've found that on top of starting the week off with a gratifying list of accomplishments, it also is invigorating to think about what the future holds, and what awesome projects/accomplishments await.

We work out logistics outside the meeting. Schedules, priorities are handled on an individual basis.

Such meetings have actually turned out small things like Finisht.com and Twenis.com. It's been very cool, and the team I work with can get so excited about coding that I sometimes can't believe it.

Pete Karl II
+1  A: 

There are two things that you want to do.

Daily Meetings

All you want to do is ask two questions.

  1. What did you do yesterday?
  2. What are you going to do today?

Very quickly you will establish if the developers are making progress or if there are any issues that are causing delays. Trying to get updates more regularly will prove to be overkill and probably be perceived as micro management.

Weekly Progress Reports

Once a week, take half an hour to put together a simple report that covers the following

  • Achievements
  • Assumptions
  • Dependancies
  • Issues
  • Resolutions

It shouldn't take much effort to do this and it will give you a very good insight into how the project is tracking. It's also very effective in providing management or clients and overview of what's happening and what needs to be addressed.

For a more comprehensive overview, visit the following links

Cheers, Marty

Martin Bauer