18

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?

Community
  • 1
Saeed Neamati
  • 18,142
  • 23
  • 87
  • 125
  • 21
    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 Eberle Sep 13 '11 at 03: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 04:55
  • 10
    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 07:32
  • 5
    Make sure the TPS reports have the correct cover. – Simon Richter Sep 13 '11 at 09:50
  • 1
    You should always feel free to reinvent the wheel. And I love how you choose to let your developers design their own wheels as well. Your vehicle may not go forward very well but i am sure it has lots of interesting wheels. – SoylentGray Sep 13 '11 at 13:17
  • 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
  • 2
    lol. I think the hiliarious comments on the question kind of address what peoples main thoughts are on this type of approach. My thoughts? If you implemented this where I work... I'd quit asap. – Anonymous Type Sep 13 '11 at 23:58
  • 2
    Why do you need to coordinate developers every day? Are they sheep? Developers are intelligent enough to coordinate themselves. Even once a week is pushing it. – Asclepius Jun 11 '14 at 02:48
  • @A-B-B: Developers are not sheep, but many companies would like to treat them as such. – Giorgio Jul 06 '14 at 07:24
  • @A-B-B agreed developers have the ability to coordinate themselves but the problem is that they frequently lack the wisdom to realise the benefits of so doing - if that *wasn't* an issue then these practices wouldn't have arisen in the first place – Murph Jul 06 '14 at 08:29
  • @Murph: There is a very high demand for developers and certain practices make it more profitable for companies to employ less experienced / lower-level (and therefore cheaper) developers because they compensate for the developers' poor organizational skills. – Giorgio Jul 06 '14 at 08:51
  • @Giorgio I won't disupute that - but you've kind of not grasped my point - just because people can do things doesn't mean that they will (for all kinds of reasons) therefore you need to provide structure to help. Most of us are not rock stars and most of us need guidance. – Murph Jul 06 '14 at 10:26

11 Answers11

38

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.

S.Lott
  • 45,264
  • 6
  • 90
  • 154
  • 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 03: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
  • 1
    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 01:52
  • Even better - "I would like to have estimates for the report about coding." – Nagarjuna Borra Oct 13 '22 at 05:58
11

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.

Demian Brecht
  • 17,555
  • 1
  • 47
  • 81
  • 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 03: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. –  Sep 13 '11 at 06: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. –  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 01:56
  • @S.Lott - why both a CV/resume *and* an interview? Why make slides *and* give the presentation? Each could be called duplication, but that would be missing the point. As I said, I usually keep a to-do list anyway. e-mailing it would be a few-seconds job. A minute reviewing it would be sensible preparation for that quick verbal report - even though what I would say wouldn't be just iterating through that list. And just because the spoken report says things that the to-do list doesn't, that doesn't mean the to-do list isn't read, and doesn't mean it's useless. –  Sep 14 '11 at 23:53
  • @S.Lott - basically, I see no reason why a manager wouldn't want to know the simple what-jobs-have-I-crossed-off *and* the more subjective what-I-think-is-significant. Ideally not in a micromanaging way, but we're only talking about a few minutes each day here. –  Sep 15 '11 at 00:02
  • @Steve314: I can see you really, really like doing twice the work. That's good. I find that the written report is useless since the conversation happens no matter if it was written, submitted or skipped. Since you really like doing twice the work, please post your own answer explaining why doing twice the work is so good. My answer is not your answer. I find that doing twice the work (when the written part is ignored) is wasteful. That's my answer no matter how much you like doing twice the work. – S.Lott Sep 15 '11 at 02:08
  • @S.Lott - you do know that twice zero is zero, don't you? I already said (repeatedly) that I usually keep a to-do list anyway, and pasting that into an e-mail is so close to zero work that it's not worth quibbling. We've probably wasted more far time writing these comments than it would take me to e-mail a years worth of these these to-do lists. So why obsess over this particular "twice the work" issue? Of course if your issue is a more time-consuming written report, then you're right - but from the start my point was about e-mailing a to-do list that already exists. –  Sep 15 '11 at 22:06
  • @Steve314: You do know that a written report which is ignored is work that is of no value? You write a report and you **still** must go to meetings to review the contents of the report. Why even click send if it is only going to be ignored? "mailing a to-do list that already exists" is **not** what the question asks, is it? If it is, please correct my failure to understand the question. Please stop repeating your assertions and your (actually smart) work-around to bad management. My answer stands based on my experience. You may be good working around bad management. I can't suggest it. – S.Lott Sep 15 '11 at 22:37
7

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.

Wayne Molina
  • 15,644
  • 10
  • 56
  • 87
6

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.

  • +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
4

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.

Giorgio
  • 19,486
  • 16
  • 84
  • 135
2

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".

SoapBox
  • 121
  • 4
  • 1
    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. –  Sep 13 '11 at 06:34
  • @Steve314, lol true, potentially a good way to proactively spot the next round of *ahem* retrenchments. – Anonymous Type Sep 14 '11 at 00:01
2

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.

poolie
  • 362
  • 2
  • 11
2

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.

user937146
  • 626
  • 6
  • 4
2

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.

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
2

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.

keppla
  • 5,210
  • 24
  • 32
2

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.

Vladaimir Cetkovic
  • 161
  • 4