[teampractices] A tool for keeping action items accountable?

Fri May 6 07:58:29 UTC 2016

On Thu, May 5, 2016 at 11:21 PM, Max Binder <mbinder at wikimedia.org> wrote:
> Sorry for the delayed response. Inline:
>
>> 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.
>
>
> Examples:
>
> Reach out to Team X to see what their OTRS norms are
> Look into gCal To Dos system for process alternatives
> Team member A syncs with Team member B and C on travel plans
> Get Team member D access to OTRS
> Forward email about cross-team collaboration to someone outside team
>
> Hopefully that provides some context? Folks on some of the teams represented
> above have felt that it's too cumbersome or it's inappropriate to document
> some of these tasks in Phabricator backlogs/release boards/sprint boards.
>>
>> Is it fair to assume that most actions coming out of a sprint
>> retrospective will have impact on the team?
>
>
> Yes
>
>> 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.
>
>
> The overhead is relative. Right now, teams enjoy the ease that comes with
> checking a retro-followup email, or a list in a Google Doc or Etherpad.
> Obviously, in some cases, this is not enough to actually ensure the task
> gets done. Phabricator, like most task-tracking systems, can be a little
> overkill when it comes to tracking these simpler tasks. JIRA, for example
> would be pretty heavy for reminding someone to talk to someone else before
> the next bi-weekly retro.
>
> Ultimately, the default solutions are A) the status quo of list/email
> (simple, lossy), or B) the existing task-tracker, like Phab (in-process,
> cumbersome). The teams are looking for more middle ground.
>
>> If the "overhead" concern also (or actually) encompasses 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.
>
>
> Thank you for pointing that out. I do think some component of this is
> privacy, so in the event that a team feels good about using Phabricator for
> sensitive tasks, it's good to know they can.
>
>> 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).
>
>
> Thanks for this description, Guillaume. In my experience, at least with Team
> Practices, is that most if not all retros follow these guidelines. The issue
> being encountered is that assigned actions are not getting done because
> there is a lack of accountability/transparency/nagging (systematized or
> otherwise).

What I probably did not put enough emphasis on is that in our context,
we tried not the see uncompleted retrospective actions as a failure,
but as an indicator of a deeper malfunction. I am naturally suspicious
of adding tools in this kind of context. I usually try to take the
starting position as "the people did their best" (I don't like the
Prime Directive [1] in itself, for the same reasons as Martin Fowler,
but I like the principles behind it. What I found is that in most
cases, if people did not complete their actions, it is usually for
good reason, or at least good reasons in their context. More urgent
things, not understanding the importance of the task, the task being
actually less important than first thought, the task being more
complex than first thought (so its "ROI" being less than first
expected), or plenty of other things. Nagging people, or putting in
place a process or tool to make sure we complete whatever action was
taken during a retrospective tend to work and make people complete
their actions. In that process, we loose the natural feedback of
dropping tasks.

Putting in place a process / tool sounds like addressing the first
cause in the causality chain. Digging deeper will probably lead to
interesting discoveries. The 5 Whys [2] is again an exercise that I
profoundly dislike (for reasons I can get into in another thread if
you'd like), but again, its premises are interesting. The digger you
dig, the higher the reward...

And usual disclaimer, I'm mainly talking about my personal experience
here. I don't know enough of the specific context to know if it
applies in your situation as well. For all I know, you probably
already have digged deep enough in your causality chain and me telling
you that tools are not the issue is just me being pedantic and
unhelpful (if that's the case, please accept my apologies).

[1] http://martinfowler.com/bliki/PrimingPrimeDirective.html
[2] https://en.wikipedia.org/wiki/5_Whys

>>
>> Recently, I have started to create a calendar event for myself at the
>> midpoint between retros (at about the 2 week mark). At that point, I email a
>> reminder to action item owners. I don't yet know whether this is
>> appreciated, and/or if it will help increase the rate of action items being
>> completed.
>>
> I think this is one possible solution. It does put added burden on the
> facilitator, for better or worse.
>>
>> Once someone owns an action item, I trust them to create a phab task, or
>> not, as they see fit. Often the action item is "Create a phab task for X",
>> and adding a task to create another task would be silly. I think most action
>> items are along the lines of "Convene a meeting about X", or "Discuss X with
>> Y".
>
> Yes, if the action is to create a task, it is explicitly that, and it would
> be redundant, as you say, to create a task to create a task. Most action
> items, as exampled above, are also as stated inline.
>
>
> On Thu, Apr 28, 2016 at 1:25 PM, Kevin Smith <ksmith at wikimedia.org> wrote:
>>
>> As a facilitator of (monthly) retrospectives for Discovery, shortly after
>> the meeting I have emailed an "action items" reminder to anyone who was
>> assigned one. Typically that's a few days after, at the same time the notes
>> get put on wiki. Then, during the following retrospective, we start off by
>> reviewing the status of previous action items. Similar to what Guillaume
>> described, but a bit lighter.
>>
>> Recently, I have started to create a calendar event for myself at the
>> midpoint between retros (at about the 2 week mark). At that point, I email a
>> reminder to action item owners. I don't yet know whether this is
>> appreciated, and/or if it will help increase the rate of action items being
>> completed.
>>
>> If I create the retro etherpad/google doc a few days before the next
>> retro, I might send yet another email reminder to action item owners. But
>> I'm not committing to that.
>>
>>
>> Once someone owns an action item, I trust them to create a phab task, or
>> not, as they see fit. Often the action item is "Create a phab task for X",
>> and adding a task to create another task would be silly. I think most action
>> items are along the lines of "Convene a meeting about X", or "Discuss X with
>> Y".
>>
>>
>>
>> Kevin Smith
>> Agile Coach, Wikimedia Foundation
>>
>>
>> On Wed, Apr 27, 2016 at 1:23 PM, Greg Grossmeier <greg at wikimedia.org>
>> wrote:
>>>
>>> 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
>>>
>>>
>>> _______________________________________________
>>> teampractices mailing list
>>> teampractices at lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>>
>>
>>
>> _______________________________________________
>> teampractices mailing list
>> teampractices at lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>
>
> _______________________________________________
> teampractices mailing list
> teampractices at lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/teampractices
>

-- 
Guillaume Lederrey
Operations Engineer, Discovery
Wikimedia Foundation