<div dir="ltr">Sorry for the delayed response. Inline:<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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. <br></blockquote><div><br></div><div>Examples:<br><ul><li>Reach out to Team X to see what their OTRS norms are</li><li>Look into gCal To Dos system for process alternatives<br></li><li>Team member A syncs with Team member B and C on travel plans</li><li>Get Team member D access to OTRS</li><li>Forward email about cross-team collaboration to someone outside team</li></ul><p>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.</p><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>Is it fair to assume that most actions coming out of a sprint retrospective will have impact on the team? <br></div></blockquote><div><br></div><div>Yes<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">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.</blockquote><div><br></div><div>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. <br><br>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.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div>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.</div></blockquote><div><br></div><div>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.<br><br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">The usual rule we put in place with our teams was: "A retrospective<br>
action must have a fairly limited scope and be possible to implement<br>
before the next retrospective". Larger items are not considered to be<br>
retrospective actions, but might be put into the team backlog. Action<br>
items are the responsibility of their owner (if we can't find an owner<br>
for the action, the action is dropped). The facilitator responsibility<br>
is to check the status of those actions at the next retro. If those<br>
actions have not been completed by the next retro, they are either<br>
dropped (if we did not make progress, they are probably not as<br>
important as we thought), converted as backlog item (they were larger<br>
than we initially thought), or kept as action item for the next retro<br>
(rare case).</blockquote><div><br></div><div>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). <br></div></div></div></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><p>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. <br><br></p></blockquote><div>I think this is one possible solution. It does put added burden on the facilitator, for better or worse. <br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><p>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". </p></blockquote><div>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.<br></div><div> </div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 28, 2016 at 1:25 PM, Kevin Smith <span dir="ltr"><<a href="mailto:ksmith@wikimedia.org" target="_blank">ksmith@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>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. <br><br></div>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. <br><br></div>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. <br><br><br></div>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". <br><span class="HOEnZb"><font color="#888888"><br></font></span></div><div class="gmail_extra"><span class="HOEnZb"><font color="#888888"><br clear="all"><div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888"><br>Kevin Smith<br>Agile Coach, Wikimedia Foundation<br></font></span><font><font><i><font color="#888888"><br></font></i></font></font></div></div></div></div></div></div></div></div></div></font></span><div><div class="h5">
<br><div class="gmail_quote">On Wed, Apr 27, 2016 at 1:23 PM, Greg Grossmeier <span dir="ltr"><<a href="mailto:greg@wikimedia.org" target="_blank">greg@wikimedia.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">That's basically how we do it in releng during our meetings.</p>
<p dir="ltr">--<br>
Sent from my phone, please excuse brevity.</p><div><div>
<div class="gmail_quote">On Apr 27, 2016 10:20 AM, "Guillaume Lederrey" <<a href="mailto:glederrey@wikimedia.org" target="_blank">glederrey@wikimedia.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In another life, I have been facilitating a few retrospectives. Not<br>
here yet, so the context is probably different and this past<br>
experience probably does not apply without the necessary amount of<br>
tweaking. Still:<br>
<br>
The usual rule we put in place with our teams was: "A retrospective<br>
action must have a fairly limited scope and be possible to implement<br>
before the next retrospective". Larger items are not considered to be<br>
retrospective actions, but might be put into the team backlog. Action<br>
items are the responsibility of their owner (if we can't find an owner<br>
for the action, the action is dropped). The facilitator responsibility<br>
is to check the status of those actions at the next retro. If those<br>
actions have not been completed by the next retro, they are either<br>
dropped (if we did not make progress, they are probably not as<br>
important as we thought), converted as backlog item (they were larger<br>
than we initially thought), or kept as action item for the next retro<br>
(rare case).<br>
<br>
With those rules, we don't rely on specific tools...<br>
<br>
No idea how this applies at WMF...<br>
<br>
<br>
On Wed, Apr 27, 2016 at 9:55 AM, Quim Gil <<a href="mailto:qgil@wikimedia.org" target="_blank">qgil@wikimedia.org</a>> wrote:<br>
> Could you provide examples of these "action items"? It will help<br>
> understanding the relevance of "non-dev/product" action items coming out of<br>
> (presumably dev/product) sprint retrospectives.<br>
><br>
> This sounds like a matter of threshold:<br>
><br>
> * If an action item is purely personal, then sure, use the purely personal<br>
> tool to deal with it.<br>
> * If an action item has an impact on the team, then use the team tool to<br>
> deal with it, no matter how simple, small, "non-dev/product".<br>
><br>
> Is it fair to assume that most actions coming out of a sprint retrospective<br>
> will have impact on the team?<br>
><br>
> This is where the fear to i.e. bringing back Trello doesn't sound any<br>
> visceral to me, but well justified. Someone starts creating strictly<br>
> personal actions in Trello (Asana, etc), they continue adding other small<br>
> actions because 'since we are using this tool anyway and I'm writing the<br>
> actions quickly after the meeting'... Three months down the road that<br>
> parallel board has got a life on its own, they start having tasks<br>
> duplicating with the team's tasks in Phabricator, some things fall between<br>
> the cracks...<br>
><br>
> Yes, I know this would not happen to *you* or *your* team (whoever *you*<br>
> are), but looking at our history we have solid reasons to think that this<br>
> will certainly happen to *someone*, and then that will be taken as a<br>
> reference by * someone else* not reading this thread today, and then...<br>
><br>
><br>
><br>
> On Wed, Apr 27, 2016 at 1:49 AM, Max Binder <<a href="mailto:mbinder@wikimedia.org" target="_blank">mbinder@wikimedia.org</a>> wrote:<br>
>><br>
>> The first thought was to use existing Phabricator boards, but the team<br>
>> agreed that Phab was a lot of overhead for reminding folks to follow up on<br>
>> non-dev/product tasks.<br>
><br>
> Why overhead? Creating a minimally acceptable Phabricator task takes one<br>
> title and one project to associate it with. Even a description is optional.<br>
> If that project is #Team-X-Internal-Stuff, then the rest can't be bothered.<br>
><br>
> If the "overhead" concern also (or actually) encompases a concern about lack<br>
> of privacy (i.e. "John to get a headset that actually works in hangouts")<br>
> then you can always request a private space for your team in Phabricator.<br>
><br>
> The public / private aspect is sometimes tangential, sometimes orthogonal in<br>
> these discussions. The test is the following: those suggesting Trello, would<br>
> like to have a public or a private board for this? If privacy is relevant,<br>
> ask for a private space in Phabricator, where all tasks will be integrated<br>
> to personal backlogs and teams workboards, and where privacy settings of<br>
> tasks can be modified, being all of them available in the same tool.<br>
><br>
> --<br>
> Quim Gil<br>
> Engineering Community Manager @ Wikimedia Foundation<br>
> <a href="http://www.mediawiki.org/wiki/User:Qgil" rel="noreferrer" target="_blank">http://www.mediawiki.org/wiki/User:Qgil</a><br>
><br>
> _______________________________________________<br>
> teampractices mailing list<br>
> <a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.org</a><br>
> <a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
><br>
<br>
<br>
<br>
--<br>
Guillaume Lederrey<br>
Operations Engineer, Discovery<br>
Wikimedia Foundation<br>
<br>
_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
</blockquote></div>
</div></div><br>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org" target="_blank">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
teampractices mailing list<br>
<a href="mailto:teampractices@lists.wikimedia.org">teampractices@lists.wikimedia.org</a><br>
<a href="https://lists.wikimedia.org/mailman/listinfo/teampractices" rel="noreferrer" target="_blank">https://lists.wikimedia.org/mailman/listinfo/teampractices</a><br>
<br></blockquote></div><br></div>