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