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