Thoughts on software team status updates
January 25, 2011 12:01 PM   Subscribe

I'm a project manager for a small software group (6 engineers) and I'm considering a different approach to gathering status from the team. I'd like to throw it out to the MeFi community first to see if it seems like something that would be beneficial and fair from the developer's point of view. It's basically a weekly list of tasks that are shared with everyone. Details inside...

Here's my idea - start out the week by having all the developers write out all the things they want to accomplish that week in a shared google doc. At the end of the week, have them write down what they actually did.

I see this helping on multiple fronts - it gives me and my boss documented visibility into the current progress of the project, it helps the devs reflect on their own estimation skills and performance, brings to light any items that derailed them from their intended work week, etc.

I see this as an alternative to the Agile daily stand up meeting. We've tried this in the past and found it to be unnecessarily cumbersome. My concern about this method is that it might be too overbearing. Developers - what are your thoughts on it? Do you think this would work? Would you be cool with something like this? If not, what has worked for you in the past?
posted by unmodern to Computers & Internet (12 answers total) 15 users marked this as a favorite
 
It has been my experience that using shared google docs for project management turns into nothing but a headache. I would definitely look into something more designed for your goals like pivotal (which is still free for the next six months or so, but totally worth paying for, imho).
posted by hominid211 at 12:14 PM on January 25, 2011


I have used systems like this, and helped design/build task-based groupware systems somewhat this. Heck, I use one right now, every day.

In terms of expectations, you need to be ready to see and deal with a lot of "fluff" in the tasks. For the sake of filling up their lists, people will (consciously or not) add a number of items like "Continuing to document FEATURE" and "Studying SYSTEM" and "Refining FUNCTION code"... inherently immeasurable and noisy data that isn't of much value to management.

There are a lot of ways to limit that, but the best is to disallow freeform tasks, and force them all to come from a fixed set with suggested soft time-budgets. This doesn't work in all shops or in all industries (and in a software shop it is especially tricksy), but the more you can neatly package the most common recurring types of work, the more useful the resulting data will be. Simply being to report on "categories" of work is lovely for management. And then, yes, it can help with estimation sharpness on the part of the workers, too.

Another nice trick is a Twitter status-style "Currently: DOING THING" that the whole team (and management) can see at a glance. It keeps everyone subliminally aware of what is happening, and can inspire a lot of impromptu walkabout mini-meetings that are quite productive. Mine is a dashboard app, a sort of In-Out box on steroids. It's nice seeing what everyone is up to at this very moment... and it also helps me know when not to interrupt.
posted by rokusan at 12:15 PM on January 25, 2011


Lots of questions / suggestions come to mind about your existing process and what you're hoping to accomplish here (I'm a developer in a similarly-sized Scrum team):

1) What did you find cumbersome about a daily stand-up? We've been operating with the same basic Scrum team for about 2 1/2 years and 90% of our stand-up meetings are under 10 minutes long. If you find you have stand-ups lasting longer than that, you might be Doing It Wrong.

2) I very much like the idea of comparing what you planned to do with what you actually got done; this is the essence of the "burn down" metric and gives you an idea of your estimation skills. In our team, when you complete a task you put it into an "early", "late" or "on-time" pile based on our a priori estimate of the number of hours it was supposed to take. At the end of each sprint (we do weekly sprints) we spend a short period of time (less than a minute) talking about each late task and looking for patterns - if we're systematically underestimating or missing on a class of tasks, this becomes fodder for our bi-weekly Sprint Retrospective meeting. We've found that this improves our estimation and upward communication.

3) It's not clear from your post, but are you planning to track items across the team, or on a per-developer basis? I'm strongly opposed to tracking individual developer performance within a Scrum team; it hurts team morale and harms the valuable culture of shared ownership that you get from Scrum.

4) What are you doing now as an alternative tracking / measurement system? The basic loop of a) define what you want to do, b) do it, and c) measure how much you did, is pretty much the fundamental Scrum cycle. In other words, what is it about your existing organization that makes you "Agile" (or do you not see yourselves that way?)
posted by bbuda at 12:28 PM on January 25, 2011 [1 favorite]


Have you considered a tool like PivotalTracker? I am a developer and use it with my small software team. It's free (for the moment), looks good, and serves us well as the sort of living document that you seek.
posted by JohnFredra at 1:02 PM on January 25, 2011


