[teampractices] A tool for keeping action items accountable?

[Guillaume Lederrey]

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