That's basically how we do it in releng during our meetings. -- Sent from my phone, please excuse brevity. On Apr 27, 2016 10:20 AM, "Guillaume Lederrey" <gleder...@wikimedia.org> wrote:
> In another life, I have been facilitating a few retrospectives. Not > here yet, so the context is probably different and this past > experience probably does not apply without the necessary amount of > tweaking. Still: > > The usual rule we put in place with our teams was: "A retrospective > action must have a fairly limited scope and be possible to implement > before the next retrospective". Larger items are not considered to be > retrospective actions, but might be put into the team backlog. Action > items are the responsibility of their owner (if we can't find an owner > for the action, the action is dropped). The facilitator responsibility > is to check the status of those actions at the next retro. If those > actions have not been completed by the next retro, they are either > dropped (if we did not make progress, they are probably not as > important as we thought), converted as backlog item (they were larger > than we initially thought), or kept as action item for the next retro > (rare case). > > With those rules, we don't rely on specific tools... > > No idea how this applies at WMF... > > > On Wed, Apr 27, 2016 at 9:55 AM, Quim Gil <q...@wikimedia.org> wrote: > > Could you provide examples of these "action items"? It will help > > understanding the relevance of "non-dev/product" action items coming out > of > > (presumably dev/product) sprint retrospectives. > > > > This sounds like a matter of threshold: > > > > * If an action item is purely personal, then sure, use the purely > personal > > tool to deal with it. > > * If an action item has an impact on the team, then use the team tool to > > deal with it, no matter how simple, small, "non-dev/product". > > > > Is it fair to assume that most actions coming out of a sprint > retrospective > > will have impact on the team? > > > > This is where the fear to i.e. bringing back Trello doesn't sound any > > visceral to me, but well justified. Someone starts creating strictly > > personal actions in Trello (Asana, etc), they continue adding other small > > actions because 'since we are using this tool anyway and I'm writing the > > actions quickly after the meeting'... Three months down the road that > > parallel board has got a life on its own, they start having tasks > > duplicating with the team's tasks in Phabricator, some things fall > between > > the cracks... > > > > Yes, I know this would not happen to *you* or *your* team (whoever *you* > > are), but looking at our history we have solid reasons to think that this > > will certainly happen to *someone*, and then that will be taken as a > > reference by * someone else* not reading this thread today, and then... > > > > > > > > On Wed, Apr 27, 2016 at 1:49 AM, Max Binder <mbin...@wikimedia.org> > wrote: > >> > >> The first thought was to use existing Phabricator boards, but the team > >> agreed that Phab was a lot of overhead for reminding folks to follow up > on > >> non-dev/product tasks. > > > > Why overhead? Creating a minimally acceptable Phabricator task takes one > > title and one project to associate it with. Even a description is > optional. > > If that project is #Team-X-Internal-Stuff, then the rest can't be > bothered. > > > > If the "overhead" concern also (or actually) encompases a concern about > lack > > of privacy (i.e. "John to get a headset that actually works in hangouts") > > then you can always request a private space for your team in Phabricator. > > > > The public / private aspect is sometimes tangential, sometimes > orthogonal in > > these discussions. The test is the following: those suggesting Trello, > would > > like to have a public or a private board for this? If privacy is > relevant, > > ask for a private space in Phabricator, where all tasks will be > integrated > > to personal backlogs and teams workboards, and where privacy settings of > > tasks can be modified, being all of them available in the same tool. > > > > -- > > Quim Gil > > Engineering Community Manager @ Wikimedia Foundation > > http://www.mediawiki.org/wiki/User:Qgil > > > > _______________________________________________ > > teampractices mailing list > > teampractices@lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/teampractices > > > > > > -- > Guillaume Lederrey > Operations Engineer, Discovery > Wikimedia Foundation > > _______________________________________________ > 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