<div dir="ltr">Thanks all. I distilled the best practices for "sensation X" to:<br><ul><li>Set priorities, execute in order, interrupt only if necessary<br></li><li>Stop starting, and start finishing</li><li>Forecast capacity, and use forecasting accuracy as a barometer for iteration length/batch size</li><li>Create MVPs, and shorten iterations as much as possible to ship <i>and</i> get feedback<br></li></ul><p>Practices par for the course in these parts, but I appreciated the discussion. Thanks all!<br></p></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 9, 2015 at 10:32 AM, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>Hopefully this depiction is an exaggeration of what is really happening, because right now I'm imagining someone whose "todo" queue is growing linearly while their "done" pile eternally remains empty. It seems odd that new higher-priority work would be coming in so fast
that not only can the old work not get done first, but the new work
can't either. <br><br></div>Whoever is prioritizing work needs to at least be able to distinguish between "something is on fire" and everything else. Only a "something is on fire" issue should interrupt work in progress. If those come up a lot, then it starts to sound like they need to hire someone else to put out fires, AND they probably need to look into who is starting all those fires in the first place (and stop them). <br><br></div>After that, I would push for the todo list to be fully prioritized. New stuff would only enter at the top if it was truly more urgent and important than everything else already in the list. Presumably many/most new tasks would actually drop somewhere farther down in the queue, which would result in the imminent work becoming more stable and predictable. <br><br></div>As a side note, task size could be significantly contributing to this problem. If tasks are days or weeks long, that greatly increases the odds of an emergency popping up before the current work is completed. I would look for opportunities to reduce the batch size to help work flow through the pipeline more smoothly. <br><br><div><br></div></div><div class="gmail_extra"><span class=""><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div>
<br></span><div class="gmail_quote"><div><div class="h5">On Mon, Sep 7, 2015 at 9:10 PM, Rob Lanphier <span dir="ltr"><<a href="mailto:robla@wikimedia.org" target="_blank">robla@wikimedia.org</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr"><span>On Mon, Sep 7, 2015 at 1:27 PM, Max Binder <<a href="mailto:mbinder@wikimedia.org" target="_blank">mbinder@wikimedia.org</a>> wrote:<br>> Everything is set at an equally high priority, with each upcoming task<br>> usurping the priority of the current task. There are no low priority moments<br>> because stress of the upcoming tasks is the motivator to do the work. I also<br>> do believe that context-switching is not limited to the traditional phrase<br>> "multitasking," in that you can still do one thing at a time, but if you<br>> don't carve out capacity for preparing to do work then you can't execute<br>> when it is time to.<br><br></span><div>Ah, I call that "being stuck in swap" (see <a href="https://en.wikipedia.org/wiki/Thrashing_(computer_science)" target="_blank">the "Thrashing" article on Wikipedia</a>). In software and in life, it's tempting to try to do too much, where "too much" may well be "too much planning". The software side of this problem is very well studied, and there are capacity management solutions. I'm not familiar with an equivalent term to "stuck in swap" that applies to planning, so I've used that metaphor liberally in the past.</div><div><br></div><div>Perhaps that's still the "multitasking" metaphor that you're trying to avoid, but I think that trying to plan the upcoming task at the same time as executing the current task <i>is</i> a form of multitasking.</div><span><font color="#888888"><div><br></div><div>Rob</div><div><br></div></font></span></div>
<br></div></div><span class="">_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></span></blockquote></div><br></div>
<br>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>