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

[Kevin Smith]

Your 4 bullets are good, but I think "reduce batch (task) size" deserves a
bullet as well, or at least should be featured prominently on another
bullet.



Kevin Smith
Agile Coach, Wikimedia Foundation


On Mon, Sep 14, 2015 at 5:34 PM, Max Binder <mbinder at wikimedia.org> wrote:

> 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
>>
>>
>
> _______________________________________________
> 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/20150915/07439b74/attachment.html>