Re: [teampractices] A tool for keeping action items accountable?

[Quim Gil]

Thank you GuillaumeL for your contributions to this discussion!

On Fri, May 6, 2016 at 9:58 AM, Guillaume Lederrey 
wrote:

> I am naturally suspicious of adding tools in this kind of context.
>

Me too. I was wondering... If the team is taking notes in a document...
what is the problem of documenting in the same doc those small actions that
are either too small or too private for our Phabricator usage?

This is in fact what we do in the Technical Collaboration team, thanks to a
good practice brought by the Community Liaisons. We don't have sprint
retrospectives but we have a weekly meeting, and we record there the
actions that come out of that meeting. Indeed, some tasks won't quite fit
for Phabricator and, as Guillaume says, some tasks are not done a week
later and perhaps even for a good reason.

I think another important factor here is that we use a single document for
all our weekly meetings, as opposed to one document per meeting. This has a
couple of advantages, at least

* The actions we wrote down last week are still there when we use the doc
in the next meeting. If someone missed to complete a task assigned, all
team members can see it clearly.
* Since team members keep visiting the doc after the meeting, sometimes
someone will leave a question or a comment next to an action, and sometimes
that will lead to a small casual discussion or updates about the action.

So perhaps Phabricator + single doc is all you need after all?

-- 
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

Re: [teampractices] A tool for keeping action items accountable?

[Max Binder]

>
> 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).


I've found your feedback valuable and respectful. :)

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.



> 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.
>

I think this is a relevant perspective, and I appreciate you drawing
attention to it. I think there are definitely times when process can be so
strict that it masks the issues it was meant to surface, rather than
surfacing. That may be so, in this case.

It is also true that the team agreed to do the actions identified in the
retro, and subsequently identified that dropping the ball was unacceptable.
I think, like any conversation, context is important, and the tool the team
has identified as a need is not a panacea but an added way to have that
conversation.

On Fri, May 6, 2016 at 1:58 AM, Guillaume Lederrey 
wrote:

> On Thu, May 5, 2016 at 11:21 PM, Max Binder  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 

Re: [teampractices] A tool for keeping action items accountable?

[Kevin Smith]

I always learn something from Guillaume's process emails!

Tasks not being completed would seem to be a subset of a larger issue,
which is that individuals often don't have systems to remind them of what
they need to do. Some people have personal phab boards, some have physical
post-it kanban boards up in their office, some use gcal. Others rely on
memory, random emails, etc.

This discussion has tilted me in the direction of using phab more than we
have, at least in cases where it's reasonable to do so.



Kevin Smith
Agile Coach, Wikimedia Foundation


On Fri, May 6, 2016 at 1:58 AM, Guillaume Lederrey 
wrote:

> On Thu, May 5, 2016 at 11:21 PM, Max Binder  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
> 

Re: [teampractices] A tool for keeping action items accountable?

[Guillaume Lederrey]

On Thu, May 5, 2016 at 11:21 PM, Max Binder  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 

Re: [teampractices] A tool for keeping action items accountable?

[Max Binder]

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).

> 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  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 

Re: [teampractices] A tool for keeping action items accountable?

[Kevin Smith]

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  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" 
> 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  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 
>> 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 

