Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

In another question, I asked about why developers might don't like daily scrum. We talked to developers and we decided to not hold daily scrum for a while (to give it a try and customized scrum in our first attempt). This is the output of consulting with developers directly.

On the other hand, we don't want to lose good parts of daily scrum, like getting a chance to coordinate developers everyday, or watching the work progress like a Key Performance Indicator, to take actions early.

As an alternative to daily scrum, we're thinking about asking developers to provide daily reports with the following conditions:

  1. No need to follow any specific format. Each and every format is accepted.
  2. Even if the work is not done, we want to hear the amount of progress.
  3. There is no need to mention the time spent on each task.
  4. Development obstacles and coordination requirements should be mentioned.
  5. There is no need to be obsessed with daily reports. It's not taken that strict.

Do you think that this can decrease their productivity? Have you had any daily report experience? Do you have any suggestion for us, so that we can get sure that we're not micromanaging?

share|improve this question

closed as primarily opinion-based by Jim G., MichaelT, gnat, BЈовић, GlenH7 Jul 6 at 13:35

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

20  
If your scrum meetings take more than 5-10 minutes, you're not doing it right. Scrum meetings are not a place to fix or discuss. All you do is say: what I did, what I'm doing, and what's blocking me. It takes 60 seconds and should not be stressful at all. Any further discussions should happen outside of scrum. –  Chris Sep 13 '11 at 3:50
3  
Can you say more about what benefit you will get (or hope/expect to get) from daily reporting? –  poolie Sep 13 '11 at 4:55
9  
I hate point #2: it doesn't solve any problem from the developer's side, only from manager's. Plus it indicates that the boss doesn't trust me in my work. I prefer what Chris says: what I did, what I'm doing, what's blocking me. –  mouviciel Sep 13 '11 at 7:32
5  
Make sure the TPS reports have the correct cover. –  Simon Richter Sep 13 '11 at 9:50
2  
Is there a reason to talk to other carbon-based lifeforms given source control integrated with a bug tracker and a CI server? –  Wyatt Barnett Sep 13 '11 at 14:12
show 7 more comments

11 Answers

up vote 32 down vote accepted

As an alternative to daily scrum, we're thinking about asking developers to provide daily reports with the following conditions:

What a terrible idea.

Do you think that this can decrease their productivity?

Yes.

Why? A verbal presentation at a meeting combines writing and n people "reading" the report into one concurrent activity. Talking plus Listening. Over and done with. Questions answered right away.

Writing a report is a waste of time because there will be questions and you'll have to review the report with folks who (a) have questions and (b) didn't really read it.

Daily reports, won't get read. They rapidly devolve to in-box-noise.

"There is no need to be obsessed with daily reports". In which case, why do them?

Do you have any suggestion for us, so that we can get sure that we're not micromanaging?

Yes. Have a daily stand-up. It takes a few minutes and you're done.

If your daily stand-up takes more than a few (15?) minutes, you're sharing way too much detail and need to schedule separate meetings for those details. Daily stand-ups are easy to do. After a 2-minute summary, everything else is probably details, not for the whole team, and needs to be pushed into a follow-up meeting. The meeting moves on to the next person's focus for the day.

share|improve this answer
6  
+1 "If your daily stand-up takes more than a few (15?) minutes, you're sharing way too much detail ..." in our weekly meeting (where we get in contact with developers who are interstate) we really try to reinforce this type of rule. We've had meetings that have run way too long and since we schedule it before lunch .,.. well you get the picture. –  James Khoury Sep 13 '11 at 3:17
    
The longest stand-up that I was involved with was 20 minutes, and that was because of an influx of people. We not only had the development team, but interns, co-ops, and one or two contractors. Not everyone always talked, but if a lot of people had relevant updates, it pushed the limits. At 20 minutes, attentions started to wander, so that became the cap, until the numbers decreased and we went back to 15 minute meetings. Typically, though, 15 minutes is a good time to shoot for. –  Thomas Owens Sep 13 '11 at 10:46
    
Do you think that this can decrease their productivity? Yes. lol so true. Why aren't you coding?? coz I'm writing a report about coding. –  Anonymous Type Sep 13 '11 at 23:59
    
+1: "I'm writing a report about coding". The Micro-status is "I'm providing macro-status report". –  S.Lott Sep 14 '11 at 1:52
add comment

I've done these in the past, but in the morning as opposed to the end of day. It generally took less than five minutes to fill out, so no, I can't see how there would be any decrease in a developer's productivity. The nice thing about doing it in the morning was that it made you think about what you're going to do for the rest of the day.

Having said that...

We found that it was more times than not, it wasn't the most effective method of communicating what we had done the previous day and what we were going to work on that day. Why? People generally didn't read them. It was a scheduled Outlook task, so everyone sent them out every day, but either they were glossed over or just missed altogether (other than by leads or management).

