<div dir="ltr"><div><div>I always learn something from Guillaume's process emails!<br><br></div>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. <br><br></div>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. <br><br></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><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>
<br><div class="gmail_quote">On Fri, May 6, 2016 at 1:58 AM, Guillaume Lederrey <span dir="ltr"><<a href="mailto:glederrey@wikimedia.org" target="_blank">glederrey@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 class="HOEnZb"><div class="h5">On Thu, May 5, 2016 at 11:21 PM, Max Binder <<a href="mailto:mbinder@wikimedia.org">mbinder@wikimedia.org</a>> wrote:<br>
> Sorry for the delayed response. Inline:<br>
><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>
><br>
> Examples:<br>
><br>
> Reach out to Team X to see what their OTRS norms are<br>
> Look into gCal To Dos system for process alternatives<br>
> Team member A syncs with Team member B and C on travel plans<br>
> Get Team member D access to OTRS<br>
> Forward email about cross-team collaboration to someone outside team<br>
><br>
> Hopefully that provides some context? Folks on some of the teams represented<br>
> above have felt that it's too cumbersome or it's inappropriate to document<br>
> some of these tasks in Phabricator backlogs/release boards/sprint boards.<br>
>><br>
>> Is it fair to assume that most actions coming out of a sprint<br>
>> retrospective will have impact on the team?<br>
><br>
><br>
> Yes<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>
><br>
> The overhead is relative. Right now, teams enjoy the ease that comes with<br>
> checking a retro-followup email, or a list in a Google Doc or Etherpad.<br>
> Obviously, in some cases, this is not enough to actually ensure the task<br>
> gets done. Phabricator, like most task-tracking systems, can be a little<br>
> overkill when it comes to tracking these simpler tasks. JIRA, for example<br>
> would be pretty heavy for reminding someone to talk to someone else before<br>
> the next bi-weekly retro.<br>
><br>
> Ultimately, the default solutions are A) the status quo of list/email<br>
> (simple, lossy), or B) the existing task-tracker, like Phab (in-process,<br>
> cumbersome). The teams are looking for more middle ground.<br>
><br>
>> If the "overhead" concern also (or actually) encompasses a concern about<br>
>> lack of privacy (i.e. "John to get a headset that actually works in<br>
>> hangouts") then you can always request a private space for your team in<br>
>> Phabricator.<br>
><br>
><br>
> Thank you for pointing that out. I do think some component of this is<br>
> privacy, so in the event that a team feels good about using Phabricator for<br>
> sensitive tasks, it's good to know they can.<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>
><br>
> Thanks for this description, Guillaume. In my experience, at least with Team<br>
> Practices, is that most if not all retros follow these guidelines. The issue<br>
> being encountered is that assigned actions are not getting done because<br>
> there is a lack of accountability/transparency/nagging (systematized or<br>
> otherwise).<br>
<br>
</div></div>What I probably did not put enough emphasis on is that in our context,<br>
we tried not the see uncompleted retrospective actions as a failure,<br>
but as an indicator of a deeper malfunction. I am naturally suspicious<br>
of adding tools in this kind of context. I usually try to take the<br>
starting position as "the people did their best" (I don't like the<br>
Prime Directive [1] in itself, for the same reasons as Martin Fowler,<br>
but I like the principles behind it. What I found is that in most<br>
cases, if people did not complete their actions, it is usually for<br>
good reason, or at least good reasons in their context. More urgent<br>
things, not understanding the importance of the task, the task being<br>
actually less important than first thought, the task being more<br>
complex than first thought (so its "ROI" being less than first<br>
expected), or plenty of other things. Nagging people, or putting in<br>
place a process or tool to make sure we complete whatever action was<br>
taken during a retrospective tend to work and make people complete<br>
their actions. In that process, we loose the natural feedback of<br>
dropping tasks.<br>
<br>
Putting in place a process / tool sounds like addressing the first<br>
cause in the causality chain. Digging deeper will probably lead to<br>
interesting discoveries. The 5 Whys [2] is again an exercise that I<br>
profoundly dislike (for reasons I can get into in another thread if<br>
you'd like), but again, its premises are interesting. The digger you<br>
dig, the higher the reward...<br>
<br>
And usual disclaimer, I'm mainly talking about my personal experience<br>
here. I don't know enough of the specific context to know if it<br>
applies in your situation as well. For all I know, you probably<br>
already have digged deep enough in your causality chain and me telling<br>
you that tools are not the issue is just me being pedantic and<br>
unhelpful (if that's the case, please accept my apologies).<br>
<br>
<br>
[1] <a href="http://martinfowler.com/bliki/PrimingPrimeDirective.html" rel="noreferrer" target="_blank">http://martinfowler.com/bliki/PrimingPrimeDirective.html</a><br>
[2] <a href="https://en.wikipedia.org/wiki/5_Whys" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/5_Whys</a><br>
<div class="HOEnZb"><div class="h5"><br>
>><br>
>> Recently, I have started to create a calendar event for myself at the<br>
>> midpoint between retros (at about the 2 week mark). At that point, I email a<br>
>> reminder to action item owners. I don't yet know whether this is<br>
>> appreciated, and/or if it will help increase the rate of action items being<br>
>> completed.<br>
>><br>
> I think this is one possible solution. It does put added burden on the<br>
> facilitator, for better or worse.<br>
>><br>
>> Once someone owns an action item, I trust them to create a phab task, or<br>
>> not, as they see fit. Often the action item is "Create a phab task for X",<br>
>> and adding a task to create another task would be silly. I think most action<br>
>> items are along the lines of "Convene a meeting about X", or "Discuss X with<br>
>> Y".<br>
><br>
> Yes, if the action is to create a task, it is explicitly that, and it would<br>
> be redundant, as you say, to create a task to create a task. Most action<br>
> items, as exampled above, are also as stated inline.<br>
><br>
><br>
> On Thu, Apr 28, 2016 at 1:25 PM, Kevin Smith <<a href="mailto:ksmith@wikimedia.org">ksmith@wikimedia.org</a>> wrote:<br>
>><br>
>> As a facilitator of (monthly) retrospectives for Discovery, shortly after<br>
>> the meeting I have emailed an "action items" reminder to anyone who was<br>
>> assigned one. Typically that's a few days after, at the same time the notes<br>
>> get put on wiki. Then, during the following retrospective, we start off by<br>
>> reviewing the status of previous action items. Similar to what Guillaume<br>
>> described, but a bit lighter.<br>
>><br>
>> Recently, I have started to create a calendar event for myself at the<br>
>> midpoint between retros (at about the 2 week mark). At that point, I email a<br>
>> reminder to action item owners. I don't yet know whether this is<br>
>> appreciated, and/or if it will help increase the rate of action items being<br>
>> completed.<br>
>><br>
>> If I create the retro etherpad/google doc a few days before the next<br>
>> retro, I might send yet another email reminder to action item owners. But<br>
>> I'm not committing to that.<br>
>><br>
>><br>
>> Once someone owns an action item, I trust them to create a phab task, or<br>
>> not, as they see fit. Often the action item is "Create a phab task for X",<br>
>> and adding a task to create another task would be silly. I think most action<br>
>> items are along the lines of "Convene a meeting about X", or "Discuss X with<br>
>> Y".<br>
>><br>
>><br>
>><br>
>> Kevin Smith<br>
>> Agile Coach, Wikimedia Foundation<br>
>><br>
>><br>
>> On Wed, Apr 27, 2016 at 1:23 PM, Greg Grossmeier <<a href="mailto:greg@wikimedia.org">greg@wikimedia.org</a>><br>
>> wrote:<br>
>>><br>
>>> That's basically how we do it in releng during our meetings.<br>
>>><br>
>>> --<br>
>>> Sent from my phone, please excuse brevity.<br>
>>><br>
>>> On Apr 27, 2016 10:20 AM, "Guillaume Lederrey" <<a href="mailto:glederrey@wikimedia.org">glederrey@wikimedia.org</a>><br>
>>> wrote:<br>
>>>><br>
>>>> 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">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<br>
>>>> > 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<br>
>>>> > personal<br>
>>>> > tool to deal with it.<br>
>>>> > * If an action item has an impact on the team, then use the team tool<br>
>>>> > 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<br>
>>>> > 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<br>
>>>> > small<br>
>>>> > actions because 'since we are using this tool anyway and I'm writing<br>
>>>> > 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<br>
>>>> > between<br>
>>>> > the cracks...<br>
>>>> ><br>
>>>> > Yes, I know this would not happen to *you* or *your* team (whoever<br>
>>>> > *you*<br>
>>>> > are), but looking at our history we have solid reasons to think that<br>
>>>> > 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<br>
>>>> > then...<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > On Wed, Apr 27, 2016 at 1:49 AM, Max Binder <<a href="mailto:mbinder@wikimedia.org">mbinder@wikimedia.org</a>><br>
>>>> > wrote:<br>
>>>> >><br>
>>>> >> The first thought was to use existing Phabricator boards, but the<br>
>>>> >> team<br>
>>>> >> agreed that Phab was a lot of overhead for reminding folks to follow<br>
>>>> >> up on<br>
>>>> >> non-dev/product tasks.<br>
>>>> ><br>
>>>> > Why overhead? Creating a minimally acceptable Phabricator task takes<br>
>>>> > one<br>
>>>> > title and one project to associate it with. Even a description is<br>
>>>> > optional.<br>
>>>> > If that project is #Team-X-Internal-Stuff, then the rest can't be<br>
>>>> > bothered.<br>
>>>> ><br>
>>>> > If the "overhead" concern also (or actually) encompases a concern<br>
>>>> > about lack<br>
>>>> > of privacy (i.e. "John to get a headset that actually works in<br>
>>>> > hangouts")<br>
>>>> > then you can always request a private space for your team in<br>
>>>> > Phabricator.<br>
>>>> ><br>
>>>> > The public / private aspect is sometimes tangential, sometimes<br>
>>>> > orthogonal in<br>
>>>> > these discussions. The test is the following: those suggesting Trello,<br>
>>>> > would<br>
>>>> > like to have a public or a private board for this? If privacy is<br>
>>>> > relevant,<br>
>>>> > ask for a private space in Phabricator, where all tasks will be<br>
>>>> > integrated<br>
>>>> > to personal backlogs and teams workboards, and where privacy settings<br>
>>>> > 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">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">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>
>>> 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>
>><br>
>><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>
><br>
><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>
<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">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>
</div></div></blockquote></div><br></div>