Re: [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" 
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  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 
> 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

Re: [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  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  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

Re: [teampractices] A tool for keeping action items accountable?

[Quim Gil]

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  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

Re: [teampractices] A tool for keeping action items accountable?

[Sarah R]

As FYI, our Wikimedia Team Trello account is sunsetting on May 2. If there
are folks who want to see it live on, please let me know before that
date... :-)


On Tue, Apr 26, 2016 at 6:16 PM, Max Binder  wrote:

> Thanks for clarifying your visceral fear. :)
>
> On Tue, Apr 26, 2016 at 5:48 PM, Bryan Davis  wrote:
>
>> On Tue, Apr 26, 2016 at 6:07 PM, Max Binder 
>> wrote:
>> > On Tue, Apr 26, 2016 at 5:02 PM, Bryan Davis 
>> wrote:
>> >>
>> >> On Tue, Apr 26, 2016 at 5:49 PM, Max Binder 
>> wrote:
>> >> > Someone suggested Trello, since it is lightweight and connects with
>> >> > automation tools like IFTTT. There is concern about using another
>> >> > Phab-like
>> >> > tool, that isn't Phab, at the same time as Phab.
>> >>
>> >> Please, please, please don't bring back use of the Trello zombie. I
>> >> also don't understand at all how Trello is more "light weight" than
>> >> Phab.
>> >
>> > Yea, I think some folks simply prefer one tool to another based on
>> personal
>> > comfort. I don't necessarily have a problem with folks using outside
>> tools
>> > if it makes them more productive, so long as it doesn't
>> >
>> > alienate the team
>> > alienate the volunteers
>> > cause confusion by having multiple sources of truth (especially across
>> > tools)
>> >
>> > Ultimately, the problem I initially posed is probably best solved by
>> > personal accountability. If you like post-its on your wall, great.
>> Notepad
>> > you can cross out? Sure! Trello board for personal tasks? Have at it.
>> The
>> > issue that remains, however, is other folks seeing those to-dos...
>>
>> For personal todo lists I agree that people should use whatever works
>> for them. My (probably uncalled for) anti-Trello outburst was based on
>> the assumption that you were looking for a standard tool and workflow
>> for a WMF team or teams. We picked Phabricator to replace Bugzilla at
>> least in part on the promise that it was a more flexible tool that
>> could replace the ever growing proliferation of task tracking systems
>> that the Foundation was acreeting as each team made personal choices
>> on how to manage their work. This caused a lot of pain for anyone who
>> worked on multiple teams or was just trying to keep track of issues
>> that crossed from team to team.
>>
>> A team using Trello to track retrospective commitments is probably no
>> worse than the current state I would expect of them being bullet
>> points in a google doc somewhere. My visceral fear is that it would be
>> a gateway drug for some teams however to slide back into tracking real
>> projects outside of Phabricator.
>>
>> Bryan
>> --
>> Bryan Davis  Wikimedia Foundation
>> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
>> irc: bd808v:415.839.6885 x6855
>>
>> ___
>> 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
>
>


-- 
Sarah R. Rodlund
Project Coordinator-Engineering, Wikimedia Foundation
srodl...@wikimedia.org
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] A tool for keeping action items accountable?

[Max Binder]

Thanks for clarifying your visceral fear. :)

On Tue, Apr 26, 2016 at 5:48 PM, Bryan Davis  wrote:

