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

[Kevin Smith]

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20150909/b9e4a8cc/attachment.html>