[teampractices] A tool for keeping action items accountable?

[Greg Grossmeier]

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" <glederrey at 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 <qgil at 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 <mbinder at 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 at lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/teampractices
> >
>
>
>
> --
> Guillaume Lederrey
> Operations Engineer, Discovery
> Wikimedia Foundation
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.wikimedia.org/pipermail/teampractices/attachments/20160427/03dbee38/attachment.html>