> On Tue, Apr 26, 2016 at 6:07 PM, Max Binder  wrote:
> > On Tue, Apr 26, 2016 at 5:02 PM, Bryan Davis 
> wrote:
> >>
> >> On Tue, Apr 26, 2016 at 5:49 PM, Max Binder 
> wrote:
> >> > Someone suggested Trello, since it is lightweight and connects with
> >> > automation tools like IFTTT. There is concern about using another
> >> > Phab-like
> >> > tool, that isn't Phab, at the same time as Phab.
> >>
> >> Please, please, please don't bring back use of the Trello zombie. I
> >> also don't understand at all how Trello is more "light weight" than
> >> Phab.
> >
> > Yea, I think some folks simply prefer one tool to another based on
> personal
> > comfort. I don't necessarily have a problem with folks using outside
> tools
> > if it makes them more productive, so long as it doesn't
> >
> > alienate the team
> > alienate the volunteers
> > cause confusion by having multiple sources of truth (especially across
> > tools)
> >
> > Ultimately, the problem I initially posed is probably best solved by
> > personal accountability. If you like post-its on your wall, great.
> Notepad
> > you can cross out? Sure! Trello board for personal tasks? Have at it. The
> > issue that remains, however, is other folks seeing those to-dos...
>
> For personal todo lists I agree that people should use whatever works
> for them. My (probably uncalled for) anti-Trello outburst was based on
> the assumption that you were looking for a standard tool and workflow
> for a WMF team or teams. We picked Phabricator to replace Bugzilla at
> least in part on the promise that it was a more flexible tool that
> could replace the ever growing proliferation of task tracking systems
> that the Foundation was acreeting as each team made personal choices
> on how to manage their work. This caused a lot of pain for anyone who
> worked on multiple teams or was just trying to keep track of issues
> that crossed from team to team.
>
> A team using Trello to track retrospective commitments is probably no
> worse than the current state I would expect of them being bullet
> points in a google doc somewhere. My visceral fear is that it would be
> a gateway drug for some teams however to slide back into tracking real
> projects outside of Phabricator.
>
> Bryan
> --
> Bryan Davis  Wikimedia Foundation
> [[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
> irc: bd808v:415.839.6885 x6855
>
> ___
> 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

Re: [teampractices] A tool for keeping action items accountable?

[Bryan Davis]

On Tue, Apr 26, 2016 at 6:07 PM, Max Binder  wrote:
> On Tue, Apr 26, 2016 at 5:02 PM, Bryan Davis  wrote:
>>
>> On Tue, Apr 26, 2016 at 5:49 PM, Max Binder  wrote:
>> > Someone suggested Trello, since it is lightweight and connects with
>> > automation tools like IFTTT. There is concern about using another
>> > Phab-like
>> > tool, that isn't Phab, at the same time as Phab.
>>
>> Please, please, please don't bring back use of the Trello zombie. I
>> also don't understand at all how Trello is more "light weight" than
>> Phab.
>
> Yea, I think some folks simply prefer one tool to another based on personal
> comfort. I don't necessarily have a problem with folks using outside tools
> if it makes them more productive, so long as it doesn't
>
> alienate the team
> alienate the volunteers
> cause confusion by having multiple sources of truth (especially across
> tools)
>
> Ultimately, the problem I initially posed is probably best solved by
> personal accountability. If you like post-its on your wall, great. Notepad
> you can cross out? Sure! Trello board for personal tasks? Have at it. The
> issue that remains, however, is other folks seeing those to-dos...

For personal todo lists I agree that people should use whatever works
for them. My (probably uncalled for) anti-Trello outburst was based on
the assumption that you were looking for a standard tool and workflow
for a WMF team or teams. We picked Phabricator to replace Bugzilla at
least in part on the promise that it was a more flexible tool that
could replace the ever growing proliferation of task tracking systems
that the Foundation was acreeting as each team made personal choices
on how to manage their work. This caused a lot of pain for anyone who
worked on multiple teams or was just trying to keep track of issues
that crossed from team to team.

A team using Trello to track retrospective commitments is probably no
worse than the current state I would expect of them being bullet
points in a google doc somewhere. My visceral fear is that it would be
a gateway drug for some teams however to slide back into tracking real
projects outside of Phabricator.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] A tool for keeping action items accountable?

[Bryan Davis]

On Tue, Apr 26, 2016 at 5:49 PM, Max Binder  wrote:
> Someone suggested Trello, since it is lightweight and connects with
> automation tools like IFTTT. There is concern about using another Phab-like
> tool, that isn't Phab, at the same time as Phab.

Please, please, please don't bring back use of the Trello zombie. I
also don't understand at all how Trello is more "light weight" than
Phab.

Bryan
-- 
Bryan Davis  Wikimedia Foundation
[[m:User:BDavis_(WMF)]]  Sr Software EngineerBoise, ID USA
irc: bd808v:415.839.6885 x6855

___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] A tool for keeping action items accountable?

[Max Binder]

A participant in a recent sprint retrospective requested a way to keep
people accountable for action items raised during a retro. Up to this
point, we've been emailing the action items to their stewards, but it's a
lossy process; even if the email is sent, it's not always followed up on.
I'm tasked with researching alternatives. Some ideas:

   - 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.


   - Someone suggested Trello, since it is lightweight and connects with
   automation tools like IFTTT. There is concern about using another Phab-like
   tool, that isn't Phab, at the same time as Phab.


   - Someone suggested looking into Google Reminders, as part of Calendar,
   but assigning the Reminder to the stewards of respective action items. I
   have not seen a way to use this for this purpose.

Thoughts?
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices