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