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

[Max Binder]

I think it is good to frame time as a budget, because it is a finite
resource. Then the mantra becomes "I need to spend less" rather than "I
need more resources."

Hofstadter's Law (a favorite) relates better to our previous point on
measuring capacity. Estimating task size and complexity is a key part of
measuring capacity. Our bullet points earlier in the thread talk about
gaining forecasting accuracy over time, and subsequently adjusting batch
size with each iteration, to get a better understanding of how long it
takes to do something in one loop. Then re-prioritize accordingly, with the
umbrella understanding that finishing (or totally abandoning) work is
usually a higher priority than starting and stopping.

Jim Benson wrote an excellent book [1] on biases that talks about
differentiating "prediction" from "estimation." Prediction is the act of
aiming with the hope you are right, where estimation is is the act of
aiming with the understanding that you are wrong. The former points you
towards a status quo and disappointment when it is not met, where the
latter prepares you for inevitable change. It's a subtle difference that
can really help to focus on when trying to inspect and adapt properly.

[1]
https://www.mediawiki.org/wiki/Team_Practices_Group/Recommended_Reading#Agile_.28general.29

On Wed, Sep 30, 2015 at 12:14 PM, S Page  wrote:

> On Wed, Sep 9, 2015 at 10:32 AM, Kevin Smith  wrote:
>
>>  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.
>>
>
> The problem for me comes from ruthless prioritization vs. dealing with new
> small inbox issues in the moment. I'm sure I read some advice to do the
> latter instead of the overhead of managing an enormous growing pile of
> postponed work. Especially with documentation, tagging yet another mail
> thread "ought to document this nugget some day" vs. spending
> just-a-little-bit more time getting it done here and now. The problems are
> a) If there are too many small things you can get done in the moment, then
> those moments take over your day.
> b) Hoftstadter's Law [1].
>
> I guess the answer is to budget your time better. Thanks for any advice,
> though I don't expect any because answering this is not in your quarterly
> goals or current sprint :-).
>
> [1] "It always takes longer than you expect, even when you take into
> account Hofstadter's Law." https://en.wikipedia.org/wiki/Hofstadter's_law
>
> --
> =S Page  WMF Tech writer
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [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  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  wrote:
>
>> On Mon, Sep 7, 2015 at 1:27 PM, Max Binder  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 ).
>> 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@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

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

[Joel Aufrecht]

How much overlap is there between your sensation X and "future tripping
"?



*--Joel Aufrecht*
Team Practices Group
Wikimedia Foundation

On Mon, Sep 7, 2015 at 9:10 PM, Rob Lanphier  wrote:

> On Mon, Sep 7, 2015 at 1:27 PM, Max Binder  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 ).
> 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@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [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  wrote:

> On Mon, Sep 7, 2015 at 1:27 PM, Max Binder  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 ).
> 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@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

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

[Rob Lanphier]

On Mon, Sep 7, 2015 at 1:27 PM, Max Binder  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 ).
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@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

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

[Max Binder]

Thanks, Rob. It sounds to me like this particular case is a lack of good
prioritization, and tasks that are different enough from one another to
feel like context-switching even when doing one thing at at time.

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.

In this case, I would say priorities need to be set, and time needs to be
made between tasks/meetings in order to get into the right mindset,
particularly if the tasks are quite different from an execution standpoint.

Were there a term for this...

On Sat, Sep 5, 2015 at 12:16 PM, Rob Lanphier  wrote:

> On Fri, Sep 4, 2015 at 1:27 PM, Max Binder  wrote:
>
>> The future tasks matter, but so do the current tasks, and yet in order to
>> execute the next task, a sacrifice is made to current productivity.
>>
>
> I think the term you may be looking for is "analysis paralysis
> ".  It's not a perfect
> fit, but it seems reasonably close to what you're describing.  It's good to
> have a limited number of people in any particular organization focused on
> planning out "the next thing", but it takes a lot of skill on *everyone's* 
> part
> to ensure that the presence of that focus doesn't lead to organizational
> analysis paralysis.
>
> Rob
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

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

[Rob Lanphier]

On Fri, Sep 4, 2015 at 1:27 PM, Max Binder  wrote:

> The future tasks matter, but so do the current tasks, and yet in order to
> execute the next task, a sacrifice is made to current productivity.
>

I think the term you may be looking for is "analysis paralysis
".  It's not a perfect
fit, but it seems reasonably close to what you're describing.  It's good to
have a limited number of people in any particular organization focused on
planning out "the next thing", but it takes a lot of skill on *everyone's* part
to ensure that the presence of that focus doesn't lead to organizational
analysis paralysis.

Rob
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

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

[Max Binder]

Clarification:

When I get into "busy mode" I always focus and give priority to the future
> task. It's about getting through the whole day as opposed to focusing on
> the task at hand. So not exactly context switching, and not exactly tunnel
> vision--something in between both.
>
> It's the feeling of constantly saying "I have five minutes to do this and
> as soon is this is over, I'll have seven minutes to do this next thing, and
> I can begin prepping for that by doing x instead of y."
>
> I'm blind to what's going on because I have to focus on what is going to
> happen.
>
> It stresses me out instead of making me feel like I'm accomplishing
> anything.
>

I paraphrased it as "you focus less on the current task because the next
task is always distracting you."

I looked up "short termism" and I think it is kind of like the opposite of
that. Where "short termism" is essentially sacrificing long term for short
term gain (tech debt), this is sacrificing short term "presentness" by
context-switching on future tasks (not current ones).

Relatedly, speedy meeetings FTW.

"The thick of thin things" is also related, focusing on prioritizing, but
I'm not sure it's quite what this is.



On Fri, Sep 4, 2015 at 9:33 AM, Kevin Smith  wrote:

> It doesn't sound the same as Endless Deathmarch, but I don't feel like I
> really understand the question yet. Can you elaborate on "always prepping
> for the next thing" aka "future blindness"?
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Thu, Sep 3, 2015 at 4:43 PM, Max Binder  wrote:
>
>> A question came to me from a friend, and I thought I'd pose it here for
>> discussion:
>>
>> Question for a scrum master: I know you call "multi-tasking" the far more
>>> accurate "context-switching," but do you have a real term for what I can
>>> only call "future blindness"? It isn't exactly tunnel vision that I've been
>>> having because I do think broadly (just not of the present) and my focus
>>> shifts all the time. But this always prepping for the next thing is driving
>>> me into ground. I need to call it something so that I can identify it,
>>> label it, and master it.
>>>
>>
>> Anyone know of any existing term to research? Kevin's kanban "Endless
>> Deathmarch" maybe?
>>
>> ___
>> teampractices mailing list
>> teampractices@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>>
>
> ___
> teampractices mailing list
> teampractices@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices