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 <[email protected]> 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 <[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 > >
_______________________________________________ teampractices mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/teampractices