We found that having the daily stand-ups were much more valuable as people tended to listen to each other. Also, if there was a misunderstanding, it would be flushed out then and there, which is more apt to happen than someone replying to a daily status e-mail to ask further questions.

share|improve this answer
2  
+1: "they were glossed over". I've worked for customers who wanted daily status, but still insisted on meetings to discuss it. If we were going to have the meeting anyway, why write it all down first? –  S.Lott Sep 13 '11 at 3:00
    
@S.Lott - maybe because it's written down anyway - basically the to-do list that many people will use to keep track of their own progress. Given that (from the question) "there's no need to follow any specific format", I'd be more than happy to copy and paste my to-do list complete with struck-out completed items - I usually do that each day to start to next days list anyway. My spoken report would focus on what I remember and what I think others should hear - so it would miss things out compared with the written, but also speculate about upcoming issues that may affect other people. –  Steve314 Sep 13 '11 at 6:49
    
@Steve314: "My spoken report..." That's a noble effort to make the most of a bad situation. More fundamentally, however, why duplicate? If the written report is simply not being used for anything, why do people ask for it? –  S.Lott Sep 13 '11 at 12:19
    
@S.Lott - if it's not being used for anything, that's true. But I've heard plenty about programmers thinking everythings ticking over fine with plenty of progress being made, while the managers are in a panic because they haven't heard anything for ages and so assume people are keeping quiet trying to hide a total lack of progress or some oncoming disaster. Let the managers see some ticked-off to-do items and maybe that can be avoided. As for the duplication, human communication needs redundancy - everyone involved is only human. –  Steve314 Sep 13 '11 at 20:31
    
@Steve314: "programmers thinking everythings ticking over fine ..., while the managers are in a panic". Not the point at all. A written report which merely leads to a meeting to discuss progress was not read. If it was not read, why write it? You can make a noble effort to turn a bad situation good. But a written report which only leads to a follow-on meeting is a waste of a written report. Just have the follow-on meeting. Just have the follow-on meeting daily. While standing up. And be done with it. –  S.Lott Sep 14 '11 at 1:56
show 5 more comments

In all honesty, allowing anyone to report in without constraints seems a tad too far to the liberal side of the equation. Where I work, we go in a circle and each developer gives the following:

  1. What was done the prior day. Not all the tiny details, but overall.
    • If the above is not finished, if not, what is needed to finish and how long it will take.
    • If the above is finished, what the next task is, what is required, and the time time it will take.
  2. Blockers. If you're working on Foo, which depends on Bar, and Bar is not finished, this needs to be made clear.

Setting up a general schema for everyone to follow can make going through a given report easy. You can easily setup some method for everyone to get an email with the daily reports, and thus allow anyone to find out what is going on.

share|improve this answer
    
+1: we are doing the same. Not daily, but weekly on monday for the whole week (so your way, just on a bigger timeframe). We aren't doing it daily because most employees are students and aren't there every day, most communication is via IM or similar as well, so a weekly meeting between the whole team (about 10) is sufficient. –  Femaref Sep 13 '11 at 14:44
add comment

IMO any type of daily meeting/report decreases productivity because it, to be frank, stinks of micromanagement. Yes, I'm aware of Scrum and the like and those aren't too bad provided they're short status updates ("Hey how is Project X coming?") but I firmly believe that it's insulting to professional developers to keep tabs on us at that low a level; it's akin to using timecards to make sure we're in the office 8 hours a day, or making sure there are no walls so you can spy on people's computers to see what windows they have open at a given time.

If you have to keep tabs on everyone to make sure they're working, it means you don't trust them. If you don't trust them, there's a bigger issue at work than the one you are worrying about.

share|improve this answer
add comment

My team has been doing scrum for about one year now. Before that we were having two meetings a week, during which each team member reported about his / her activity in the previous 2, 3 days. Each meeting lasted between 30 minutes and 1 hour. In case we needed to exchange information and coordinate our work, we just used to go up to our colleagues and speak to them (which we still do, of course).

Now that we are doing scrum we often have the impression that one meeting a day (even though it only lasts 15 minutes) is too much. Often the reports of some members boil down to: "Nothing new since yesterday". We have often had the impression that the 2-meetings-per-week schema was more effective.