We have team members in different states/countries and for one particular project, we tried a scrum/agile-ish email every day where the devs would email all others on the same team (including boss, boss's boss, and salesman/customer liaison) the answers to these three (then an optional fourth) questions:
  1. What did you do yesterday?
  2. What do you plan on doing today?
  3. What issues did you run into that slowed your progress?
  4. What really super helpful/amazing thing did you accomplish that helps the team?
Our salesman loved it because he knew who was working on what and if there was any progress on it. This also made our customer, in turn, very happy.

Our boss loved it because he could see what issues arose and could better help us prioritize if needed.

The developers loved it because it took all of 2 minutes, really, to compile the answers and email to the team and no annoying meeting or conference call was necessary.

I set this up as my capstone project for my graduate degree and everyone seemed pretty happy about it.

But, a year later, FWIW, we don't do it anymore. That was one big project on which multiple people spent the extreme majority of their time. We've since much fractured what projects everyone is working on (for better or for worse).
posted by jillithd at 1:41 PM on January 25, 2011


Lots of great thoughts here.

bbuda - here are some answers:

1 - We started doing standups for a short while but we canned it because it was getting tiresome, even though they were short. I think the team had a difficult time engaging with each other in meaningful ways, most responses didn't seem helpful like - "fixing bugs again" or "still working on that performance feature..." We've since switched to longer but less frequent meetings.

3 - I'd like to track per-developer, but I do want to avoid the negative effects. However, isn't one of the points of a scrum meeting to keep the team accountable to each other or at least be aware of what they said they would accomplish?

4 - We're not a strictly agile process but do pull some principles from that methodology. We have a good tracking system for features, defects, who did what, etc.

jilliithd - I like the idea of doing it all electronically, especially since we have some remote developers. People may prefer this to the rigmarole of gathering together, setting up the conference call, trying to remember what you did, etc. My shared doc idea seems to be the same thing, just on a weekly basis, rather than daily.
posted by unmodern at 2:28 PM on January 25, 2011


We've tried this in the past and found it to be unnecessarily cumbersome. My concern about this method is that it might be too overbearing. Developers - what are your thoughts on it?

I've found it to be unnecessarily cumbersome and overbearing.

When I'm working on a project, leave me alone unless there's a legitimate need like a requirements change or something requiring a full-on meeting. Presumably developers have a task or project assigned to them and a deadline. Making your developers update a report card in the interim is frankly insulting. I would be livid if you made me do extra work simply to justify your empty, worthless middle-management heuristics.
posted by Civil_Disobedient at 2:31 PM on January 25, 2011 [4 favorites]


@Civil_Disobedient: I don't think asking developers to provide information on the progress is worthless. I have seen developers keep working for a week and then come back and ask for another 3 days beyond the deadline. The extension may be reasonable, but heck, don't ask on the last day! No one likes surprises.

@unmodern: Any system will work only if the developers trust you not to screw them. Any system can be gamed. My only suggestion is to have granular tasks which are either done or not done. Developers just tick about 10 items every week (Done/Not Done) and from there, you should do the math to calculate progress. Use an automated system (even if its Excel or a Google Docs spreadsheet).
posted by theobserver at 2:41 PM on January 25, 2011


I dunno, we have this, it's called Bugzilla. All the tasks go in there, and then you can see the ones I've finished by looking up the ones that are marked resolved. I mean, do you want me to write an essay about why I finished particular bugs/features every week? What are we trying to accomplish here?
posted by tylerkaraszewski at 4:50 PM on January 25, 2011


For that kind of job, I would think that daily statuses would be cumbersome, unless you were in deadline mode.

My boss manages about 12 people across the state, and he simply calls us every Tuesday for updates on things that are currently important. "What's up for today, what's the status on x, how are things going?" Tuesday for two reasons: it coincides with a meeting where he has to give statuses, and nobody wants to talk to the boss on a Monday.

However, our work runs through a task and hours accounting system, so basic statuses are available to everyone who cares to look. The phone calls are just for context.

I really like task systems, when the tasks are granular enough that you can accomplish a number of them a week.

Also, don't ask or expect your team to motivate themselves through peer pressure, "teamwork" or embarrassment. They report to you, not each other.
posted by gjc at 5:31 PM on January 25, 2011 [1 favorite]


Feels overbearing unless you are really talking about junior developers.
posted by ch1x0r at 6:49 PM on January 25, 2011


Can you use something like RT (Request Tracker) and do it that way? Also, saving your updates for the end of the week always seems to generate a lot of fluff/padding/to-the-best-of-my-memory, whereas more-frequent updates -- read: "daily" -- get you better informaiton and more of it.

(I have five direct reports. The weekly updates that are written in real time are obvious and are supreior, while the ones written on Monday morning suck.)
posted by wenestvedt at 9:14 AM on January 26, 2011


« Older Decorate my apartment for me, please!   |   Double the please, double the fun Newer »
This thread is closed to new comments.