[teampractices] [Discussion] Term for always prepping for the next thing

[Max Binder]

Thanks all. I distilled the best practices for "sensation X" to:

   - Set priorities, execute in order, interrupt only if necessary
   - Stop starting, and start finishing
   - Forecast capacity, and use forecasting accuracy as a barometer for
   iteration length/batch size
   - Create MVPs, and shorten iterations as much as possible to ship *and*
   get feedback

Practices par for the course in these parts, but I appreciated the
discussion. Thanks all!

On Wed, Sep 9, 2015 at 10:32 AM, Kevin Smith <ksmith at wikimedia.org> wrote:

> 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.
>
> 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).
>
> 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.
>
> 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.
>
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Mon, Sep 7, 2015 at 9:10 PM, Rob Lanphier <robla at wikimedia.org> wrote:
>
>> On Mon, Sep 7, 2015 at 1:27 PM, Max Binder <mbinder at wikimedia.org> wrote:
>> > Everything is set at an equally high priority, with each upcoming task
>> > usurping the priority of the current task. There are no low priority
>> moments
>> > because stress of the upcoming tasks is the motivator to do the work. I
>> also
>> > do believe that context-switching is not limited to the traditional
>> phrase
>> > "multitasking," in that you can still do one thing at a time, but if you
>> > don't carve out capacity for preparing to do work then you can't execute
>> > when it is time to.
>>
>> Ah, I call that "being stuck in swap" (see the "Thrashing" article on
>> Wikipedia <https://en.wikipedia.org/wiki/Thrashing_(computer_science)>).
>> 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.
>>
>> 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 *is* a form of multitasking.
>>
>> Rob
>>
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150914/21c670b6/attachment.html>