Another downside is that the daily meeting is a planned interruption (see e.g. Paul Graham's article, point 1. Avoid distractions): since you know the interruption is going to come, you are not going to start anything difficult before the meeting (daily meetings may take place one to one and a half hours after one has started work).

Last but not least, while early feedback does have advantages ("Oh, you are working on that problem, we should discuss it!"), it is sometimes more effective to start a discussion only when you have already organized your ideas in your mind, you have specific questions, and you feel ready for discussion. Instead, daily reports can quickly cause a lot of unnecessary and unstructured brainstorming. So, beware of too early feedback: it can confuse you and slow you down.

So: in some cases daily reports did decrease our productivity. On average, I do not have the feeling that they made our work more effective.

UPDATE

I wrote my original answer a couple of years ago, and meanwhile I have switched teams. In my current team, we are doing daily meetings on-demand, i.e. when we feel we need a short status update. So, every day there is the possibility to have such a meeting but we do not do it if nobody requests it. We do have a weekly retrospective meeting. This is basically very similar to the approach we were originally using in my previous, non-agile team: fixed weekly meetings plus additional on-demand meetings during the rest of the week.

share|improve this answer
add comment

If what you really want is a rough status and to make a note of any obstacles the best way is to ask them for a short "daily status email". If you put too much emphasis on it, or make a list of what it should/should not contain then at least some of your devs will spend extra time crafting it to meet the requirements. Instead of that, just ask for a simple email. When things come up through the day say things like "oh, put that in your end of day email" and if you get a really long end of day email, mention casually "you don't need to be that detailed every day".

share|improve this answer
    
If you don't say exactly what you mean by a short daily status email, at least a few people will spend hours each day worrying if they're doing it right. –  Steve314 Sep 13 '11 at 6:34
    
@Steve314, lol true, potentially a good way to proactively spot the next round of ahem retrenchments. –  Anonymous Type Sep 14 '11 at 0:01
add comment

It's very helpful to be clear about the purpose of any meeting or report, especially one done by everyone every day. You say the reason is:

we don't want to lose good parts of daily scrum, like getting a chance to coordinate developers everyday,

What do you mean by coordinate developers? What kind of work needs coordination and isn't been ad-hoc coordinated by the developers and their managers when needed? Is there perhaps some way you could identify tasks that will need coordination, and communicate in only those cases?

or watching the work progress like a Key Performance Indicator, to take actions early.

A many good KPIs (like site response time, or number of critical bugs) is going to be mechanically measurable, and you don't need to impose a cost on the developers to do it.

share|improve this answer
add comment

I've had to do daily reports in several different formats in the workplace. Generally speaking, I think the daily reports tend to only add value for managers, not for the developers themselves. While managers gain benefit from daily reports by being able to tell the overall status of each project and each employee's taskload in a short amount of time, in my experience most developers do not bother reading each others' status reports.

However, it seems like by not enforcing a format for your daily reports, you make the reports harder to read and process for both managers and fellow developers, thus exacerbating the issue of lost developer time.

If you decide to move forward with daily reports for your developers, might I suggest using an internal wiki instead of email reports? That way you do not spam peoples' inboxes, while maintaining history of everyone's daily statuses.

share|improve this answer
add comment

Its a great idea to customise your Agile methods to make them suit you - so kudos for that.

So, daily reports instead, I'd say this isn't much better than a daily meeting, it's still the same "tell me what you're doing" approach, you've just made everyone write it down instead of speak it.

Here's an alternative approach: instead of using these 'polling' techniques where you ask each dev for their status, you use a 'push' technique instead. If the dev has nothing much to report, they don't, they should report any and all problems and progress as they occur however. So when they complete a module, they should email out to all the team that its finished, that its in SCM, where the documentation can be found, and a brief summary of what it is, how it works, and/or how to use it. If they have a problem, they should email the team asking for advice, help or any tips. (yeah, just like the old days where teams communicated well without the micromanagement we suffer today)

you'll find that this is much more productive, and constructive. You won't get meaningless reports for the sake of them and you will get a more motivated team as everyone likes to inform their peers of their work.

share|improve this answer
add comment

I also agree that it is a bad idea to replace daily stand-ups with a report. A daily stand-up is a great place to vocalize ideas and problems. This is one of the reasons I like the good old whiteboard (which we use alongside Jira+Greenhopper). The whiteboard is a place where the group 'huddle' and share information, everything is there, everything is visible, everyone moves and changes the stickies that they worked on, it also a lot of fun.

share|improve this answer
add comment

Cant you extract this information from your other tools?

  • What are you currently working on? The tickets i have assigned.
  • What is your progress? For tickets i have longer than 1 day, see comments in ticket or commit messages of the branch. Tickets i have shorter: probably done tomorrow (you dont make big 5+ day tickets, yes?)
  • What is the general progress? see open/closed-tickets-ratio
  • What needs to be organized? the tickets you get assigned back, with the status feedback needed, and everything discussed in your team's IRC, Campfire Room, whatever.

When you have more specific questions to answer, i would see the need for specific reports, but without that your reports look a little like an end in itself.

share|improve this answer
add comment

Not the answer you're looking for? Browse other questions tagged or ask your own question.