<div dir="ltr">It was perhaps a bad idea to use the short answer.<br><br>I would like to clarify some things:<br><br>* The rollout of the "daily status updates required" requirement is on hold while we sort out some details (we're discussing the content of the updates as well as tool improvements), as I mentioned previously in reply to Marco. I should have communicated this more clearly in this thread.<br>
* Speculation about what effects the requirement will have is somewhat premature, particularly in the absence of details of those requirements.<br>* We WILL NOT be asking for "do the same reports you've been doing with bsmedberg's tool, but daily"<br>
* We WILL NOT be asking for a level of detail that would require Vidyo logs and local bash histories<br>* The status updates we're asking for should generally not take you more than 10 minutes to complete<br>* We WILL try to automate collection of some info (and encourage developers to do so as well)<br>
* There WILL be information required in the updates that can't be fully automated ("what do you plan to do in the future", "what are you blocked on")<br>* The desktop team is DEFINITELY way cooler than the mobile team and our status update regime will want to make rnewman work on desktop<br>
<br>Gavin<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Aug 11, 2014 at 2:11 PM, Richard Newman <span dir="ltr"><<a href="mailto:rnewman@mozilla.com" target="_blank">rnewman@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> My hope is that it won't take long at all to write a daily report: 1-3 minutes. You know what you worked on today, and you should know what you're planning on doing tomorrow. I would strongly encourage you to do these daily reports at the end of the day, not the beginning, since everything will be fresher. I'd like feedback on whether this takes more than 3 minutes and if so why and whether more tooling would help!<br>

<br>
</div>I think there are some invisible costs here. My personal perspective (and again, feel free to ignore this because I'm not on the desktop team):<br>
<br>
* Switching into archaeology/update mode takes a big mental disjunction. I prefer to do that, and get a better picture of the state of the world, if I do it infrequently and deeply.<br>
<br>
* My daily status updates would contain either (a) no real info, or (b) useless details, from the perspective of the vast majority of readers. If I found out something worth communicating today, _I already communicated it_, using an appropriate level of detail for the audience I sent it to. Trying to make one update suit a huge audience -- product, UX, support, engineering -- requires a lot of attention.<br>

<br>
I like communications to be specific, targeted, and actionable. Status reports are none of these things, so they either waste my time (and aren't read), or waste my time and the readers' time.<br>
<br>
* For daily updates to be stress-free, it needs to be 100% socially acceptable for them to be brutally honest: to have multiple days with the update "got nothing done", "spent most of the day arguing about status updates on IRC", "read emails and churned through bugs", "banged head against shitty docs".<br>

<br>
Remember that people optimize for what you measure, at the time scale that you're measuring.<br>
<br>
If you start measuring (whether deliberately or not) the impressiveness or consistency of daily status updates, you'll get impressive daily status updates -- even if that means that they're twisted truths ("I'll land this tomorrow so I have something to report") or the result of altered and sub-optimal behaviors (tackling smaller and simpler bugs, leaving the thorny ones to sit).<br>

<br>
These are well-known risks of agile even at the two-week iteration level, let alone daily. I've seen some horrifically dysfunctional behaviors caused by agile work-loading and reporting mechanisms.<br>
<div class=""><br>
<br>
> One of the distinct advantages of daily status reporting is that you have an opportunity to make a decision about your work each day.<br>
<br>
</div>I would say that it's great to make a decision about what you work on each day, and that's really nothing to do with status reporting. I use Trello for this.<br>
<div class=""><br>
<br>
> Another goal of very lightweight and frequent status reporting is to make sure that other people on the team know what you're working on and blocked on.<br>
<br>
</div>I don't know about everyone else, but that's what I use IRC, Bugzilla, meetings, direct email, and mailing lists for.<br>
<br>
</blockquote></div><br></div>