Re: [teampractices] Distributed Work's Five Levels of Autonomy

[Max Binder]

Thanks, Nemo! Interesting stuff.

On Sat, Apr 18, 2020 at 12:51 AM Federico Leva (Nemo) 
wrote:

> Quite nice article from Matt of Automattic/Wordpress:
> https://ma.tt/2020/04/five-levels-of-autonomy/
>
> Federico
>
> ___
> 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] Continuous retro

[Max Binder]

Thanks for your perspective, Stephane. Some of the teams I currently work
with do keep what we call "living documentation" for retros. What that
means in practice is that they add topics to a shared document, as the
topics occur to them, and then we review them at a regular cadence. If we
don't get to all the topics, we either schedule additional time or save the
topics for the next cycle. The idea is to A) capture ideas so we don't lose
them, and B) use more time in the regular meeting for conversation, instead
of idea-generation. Maybe that's the closest we'll get to "continuous"?

On Wed, Jul 4, 2018 at 10:48 AM Stephane Bisson 
wrote:

> In my experience using kanban, the "continuous" aspect of many activities
> doesn't mean it's done continuously but on-demand, instead of on a fixed
> schedule. For instance, tasks are added to the "to do" column when there is
> less than X tasks in there instead of being added every Tuesday at 4pm.
>
> Similarly, maybe retro items can be added to the retro board as they occur
> or as people think about them. When there is enough material, a retro
> meeting can be called for people to discuss them face-to-face. I've never
> encountered it but I like the idea.
>
> On Wed, Jul 4, 2018 at 1:25 PM Max Binder  wrote:
>
>> I recently came across the concept of a kanban-style board that serves as
>> an on-going retrospective for a team. Rather than meeting regularly (or per
>> project), a team maintains a board that has columns like "Stop" and "Start"
>> and "Continue" and just looks at it all the time (or when they feel like
>> it, but presumably often), like a working board but for team process only.
>> I like the idea of such a tight feedback loop, but I'm skeptical about this
>> format, too (is it context-switching? Is it as engaging as a face-to-face
>> retro? Will participants feel secure in using it? etc).
>>
>> Does anyone have any experience with doing "continuous retros"? I'd love
>> to hear about it.
>> ___
>> teampractices mailing list
>> teampractices@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/teampractices
>>
>
>
> --
> Stephane Bisson
> 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

[teampractices] Added some activities to Workshop Planning guide

[Max Binder]

I finally got around to documenting some of the activities with which we
experimented at the Readers Web team's latest offsite. You can see them and
more at https://www.mediawiki.org/wiki/Workshop_Planning

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

[teampractices] Looking for a group activity for written communication

[Max Binder]

I'd like to help a team gain awareness around the importance of written
communication, and some of the pitfalls one might encounter vs oral or
face-to-face communication. I can imagine this as a presentation of useful
approaches (plus a lifetime of practice), but I was wondering if anyone
knew of an activity that a small group of people could do (role-play,
worksheets, Madlibz, etc). Something that doesn't involve me droning on,
and gives participants a chance to engage with one another? :)
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [Bay Area] Agile<-->NVC workshop

[Max Binder]

I'd be super down. I'm gonna be out of town until late June, but if he's
willing to do it after that (or even better, is willing to adapt a
remote-friendly version so that more folks can participate) that would be
swell. :)

On Mon, May 7, 2018 at 3:42 PM, Greg Grossmeier  wrote:

> 
> > I can second that this would be a great workshop...and FYI, David
> Chilcott
> > has been a good friend and mentor of mine for more than ten years, and he
> > may be willing to bring this workshop to WMF if people are interested
> and I
> > ask him nicely :)
>
> Yes please! :)
>
> Greg
>
> --
> | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
> | Release Team ManagerA18D 1138 8E47 FAC8 1C7D |
>
> ___
> 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

[teampractices] [Bay Area] Agile<-->NVC workshop

[Max Binder]

I came across this, and lament that I can't attend because it's just what
I've been looking for (and is conveniently close to my neighborhood):

https://www.eventbrite.com/e/foundations-of-effective-communication-strategies-for-challenging-situations-tickets-45606208397

Thought someone here might appreciate it and want to go. I'd welcome a
reportback if you do attend. :)
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Team Canvas: a process for forming (or re-forming) teams

[Max Binder]

Thanks, Kevin. To clarify, is the use of "Working Agreements" in the
"ongoing team norms" sense, or in the, say, offsite facilitation sense? My
gut says the former.

On Thu, Oct 26, 2017 at 2:01 PM, Kevin Smith  wrote:

> Last night, I attended a meetup[1] where we learned about the Team
> Canvas[2] approach to establishing how a team will operate. It roughly
> replaces the "Team Norms" or "Working Agreements" development, and is
> structured as a 2-hour session (or 30 minutes for the abridged "basic"
> version).
>
> Rather than jumping straight to working agreements, the canvas has
> time-boxed segments to have team members share both things about themselves
> individually (e.g. strengths) as well as things about the group (e.g.
> common goals). Within each segment, prompting questions give a structure
> that makes it easy for individuals to participate.
>
> By the time the group gets to the point of listing rules, they have a much
> better shared understanding, so that part goes quickly and smoothly (at
> least in theory).
>
> The work can be done with sticky notes, or electronically. Some tools
> (like Trello) actually include pre-built templates for the Canvas system.
>
> Some tips from the presenter last night:
>
>- It's important for each person to use a different color sticky note,
>so their voice is visually represented in the shared space.
>- Even if the paper output doesn't seem impressive, the shared work
>done by the team is where the real value lies..
>- At least for the "complete" version, an external facilitator is
>important, so all the team members can participate fully.
>- The team should understand the types of conversations that will be
>involved, so they don't freak out when they arrive.
>- However, it's probably better not to share the detailed materials
>with the team in advance--you want their thoughts in the moment, not some
>over-processed watered-down version.
>- It's not just for forming: A team should probably go through the
>exercise again every few months, or when members are added or removed.
>
> I haven't done enough team-forming/charters/norms/working agreements work
> to know how this compares to other systems. But it sounded like something I
> would be interested in trying at some point.
>
> [1] https://www.meetup.com/BeyondAgile/events/243808919/
> [2] http://theteamcanvas.com/
>
>
> Kevin Smith
> Engineering Program Manager, 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

[teampractices] FYI: Phabricator workaround for reverting batch edits

[Max Binder]

As far as I know, there is not an official way to revert a batch change to
tasks. You can, however, capture the "?ids=" part of the URL in the prep
stage of a batch change (and not after, so when in doubt do it). If you
apply that to a Maniphest query, you get the IDs, and can save the query or
the URL for later use.

I just batched 234 tasks for the Reading Web team, and this makes me feel
much safer.
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Empathy vs compassion, when helping others

[Max Binder]

Thanks for the video, Natalia (I also enjoy RSA videos). At the risk of
seeming that I lack compassion (I hope not!), I have some thoughts on it. :)

To me it seems like Brené Brown is conflating empathy with compassion
and/or understanding, and is completely mis-defining sympathy in order to
prop up empathy as a better alternative. (This makes me think this is a
technique for argumentative fallacy, maybe "reverse straw man"? "Begging
the question"?)

Specifically, these are the example conversations she uses for sympathy:

   - "I just had a miscarriage."
  - "At least you know you can get pregnant."
   - "I think my marriage is falling apart."
  - "At least you have a marriage."
   - "John is getting kicked out of school."
  - "At least he is an A-student."

I'm not sure that sounds like sympathy to me (wiktionary defines sympathy
<https://en.wiktionary.org/wiki/sympathy> and empathy as basically the same
thing, where the former is weaker than the latter). Is a silver lining the
defining aspect of sympathy?

In any case, the risk expressed in the article I linked is
<http://greatergood.berkeley.edu/article/item/when_empathy_hurts_compassion_can_heal>
that empathizing can lead to poorer decision-making (bias) and emotional
burnout on the part of the empathizer:

> Negative emotions did not disappear after the loving-kindness training;
> it’s just that the participants were less likely to feel distressed
> themselves. According to Klimecki and her colleagues, this suggests that
> the training allowed participants to stay in touch with the negative
> emotion from a calmer mindset. “Compassion is a good antidote,” says
> Klimecki. “It allows us to connect to others’ suffering, without being too
> distressed.”
>
> The main takeaway is that we can shape our own emotional reactions, and
> can alter the way we feel and respond to certain situations. In other
> words, says Klimecki, “Our emotions are not set in stone.”
>

On Thu, Feb 23, 2017 at 3:09 PM, Natalia Harateh <nhara...@wikimedia.org>
wrote:

> Thanks for sharing, Max! I’ll definitely read the article. If I can add to
> the discussion, here’s a short 2:53 min video explaining empathy in a way
> that resonated with me <https://youtu.be/1Evwgu369Jw>.
>
> TL;DR:
>
> *What is the best way to ease someone's pain and suffering? In this
> beautifully animated RSA Short, Dr Brené Brown reminds us that we can only
> create a genuine empathic connection if we are brave enough to really get
> in touch with our own fragilities.*
>
> On 23 Feb 2017, at 23:53, Max Binder <mbin...@wikimedia.org> wrote:
>
> I ran across an article claiming that empathizing with others on their
> issues can be a slippery slope to bias, or at the very least unnecessary
> absorption of another person's issues and feelings. The article was
> political in nature, so I won't post it, but it did make some claims that I
> thought to research.
>
> That let me to this article on compassion as an alternative to empathy:
> http://greatergood.berkeley.edu/article/item/when_empathy_
> hurts_compassion_can_heal
>
> I can't attest for the reputation of the site linked, but it makes some
> interesting arguments. I thought those arguments might be relevant since we
> often operate in an environment with, and espouse values using, words like
> "empathy."
>
> TL;DR:
>
> we can better cope with others’ negative emotions by strengthening our own
>> compassion skills, which the researchers define as “feeling concern for
>> another’s suffering and desiring to enhance that individual’s welfare.”
>> “Empathy is really important for understanding others’ emotions very
>> deeply, but there is a downside of empathy when it comes to the suffering
>> of others,” says Olga Klimecki, a researcher at the Max Planck Institute
>> for Human Cognitive and Brain Sciences in Germany and the lead author of
>> the study. “When we share the suffering of others too much, our negative
>> emotions increase. It carries the danger of an emotional burnout.”
>>
> ___
> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] NYTimes article on engagement at work

[Max Binder]

Might be a repost, but an interesting guest opinion article from 2014:
https://mobile.nytimes.com/2014/06/01/opinion/sunday/why-you-hate-work.html

Juicy tidbit:

With higher focus, these employees ended up getting more work done in less
> time, left work earlier in the evenings than the rest of their colleagues,
> and reported a much less stressful overall experience during the busy
> season. Their turnover rate was far lower than that of employees in the
> rest of the firm. Senior leaders were aware of the results, but the firm
> didn’t ultimately change any of its practices.



> Partly, the challenge for employers is trust. For example, our study found
> that employees have a deep desire for flexibility about where and when they
> work — and far higher engagement when they have more choice. But many
> employers remain fearful that their employees won’t accomplish their work
> without constant oversight — a belief that ironically feeds the distrust of
> their employees, and diminishes their engagement.
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] How to best track the work within Phabricator Epic tasks

[Max Binder]

Thanks, Mukunda! Good stuff. :)

I try to very gently discourage using herald to tag everything with a
> parent project. It hasn't become a problem yet but ultimately herald rules
> do not scale.


Thanks for the reminder. I definitely guilty of thinking about this stuff
more theoretically sometimes, and it's easy to say "Herald will fix it"
without acknowledging the practical aspects.

When something moves from backlog it can go into a future milestone, the
> current milestone or into the "debt" column for a future tech debt sprint.


I really dig the idea of collecting tasks under a Tech Debt Milestone and
then tackling it when it reaches a certain size. It's sort of like filling
up a bucket with water from a leak, and then emptying it when it reaches
your established limit. Works with existing mountains of debt, too, but I
think it just requires more discipline.

So I would recommend scoping your milestones so that they are limited to
> whatever you feel is a manageable set of tasks that doesn't become
> overwhelming to look at.


An analogy for many things in our line of work. :-D



On Thu, Jan 5, 2017 at 5:27 PM, Mukunda Modell <mmod...@wikimedia.org>
wrote:

>
>
> On Thu, Oct 20, 2016 at 7:42 PM, Max Binder <mbin...@wikimedia.org> wrote:
>
>> For bigger 'epic' tasks, it might be better to collect them together
>>> under a milestone in the parent project.
>>
>>
>> I agree with this. I think for sagas, you can have a whole dedicated
>> project, and for epics, you can have Milestones. If the Milestones are a
>> problem (they don't allow relative prioritization of tasks on the same
>> board, they create #toomanycolumns, etc) then you can create a dedicated
>> Milestone board, and Herald tag everything on that board with the parent
>> project.
>>
>>
> I try to very gently discourage using herald to tag everything with a
> parent project. It hasn't become a problem yet but ultimately herald rules
> do not scale. The herald rules themselves are tedious to create and
> maintain and they are slow for phabricator to process. If we get too many
> herald rules then phabricator will be slow and fixing it will be tedious.
> The overhead is in the range of 10ms to 100ms per herald rule.
>
> I didn't start out to be a naysayer though. I am really replying to to
> share some team practices with the group based on experience with the
> #Scap3 project.
>
> https://phabricator.wikimedia.org/project/board/1449/ is the parent
> project. It could be a sub-project under our team project but it's
> currently a top-level project. The top level workboard is mostly for
> backlog and high-level categorization of the tasks. We have created
> milestones that approximately correspond to quarterly goals. When something
> moves from backlog it can go into a future milestone, the current milestone
> or into the "debt" column for a future tech debt sprint. Further
> prioritization and progress tracking happens within each milestones'
> workboard:
>
> https://phabricator.wikimedia.org/project/subprojects/1449/
>
> We still end up with epic tasks and the phabricator task graph helps with
> those but I think milestones are nice for this sort of thing. Milestones
> could represent any amount of work, not just quarterly goals, however, the
> key advantage in keeping them small is that you can easily see everything
> on one screen. So I would recommend scoping your milestones so that they
> are limited to whatever you feel is a manageable set of tasks that doesn't
> become overwhelming to look at.
>
> The line between manageable and overwhelming is obviously subjective but I
> think it's useful to think of milestones in this way.
>
> Anyway that's my $0.02 about milestones.
>
> Happy Practicing,
> Mukunda
>
>
>> This approach doesn't preclude Epics. Indeed, you'll find yourself with
>> tasks that you didn't realize were as big as they turned out to be, or that
>> get scope creep. That's fine. If that's the case, though, ruthless grooming
>> into dedicated projects and Milestones seems appropriate.
>>
>> Regardless, it seems like all of these approaches benefit from having
>> someone who pays attention to the growing task list and constantly sorts
>> and prioritizes.
>>
>> On Wed, Oct 12, 2016 at 12:47 AM, Mukunda Modell <mmod...@wikimedia.org>
>> wrote:
>>
>>> For tasks with many tiny subtasks, I choose to outline them in the
>>> description and avoid creating separate subtasks.
>>>
>>> For bigger 'epic' tasks, it might be better to collect them together
>>> under a milestone in the parent project.
>>>
>>> For tasks with several interdepe

Re: [teampractices] Supporting collaboration through neuroscience

[Max Binder]

I found this information very familiar, and like to see it spelled out (and
especially appreciate the summaries you both emailed); it's like finding a
Wikipedia article about that thing you know or discovered and realizing
you're not alone in your thoughts/approaches/the universe.

I wonder if this could be an effective opener to an offsite (or similar
facilitation experience), along with what I call "Trust Buckets"
(categories of trust, derived from The Trust Equation
)
and "Communications Styles that Bug People
."
Having a group explore, even for 5 minutes, that there are distinct
components to trust, and that their colleagues value the components
differently, is an effective way to, fittingly, build trust and prime the
group for a day of constructive communication. Similarly, showing a group a
list of common communication styles that irritate people, and asking them
to identify what they agree with and what they themselves do, is an
effective way to bring awareness to a group about the underlying things
that contribute to communication challenges.

I think an introduction to the SCARF model, adapted for a 5 minute check-in
or exercise, could be useful for priming a group for self-awareness ahead
of deeper conversations with one another. If you wanted to put this entire
idea into meta-SCARF terms, I'd venture that a SCARF check-in would be an
example of increasing Relatedness ("you might feel this way while
communicating, because many people's brains tend to follow this
structure"), and Autonomy and Certainty ("now that you're aware of this
model, you can act on what was previously ambiguous in your communication
experience, for your forthcoming communication experience").

Or, as the article put it (and Kristen pointed out already), "For
minimizing threats, knowing about the domains of SCARF helps one to label
and reappraise experiences that might otherwise reduce performance."



On Thu, Oct 13, 2016 at 10:57 AM, Kristen Lans  wrote:

> Thank you for sharing this Arthur. I found the SCARF model to be
> profoundly useful as a frame for understanding some of the dynamics at play
> in my day to day work. For example, based on this model, I can see why some
> facilitation techniques I use reliably work well (by helping to equalize
> Status and increase Certainty), and why it’s sometimes difficult to think
> straight when interacting with people in positions of authority (Status
> threat!).
>
> In a world where we may be unwittingly going around triggering each
> others’ basic survival responses and jamming up our cognitive functioning,
> it becomes more clear why collaboration can be so difficult at times. It’s
> also heartening to understand some ways that we can create better work
> environments by reducing threats and increasing rewards.
>
> The notion of creating a less socially threatening work environment
> brought to mind the NY Times article about what Google learned about
> successful teams
> 
> (shared on this list in February: “[teampractices] [FYI] connection between
> great teams and psychological safety”). While I found the Times article
> incredibly interesting, the conclusion that establishing “psychological
> safety” is the key to great teams left me hanging a bit. To me the, the
> SCARF paper bridged the gap between “psychological safety is a good thing
> for teams!” and “...and here’s some practical ways to lay the foundations
> for establishing that safety”. Indeed, I went back and read the Times
> article with the SCARF frame in mind, and found the concepts presented in
> both works to be complementary.
>
> I found myself wondering about the relative importance of the domains (S,
> C, A, R, and F) to individuals. I’ve seen early career individuals calmly
> and casually pitching their ideas to executives with seemingly no
> sensitivity to Status, but spiraling into self-destructive behavior when
> their sense of Fairness is threatened. It looks like the SCARF paper
> authors wonder about this as well (“Do people vary in the importance of the
> 5 domains, and if so are there patterns across men and women, age groups or
> cultures?” (p.8)). I also wonder how this model applies across the range of
> neurodiversity.
>
> Anyway, lots of good juicy stuff here! Here are some of my favorite quote
> nuggets from the pdf of the article:
>
> On Status:
>
> “It can be surprisingly easy to accidentally threaten someone’s sense of
> status. A status threat can occur through giving advice or instructions, or
> simply suggesting someone is slightly ineffective at a task. Many everyday
> conversations 

Re: [teampractices] My experience at Agile Games West 2016

[Max Binder]

; ("Divinity") that has similar core mechanisms to Fluxx. If I buy it, maybe
>> I'll bring it to a TPG event to try.
>>
>> Like Arthur, I want to hear more about the sorting hat. At a glance, it
>> reminds me of the old (apparently misnamed) "Bayesian" email spam filters I
>> played around with years ago. Or more generally, neural networks, I
>> suppose. In an odd twist where the brain ends up simulating a simulation of
>> a brain. When reviewing code, I often describe it in terms of feelings or
>> odd sensations that something is out of place, even if I can't quite
>> identify the specific offense. Fortunately, with more analysis, the
>> true/objective cause usually becomes clear.
>>
>>
>>
>>
>>
>> Kevin Smith
>> Agile Coach, Wikimedia Foundation
>>
>>
>> On Thu, Oct 13, 2016 at 5:48 PM, Arthur Richards <aricha...@wikimedia.org
>> > wrote:
>>
>>> Thanks for sharing this Max, sounds like an interesting few sessions.
>>> Would love to hear more about 'the sorting hat'!
>>>
>>> On Thu, Oct 13, 2016 at 6:09 AM Max Binder <mbin...@wikimedia.org>
>>> wrote:
>>>
>>>> I recently attended a "pre-conference" to Agile Open California. I
>>>> wrote up my experience and posted it on the Team Practices Group MediaWiki
>>>> page:
>>>> https://www.mediawiki.org/wiki/Team_Practices_Group/Agile_Games_West
>>>> ___
>>>> 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
>>>
>>>
>>
>> ___
>> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] My experience at Agile Games West 2016

[Max Binder]

I recently attended a "pre-conference" to Agile Open California. I wrote up
my experience and posted it on the Team Practices Group MediaWiki page:
https://www.mediawiki.org/wiki/Team_Practices_Group/Agile_Games_West
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] FYI: Phabricator workaround for manually selecting tasks to bulk-edit

[Max Binder]

As far as I know, you could always Batch Edit from the Maniphest query page.

https://phabricator.wikimedia.org/maniphest/query/advanced/

Then just search for what you want. In your example for a workboard, you
would search for the workboard's title  (rather than hacking the URL). So,
if I want to Batch Edit tasks on the Team-Practices board, I'd do a
Maniphest query for Tags = Team-Practices, then Batch Edit the results, as
selected.

The real gem that you surfaced is selective Batch Editing tasks in a
column, since you can't do a Maniphest query for columns, and even when you
Batch Edit a column via the column dropdown, you can't deselect tasks.
Super useful.

Of course, if you're a not a member of Triagers
, you can't Batch Edit,
anyway. :)

Potential use cases: bulk editing in triage, bulk estimation,
> recategorizing lots of tasks at once, etc.
>

Batch editing hasn't really been updated as new Phab features have been
introduced, so newer things like Story Points (estimation) are not an
option.



On Thu, Oct 6, 2016 at 3:29 PM, Kevin Smith  wrote:

> Cool! Can you (Joel) add it to our phab docs, so I'll be able to find it
> later, if/when I need it? (If not, hopefully someone else will.)
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Thu, Oct 6, 2016 at 5:35 PM, Joel Aufrecht 
> wrote:
>
>> I saw this workaround in passing (Upstream T11286#184572
>> ) and wanted to highlight
>> it.  If you want to batch-edit some but not all tasks in a column or
>> workboard, there is a way to get shift-click power to select and deselect
>> individual items.
>>
>>1.
>>
>>Navigate to the board you want to batch-edit
>>2.
>>
>>At the top of the column on the board that you want to batch-edit,
>>click the dropdown arrow and then Batch Edit Tasks...
>>3.
>>
>>Hack the URL.  From
>>1.
>>
>>   http://local.phacility.com/maniphest/batch/?board=117=
>>   274%2C250%2C265
>>   2.
>>
>>   ...replace batch/?board=X= with ?ids=
>>   3.
>>
>>   http://local.phacility.com/maniphest/?ids=274%2C250%2C265
>>   4.
>>
>>Click Select All at the bottom of the list.
>>5.
>>
>>Shift-click tasks to deselect.
>>
>> When done deselecting, click Batch Edit Selected at the bottom of the
>> list.
>>
>> This also works for all of the tasks on a board (click the *Manage* gear
>> icon at the top right of the board, then *Batch Edit Visible Tasks...*),
>> but all of the columns are collapsed into the single query result list so
>> it's not as useful a workaround.
>>
>> Potential use cases: bulk editing in triage, bulk estimation,
>> recategorizing lots of tasks at once, etc.
>>
>>
>>
>> *-- Joel Aufrecht*
>> Team Practices Group
>> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [LOLZ] Fwd: [Phabricator] Password Reset

[Max Binder]

While this thread was initially inspired by the feelings so accurately
captured by Picard and Riker, there is another observation that I feel is
worth acknowledging.

As a global entity, the Wikimedia movement is often challenged by
communication across diverse cultures, languages, and the realities of
gender dynamics and history, among a plethora of other diversity-related
considerations that are too numerous to list exhaustively here. Simply put,
that often means that someone from one part of the world might not
understand someone from another, and that is too often exacerbated by
idiomatic language (to say nothing of my own verbosity here).

This holds especially true online, where non-verbal communication lacks the
nuance of a face-to-face encounter. The movement is concerned with
broadening the sharing of information, and shared understanding. It's easy
to see how that can be especially difficult with the challenges described.

Inside jokes are fun, and often harmless (or better yet, provide
opportunities to bond). They can also, to quote a colleague who helped me
think through this, "perpetuate an exclusive vs inclusive experience." In
this case, the joke assumes that everyone knows the best practice that
passwords should not be simple and should not be written down. In
discussing this with another colleague who helped me figure out what I was
trying to articulate, the following was put to my attention, from the ongoing
draft of the Code of Conduct for technical spaces
:

"Technical skills and community status make no difference to the right to
be respected and the obligation to respect others. Newcomers and other
contributors with limited experience in our community deserve a welcoming
attitude and constructive feedback. Prolific contributions and technical
expertise are not a justification for lower standards of behavior."

At the very least, as yet another insightful colleague put it, the
inconsistency of language in a UI can cause added cognitive load when using
the product. At worst, things like the text in the standard Phabricator
password-reset email can create a distancing user experience for those
unfamiliar with the space from which the Phacility team is coming. I wanted
to make sure that that reality was acknowledged, particularly given the
space in which the Wikimedia movement operates.



On Fri, Sep 30, 2016 at 12:34 AM, Prateek Saxena 
wrote:

> They moved the fun stuff to https://www.phacility.com/phabricator/ it
> seems.
>
> On Fri, Sep 30, 2016 at 12:56 PM, Željko Filipin 
> wrote:
> > On Thu, Sep 29, 2016 at 8:27 PM, Greg Grossmeier 
> wrote:
> >>
> >> Yeah, take a look at phabricator.com, a bit different style of humor,
> but
> >> they're consistent :)
> >
> >
> > As far as I remember, their home page had several jokes. Looks like they
> > went all serious and corporate recently, there is just one link to
> pokemon
> > site. :|
> >
> > https://phacility.com/
> >
> > Željko
> >
> > ___
> > 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
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] [LOLZ] Fwd: [Phabricator] Password Reset

[Max Binder]

I'm pretty sure this is meant as a joke...

My mother always taught me to make strong, hard-to-guess passwords and
avoid sticking them on my monitor.

-- Forwarded message --
From: 
Date: Thu, Sep 29, 2016 at 10:16 AM
Subject: [Phabricator] Password Reset
To: mbin...@wikimedia.org


Condolences on forgetting your password. You can use this link to reset it:

[link]

After you set a new password, consider writing it down on a sticky note and
attaching it to your monitor so you don't forget again! Choosing a very
short, easy-to-remember password like "cat" or "1234" might also help.

Best Wishes,
Phabricator
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Google Calendar Gadget for tracking total weekly hours

[Max Binder]

https://www.gtimereport.com/Home/Export

or

https://www.gcal2excel.com/

maybe. I'm mostly looking for something dynamic that I can see at a glance.
I've thought about digging into the source code for gadget, might just...

On Fri, Sep 23, 2016 at 4:45 PM, Kevin Smith <ksm...@wikimedia.org> wrote:

> If there is a tool to dump a week's worth of my calendar into a text file,
> I could write a ruby script that would give me some cool (and hopefully
> valuable) insights. I haven't looked to see if such a tool is available,
> but I would guess there probably is.
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Fri, Sep 23, 2016 at 4:34 PM, Joel Aufrecht <jaufre...@wikimedia.org>
> wrote:
>
>> I've been experimenting with several different tools to track my own time
>> usage, and ... it's really really hard to do it consistently enough, and
>> report on it often enough, to get any value at all out of it.
>>
>>
>>
>> *-- Joel Aufrecht*
>> Team Practices Group
>> Wikimedia Foundation
>>
>> On Fri, Sep 23, 2016 at 4:26 PM, Kevin Smith <ksm...@wikimedia.org>
>> wrote:
>>
>>> Source code to the gadget is available, and looks pretty simple. I think
>>> it would be quick to change the logic from creating a new bucket for every
>>> unique title to doingsomething else. Just need to figure out what that
>>> "something" is.
>>>
>>> Personally, I would like to have about 6 buckets. People who color-code
>>> their types of meetings might want a bucket per color. It sounds like Max
>>> just wants One Big Bucket(tm), which would be easiest of all.
>>>
>>>
>>> Kevin Smith
>>> Agile Coach, Wikimedia Foundation
>>>
>>>
>>> On Thu, Sep 22, 2016 at 2:58 PM, Max Binder <mbin...@wikimedia.org>
>>> wrote:
>>>
>>>> Recently, I thought it would be nice to have a lightweight tool for
>>>> showing me how many hours per week I am in meetings. I found this:
>>>> https://sites.google.com/site/weeklytimecounts/
>>>>
>>>> It's not exactly what I'm looking for (it calculates total hours of
>>>> meetings that have the same title), but it's similar. Anyone know of a tool
>>>> that integrates with Google Calendar to calculate the total number of hours
>>>> one is booked? Even more handy might be a tool that shows you the same
>>>> information but for other calendars to which you are subscribed (such as
>>>> teammates).
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>> ___
>> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Saw a presentation by Allen Holub

[Max Binder]

nal
> requirement until the day the project ends (at which point there will be a
> large pile of requirements which were not built).
>
> I agree with McConnell that task estimation is a skill that most
> developers haven't built up, but most could. It's a skill I developed with
> practice, and I have helped a couple other developers build it up as well.
> You'll never get to the point of perfect accuracy, but "good enough"
> estimation is definitely a realistic goal, and can be valuable.
>
> However, I think I disagree with McConnell (and Holub) that *project*
> level estimation (or "projection", as Holub prefers) is easy. New
> requirements can show up in lumps at various times, in addition to some
> tasks being easier or harder than expected. I think that you can accurately
> predict the time, scope, cost, or quality of a project. Probably 2 of those
> for the same project. Certainly not all 4.
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Wed, Sep 21, 2016 at 2:49 PM, Joel Aufrecht <jaufre...@wikimedia.org>
> wrote:
>
>> I skimmed through his #NoEstimates video until I saw burnup charts:
>>
>> https://youtu.be/QVBlnCTu9Ms?t=1616
>>
>> His argument seems to be (and I'm not watching the whole 40 minutes so I
>> could be going out of context) that you can do projections from burnups and
>> use that instead of estimation.  "Now I guess this is estimating but it's
>> not really estimating, all we are doing is counting."
>>
>> It sounds like he's opposed to a particular kind of estimation, in favor
>> of another kind of estimation, and perhaps using a bit of hyperbole as a
>> marketing tool.
>>
>>
>>
>> *-- Joel Aufrecht*
>> Team Practices Group
>> Wikimedia Foundation
>>
>> On Wed, Sep 21, 2016 at 2:38 PM, Joel Aufrecht <jaufre...@wikimedia.org>
>> wrote:
>>
>>> Interesting.  I just finished Steve McConnell's response to
>>> #NoEstimates, 17_Theses_on_Software_Estimation_(Expanded)
>>> <http://www.construx.com/10x_Software_Development/17_Theses_on_Software_Estimation_%28Expanded%29/>
>>> .
>>>
>>> The most essential of those theses might be:
>>>
>>> *5. Estimates serve numerous legitimate, important business purposes.*
>>>>
>>>
>>> ​I think the #NoEstimates response to that is, estimation doesn't work,
>>> so even if estimates would be nice, estimation doesn't actually provide
>>> them.
>>>
>>> McConnell's response is basically, estimation does work if you know what
>>> you're doing and do it right.
>>>
>>> *1. Estimation is often done badly and ineffectively and in an overly
>>>> time-consuming way.*
>>>
>>>
>>>
>>>> *2. The root cause of poor estimation is usually lack of estimation
>>>> skills.*)
>>>>
>>>
>>> And also that Scrum is actually very compatible with estimation, and
>>> that discussions should be pragmatic and not dogmatic:
>>>
>>> *14. Scrum provides better support for estimation than waterfall ever
>>>> did, and there does not have to be a trade off between agility and
>>>> predictability. *
>>>
>>>
>>>
>>>> *16. This is not religion. We need to get more technical and more
>>>> economic about software discussions. *
>>>
>>> ​
>>>
>>> What did he call his burnup charts (charts that, by the way, support
>>> estimation at a glance)?
>>>
>>>
>>>
>>>
>>>
>>> *-- Joel Aufrecht*
>>> Team Practices Group
>>> Wikimedia Foundation
>>>
>>> On Wed, Sep 21, 2016 at 1:29 PM, Max Binder <mbin...@wikimedia.org>
>>> wrote:
>>>
>>>> I attended a Meetup last night, via Bay Area Agile Leadership Network.
>>>>
>>>> Don't have Allen's deck, but here is his website with a lot of the same:
>>>> http://holub.com/
>>>>
>>>> TL;DR: His presentation was about how estimation is bad (among other
>>>> things, he argues that estimating is unethical). I felt it was a fairly
>>>> aggro presentation (full disclosure: I'm pro-estimation), but under the
>>>> veil of what I observed as an extremist view of Agile was a message
>>>> promoting Agile as a state of mind, rather than a
>>>> panacea-by-rigid-structure, all too often deployed by "Agile" companies.
>>>>
>>>> He also showed burnup charts (he didn't call them that) very similar to
>>>> those on phlogiston.wmflabs.org.
>>>>
>>>>
>>>>
>>>> ___
>>>> 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
>>
>>
>
> ___
> 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

[teampractices] Article on prioritizing bugs

[Max Binder]

Via Corey on the iOS team:
https://hackernoon.com/bugs-priority-3b5cf5f6aadd?source=
linkShare-3607e4b9ed19-1473801964


[My copy-pasta from the other thread]
Some things that jumped out at me:

However, often times the criteria for making tradeoffs aren’t made
> explicit, and can be detrimental if not understood by all people involved.


Hopefully the person assigning priority has been clear and open about how
> they are making the decisions, but I’d guess more often than not, it’s a
> mix of gut feeling and maybe, current mood.



>- *What kind of defect? *— The spectrum of defects is very large,
>where does this fall in that spectrum as best as I can see?
>- *What is the frequency of the defect?* — Does this happen every
>time, some times, some times for some users, very infrequently, only when
>the moon is full?
>
> These two variables (and maybe more for your organization) are key in
> decoupling the gut decision from the right decision.


Could this be the right way to keep your collection of bugs, features, and
> the like organized? Maybe, maybe not, it’s really whatever works for your
> organization.
>

I agree that priority is about tradeoffs. I like to treat bugs the same way
as debt and features, in that they should explicitly say why a team should
engage. I think a spectrum for assigning priority, like the one described
in the article, can be useful. I think it's more important (and not
mutually exclusive) to ensure the task clearly states it's value.

If you use a spectrum of *value*, you can apply a similar methodology for
coordinating priority to all work with which the team engages. I think this
is also more flexible, since your rubric for priorities may shift over time
(or suddenly), but clearly describing the value of a task makes it easier
to shift gears on already-prioritized tasks.
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Change the font of incoming Gmails

[Max Binder]

>
> On Firefox, there's also the nuclear option of forcing your default font
> to all websites (Privacy > Contents > Fonts > Advanced > Allow pages to
> choose their own fonts, instead of my selections above). Stylish is nice
> because you can disable custom fonts per-site, IIRC.


Yep, that's the one to which I referred when I said

Firefox has a setting to disallow sites setting unique fonts, via
>
> preferences/content/fonts/advanced


Your explanation is clearer, though. :)

Either way, the Firefox option does not affect incoming Gmail, which is why
I found Stylish to pick up the slack.

On Wed, Aug 24, 2016 at 10:43 PM, Federico Leva (Nemo) <nemow...@gmail.com>
wrote:

> Max Binder, 25/08/2016 00:56:
>
>> The fix I found: a Firefox
>> <https://addons.mozilla.org/en-US/firefox/addon/stylish/> (and Chrome
>> <https://chrome.google.com/webstore/detail/stylish/fjnbnpbmk
>> enffdnngjfgmeleoegfcffe?hl=en>)
>> add-on called Stylish.
>>
>
> On Firefox, there's also the nuclear option of forcing your default font
> to all websites (Privacy > Contents > Fonts > Advanced > Allow pages to
> choose their own fonts, instead of my selections above). Stylish is nice
> because you can disable custom fonts per-site, IIRC.
>
> Nemo
>
>
> ___
> 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

[teampractices] Change the font of incoming Gmails

[Max Binder]

Recently, this list had a thread for what email fonts are easier to read,
based on the following article:
http://www.bloomberg.com/news/articles/2015-07-27/your-e-mail-font-is-ruining-your-life

I tried it, it didn't work for me (I like consistent fonts), but I was
dismayed to discover that, when others did keep the change, I couldn't
change incoming email fonts to control my own user experience. Firefox has
a setting to disallow sites setting unique fonts, via

preferences/content/fonts/advanced

but that doesn't affect Gmail incoming messages.

The fix I found: a Firefox
 (and Chrome
)
add-on called Stylish. That, coupled with a few tweaks to an existing
community-created style
, allowed me
to revert incoming fonts to "Sans Serif" (Google's vanity name for
"Arial"). This also keeps things like italics and bold and all those
goodies we like to use for emphasis.

Here's the code from that tweak:

@-moz-document domain("mail.google.com"), domain("inbox.google.com") {
> .gmail_default{
> font-size:13px!important;
> font-family:"arial",sans serif !important;
> }
> .adO.adP p,
> .yq,
> .yq *,
> .gs *,
> .b5.xJNT8d *,
> .aV.editable{
> font-size:13px!important;
> line-height:1.6!important;
> font-family:"arial",sans serif !important;
> }
> .gs,
> .b5.xJNT8d,
> .aV.editable{color:#444!important;}
> .oM,
> .Zs,
> .gb_Wa.gb_7a.gb_f{
> display:none!important;
> }
> }
>

Happy font'ing :-)
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] W. Edwards Deming - The Deadly Diseases of Management

[Max Binder]

Interesting video, also kind of funny. A bit dated, but some still-relevant
goodies. ~15 minutes.
https://www.youtube.com/watch?v=ehMAwIHGN0Y=youtu.be

Relevant Wikipedia article:
https://en.wikipedia.org/wiki/W._Edwards_Deming#Key_principles
https://en.wikipedia.org/wiki/W._Edwards_Deming#Seven_Deadly_Diseases
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] IT projects almost as prone to overruns as the Olympics

[Max Binder]

http://fivethirtyeight.com/features/hosting-the-olympics-is-a-terrible-investment/



On Mon, Aug 15, 2016 at 2:25 PM, Grace Gellerman 
wrote:

> Thanks, Joel!
>
> For more real world examples see the wikipedia entry for the Planning
> Fallacy .
>
>
> On Mon, Aug 15, 2016 at 1:15 PM, Kevin Smith  wrote:
>
>> I would also be interested in cost overrun comparisons with other
>> *international* projects. I mean, that has to add to the confusion and
>> unpredictability, right?
>>
>> The chunnel came in at 80% over budget, according to wikipedia.
>>
>>
>> Kevin Smith
>> Agile Coach, Wikimedia Foundation
>>
>>
>> On Mon, Aug 15, 2016 at 11:33 AM, Arthur Richards <
>> aricha...@wikimedia.org> wrote:
>>
>>> Fascinating, Joel, thanks for the share!
>>>
>>> On Mon, Aug 15, 2016 at 11:24 AM, Joel Aufrecht >> > wrote:
>>>
 The Olympic Games average 156 percent cost overruns, outdistancing all
> other types of megaprojects. For comparison, road projects average 
> overruns
> of 20 percent; bridges and tunnels 34 percent; energy projects 36 percent;
> rail projects 45 percent; dams 90 percent and IT projects 107 percent.
>

 (according to The Oxford Olympics Study 2016: Cost and Cost Overrun at
 the Game )

 (source
 
 )

>>>
>>> ​Worth noting that the study looked ONLY at sports-related costs and
>>> excluded larger projects (eg infrastructure):
>>>
>>> The numbers cover the period 1960-2016 and include only sports-related
 costs, i.e., wider capital costs for general infrastructure, which are
 often larger than sports-related costs, have been excluded.​
>>>
>>>
>>> ​I am curious what the average overruns would like if all
>>> Olympics-related costs (eg infrastructure, etc) were included.
>>>
>>> --
>>> Arthur Richards
>>> Sr. Agile Coach: Organizational Collaboration
>>> Team Practices Group
>>> 
>>> [[User:Awjrichards]]
>>> IRC: awjr
>>> +1-415-839-6885 x6687
>>>
>>> ___
>>> 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
>>
>>
>
> ___
> 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] IT projects almost as prone to overruns as the Olympics

[Max Binder]

relative to those other projects, yea. That said, 50 percent ain't
nothing. :)

On Mon, Aug 15, 2016 at 11:24 AM, Joel Aufrecht 
wrote:

> The Olympic Games average 156 percent cost overruns, outdistancing all
>> other types of megaprojects. For comparison, road projects average overruns
>> of 20 percent; bridges and tunnels 34 percent; energy projects 36 percent;
>> rail projects 45 percent; dams 90 percent and IT projects 107 percent.
>>
>
> (according to The Oxford Olympics Study 2016: Cost and Cost Overrun at
> the Game )
>
> (source
> 
> )
>
>
>
> *-- Joel Aufrecht*
> Team Practices Group
> 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] 2 interesting articles about design

[Max Binder]

Interesting. I've always read that Sans Serif was better for screens, and
Serif was better for paper, but I'd buy that that was based on old-screen
protocol. The real question is, do you want to be *that person* who has the
funky font in Gmail? (I also wonder what the benefit is if the default is
Sans Serif and there are only a small percentage of folks using an
alternative font. Is it disruptive?)

On Mon, Aug 8, 2016 at 10:28 AM, Joel Aufrecht 
wrote:

> tl;dr from 2.: In GMail, click on *Gear Icon* > *Settings* > *General* > 
> *Default
> Text Style* and change to Georgia.
>
>
>
> *-- Joel Aufrecht*
> Team Practices Group
> Wikimedia Foundation
>
> On Mon, Aug 8, 2016 at 10:15 AM, Grace Gellerman  > wrote:
>
>> 1. ​Charming story about constraints, product requirements, making
>> visible that which would otherwise be invisible, and the role of design:
>>
>> http://www.bbc.com/autos/story/20160804-why-are-trains-seats
>> -so-hideous?utm_source=digg_medium=twitter
>>
>> 2. Recognizing context and the value of design in improving the
>> sustainable pace of work by reducing the waste of fatigue, improving speed
>> of recognition, and designing for humans:
>>
>> http://www.bloomberg.com/news/articles/2015-07-27/your-e-mai
>> l-font-is-ruining-your-life
>>
>> ___
>> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Phabricator terminology change (blocking->subtasks)

[Max Binder]

I know my teams would love to distinguish between subtasks (of tasks with
story points) and children (of epics). I don't think that is possible right
now, so they often use the title prefix "[Subtask]".

On Fri, Jul 1, 2016 at 10:25 AM, Joel Aufrecht 
wrote:

> Should we make (or find and join) a request that they provide a way to
> differentiate between the two cases?  Possible uses:
>
> different display in the UI
> use in data analysis, e.g., summing up tasks by summing up their subtasks
> (and not dependencies)
>
>
>
> *-- Joel Aufrecht*
> Team Practices Group
> Wikimedia Foundation
>
> On Fri, Jul 1, 2016 at 9:56 AM, Kevin Smith  wrote:
>
>> This week, phabricator changed the terminology it uses for managing
>> dependencies between tasks. What has been called "Blocking"/"Blocked by" is
>> now called "Parent"/"Subtask". Ignoring phab terminology for a minute, here
>> are the two basic cases these terms are covering:
>>
>> 1. *Sequential dependencies.* For example, if "Implement feature X"
>> needed to be complete before "Document feature X", then the implementation
>> task would Block the document task, and the document task would be blocked
>> by the implement task.
>>
>> 2. *Composition relationships/task breakdown.* For example, if "deploy
>> feature X" consisted of "implement feature X" and "document feature X",
>> then the deploy task might be a parent, while the implement and document
>> tasks would be subtasks.
>>
>> Until recently, phab has used the blocking/blocked by term to cover both
>> cases. A parent task would be blocked by its subtasks. There was a command
>> to create a subtask, which would create the appropriate blocking
>> relationships.
>>
>> Now, phab uses the parent/subtask terminology to cover both cases. In the
>> sequential tasks case, the endpoint would be considered the parent, so in
>> the example above, "document" would be the parent, and "implement" would be
>> its subtask. Note that a task may have multiple "parents".
>>
>> A nice feature they added is the ability to manage the parent/subtask
>> relationship from either end. While editing a task, you can change its
>> subtasks or its parents. Previously, you could only edit one direction.
>>
>> I created T139181 as a task to update our wiki phab documentation.
>>
>> Kevin Smith
>> Agile Coach, 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Coming up with a Phab tag for "spike"

[Max Binder]

https://phabricator.wikimedia.org/T138380

"Spike" is a widely-used term in Agile development, and many teams at the
Foundation employ it. However, as Danny_B (and AKlapper) have pointed out
in the above ticket, it is not an intuitive term for what it means,
particularly for those not using Agile (or for whom English is not their
first language).

I would be interested in other opinions, preferably on the Phab ticket
itself. :)
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Fun remote retrospectives

[Max Binder]

Thanks, Joaquin! Always good to have another way to do things.

Some of these are document-friendly, too. Android, for instance, uses the
"4Ls" retrospective every 2 weeks, and they do it list-style in an
etherpad. :)

On Wed, Jun 8, 2016 at 3:46 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> I came across this repo today by chance:
>
> https://github.com/rogeriochaves/remote-retrospectives
>
> It has links to google doc templates for doing retro activities
> funretrospectives.com  style.
>
> Seems interesting so I thought I'd share.
>
> ___
> 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?

[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 <gleder...@wikimedia.org>
wrote:

> On Thu, May 5, 2016 at 11:21 PM, Max Binder <mbin...@wikimedia.org> wrote:
> > Sorry for the delayed response. Inline:
> >
> >> Could you provide examples of these "action items"? It will help
> >> understanding the relevance of "non-dev/product" action items coming
> out of
> >> (presumably dev/product) sprint retrospectives.
> >
> >
> > Examples:
> >
> > Reach out to Team X to see what their OTRS norms are
> > Look into gCal To Dos system for process alternatives
> > Team member A syncs with Team member B and C on travel plans
> > Get Team member D access to OTRS
> > Forward email about cross-team collaboration to someone outside team
> >
> > Hopefully that provides some context? Folks on some of the teams
> represented
> > above have felt that it's too cumbersome or it's inappropriate to
> document
> > some of these tasks in Phabricator backlogs/release boards/sprint boards.
> >>
> >> Is it fair to assume that most actions coming out of a sprint
> >> retrospective will have impact on the team?
> >
> >
> > Yes
> >
> >> Why overhead? Creating a minimally acceptable Phabricator task takes one
> >> title and one project to associate it with. Even a description is
> optional.
> >> If that project is #Team-X-Internal-Stuff, then the rest can't be
> bothered.
> >
> >
> > The overhead is relative. Right now, teams enjoy the ease that comes with
> > checking a retro-followup email, or a list in a Google Doc or Etherpad.
> > Obviously, in some cases, this is not enough to actually ensure the task
> > gets done. Phabricator, like most task-tracking systems, can be a little
> > overkill when it comes to tracking these simpler tasks. JIRA, for example
> > would be pretty heavy for reminding someone to talk to someone else
> before
> > the next bi-weekly retro.
> >
> > Ultimately, the default solutions are A) the status quo of list/email
> > (simple, lossy), or B) the existing task-tracker, like Phab (in-process,
> > cumbersome). The teams are looking for more middle ground.
> >
> >> If the "overhead" concern also (or actually) encompasses a concern about
> >> lack of privacy (i.e. "John to get a headset that actually works in
> >> hangouts") then you can always request a private space for your team in
> >> Phabricator.
> >
> >
> > Thank you for pointing that out. I do think some component of this is
> > privacy, so in the event that a team feels good about using Phabricator
> for
> > sensitive tasks, it's good to know they can.
> >
> >> The usual rule we put in place with our teams was: "A retrospective
> >> action must have a fairly limited scope and be possible to implement
> >> before the next retrospective". Larger items are not considered to be
> >> retrospective actions, but might be put into the team backlog. Action
> >> items are the responsibility of their owner (if we can't find an owner
> >> for the action, the action is dropped). The facilitator responsibility
> >> is to check the status of those actions at the next retro. If those
> >> actions have not been completed by the next retro, they

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

[Max Binder]

ecently, 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 <g...@wikimedia.org>
> wrote:
>
>> That's basically how we do it in releng during our meetings.
>>
>> --
>> Sent from my phone, please excuse brevity.
>> On Apr 27, 2016 10:20 AM, "Guillaume Lederrey" <gleder...@wikimedia.org>
>> wrote:
>>
>>> In another life, I have been facilitating a few retrospectives. Not
>>> here yet, so the context is probably different and this past
>>> experience probably does not apply without the necessary amount of
>>> tweaking. Still:
>>>
>>> The usual rule we put in place with our teams was: "A retrospective
>>> action must have a fairly limited scope and be possible to implement
>>> before the next retrospective". Larger items are not considered to be
>>> retrospective actions, but might be put into the team backlog. Action
>>> items are the responsibility of their owner (if we can't find an owner
>>> for the action, the action is dropped). The facilitator responsibility
>>> is to check the status of those actions at the next retro. If those
>>> actions have not been completed by the next retro, they are either
>>> dropped (if we did not make progress, they are probably not as
>>> important as we thought), converted as backlog item (they were larger
>>> than we initially thought), or kept as action item for the next retro
>>> (rare case).
>>>
>>> With those rules, we don't rely on specific tools...
>>>
>>> No idea how this applies at WMF...
>>>
>>>
>>> On Wed, Apr 27, 2016 at 9:55 AM, Quim Gil <q...@wikimedia.org> wrote:
>>> > Could you provide examples of these "action items"? It will help
>>> > understanding the relevance of "non-dev/product" action items coming
>>> out of
>>> > (presumably dev/product) sprint retrospectives.
>>> >
>>> > This sounds like a matter of threshold:
>>> >
>>> > * If an action item is purely personal, then sure, use the purely
>>> personal
>>> > tool to deal with it.
>>> > * If an action item has an impact on the team, then use the team tool
>>> to
>>> > deal with it, no matter how simple, small, "non-dev/product".
>>> >
>>> > Is it fair to assume that most actions coming out of a sprint
>>> retrospective
>>> > will have impact on the team?
>>> >
>>> > This is where the fear to i.e. bringing back Trello doesn't sound any
>>> > visceral to me, but well justified. Someone starts creating strictly
>>> > personal actions in Trello (Asana, etc), they continue adding other
>>> small
>>> > actions because 'since we are using this tool anyway and I'm writing
>>> the
>>> > actions quickly after the meeting'... Three months down the road that
>>> > parallel board has got a life on its own, they start having tasks
>>> > duplicating with the team's tasks in Phabricator, some things fall
>>> between
>>> > the cracks...
>>> >
>>> > Yes, I know this would not happen to *you* or *your* team (whoever
>>> *you*
>>> > are), but looking at our history we have solid reasons to think that
>>> this
>>> > will certainly happen to *someone*, and then that will be taken as a
>>> > reference by * someone else* not reading this thread today, and then...
>>> >
>>> >
>>> >
>>> > On Wed, Apr 27, 2016 at 1:49 AM, Max Binder <mbin...@wikimedia.org>
>>> wrote:
>>> >>
>>> >> 

[teampractices] Phabricator workboards appear to show story point, WIP limit, AND count

[Max Binder]

I noticed a change over the last few days.
 [image: Inline image 1]
This example attached shows that the column is counting 1 card, 1 point,
with a WIP limit of 1 out of 8. Teams have been requesting card count for a
long time (Kanban, for example, uses card count rather than points), so
this is good news!

I've tested this new implementation, and confirmed my observation above.
However, I've also confirmed that the WIP is still points-based, rather
than count-based, but this is a good first step! :)
___
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 <bd...@wikimedia.org> wrote:

> On Tue, Apr 26, 2016 at 6:07 PM, Max Binder <mbin...@wikimedia.org> wrote:
> > On Tue, Apr 26, 2016 at 5:02 PM, Bryan Davis <bd...@wikimedia.org>
> wrote:
> >>
> >> On Tue, Apr 26, 2016 at 5:49 PM, Max Binder <mbin...@wikimedia.org>
> 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<bd...@wikimedia.org>
> [[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

[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

Re: [teampractices] [ANY] Looking for live example of a Phabricator custom form

[Max Binder]

Thanks, Mukunda! This is great.

You can require certain projects for all task creations going through your
> creation form, but then the user can't add any extra projects themselves
> (AFAIK).


Do you happen to know if Alex is correct about this?



On Fri, Apr 15, 2016 at 9:01 AM, Mukunda Modell <mmod...@wikimedia.org>
wrote:

> I created a custom form just to demonstrate the possibilities and
> encourage people to request custom forms. Simply submit the example to
> request your own custom form:
>
> https://phabricator.wikimedia.org/maniphest/task/edit/form/17/
>
> On Thu, Apr 14, 2016 at 5:29 PM, Alex Monk <am...@wikimedia.org> wrote:
>
>> To get a custom form for anything it should go through that project, yes.
>>
>> You can require certain projects for all task creations going through
>> your creation form, but then the user can't add any extra projects
>> themselves (AFAIK).
>>
>> You should be able to set the default task description to some helpful
>> template, but reproduction steps are not always required for bug reports.
>>
>> On 14 April 2016 at 23:13, Max Binder <mbin...@wikimedia.org> wrote:
>>
>>> Thanks for the updates. It's my understanding that in order to get a
>>> custom form for a team, it should be requested via the Phabricator
>>> project <https://phabricator.wikimedia.org/tag/phabricator/>. Is this
>>> correct?
>>>
>>> My hope was to make it easier for my teams to make tasks by
>>> autopopulating certain things, like Projects that must always be tagged, or
>>> prefilling information that is always required (such as repro steps for
>>> bugs). Is this an appropriate use of forms?
>>>
>>> On Thu, Apr 14, 2016 at 2:54 PM, Alex Monk <am...@wikimedia.org> wrote:
>>>
>>>> Custom forms for tasks (i.e. not projects, pastes, etc.) are listed at
>>>> https://phabricator.wikimedia.org/transactions/editengine/maniphest.task/
>>>>
>>>> On 14 April 2016 at 22:45, Kevin Smith <ksm...@wikimedia.org> wrote:
>>>>
>>>>> I never saw replies to this. I thought forms were a hotly-requested
>>>>> feature. Are teams using them? If not, are there implementation problems,
>>>>> or is it just a matter of not having the time to get to it yet?
>>>>>
>>>>>
>>>>>
>>>>> Kevin Smith
>>>>> Agile Coach, Wikimedia Foundation
>>>>>
>>>>>
>>>>> On Sat, Apr 2, 2016 at 4:23 AM, Max Binder <mbin...@wikimedia.org>
>>>>> wrote:
>>>>>
>>>>>> Wondering if this is a feature that my teams might want to use for
>>>>>> their bug report templates, and/or ensuring the right projects are tagged
>>>>>> for regular tasks, etc. I'd love to explore existing custom forms on 
>>>>>> other
>>>>>> teams. I think I heard that the researchers might be such a team, but I'm
>>>>>> open to any examples. :)
>>>>>>
>>>>>> ___
>>>>>> 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
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> Alex Monk
>>>> VisualEditor/Editing team
>>>> https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
>>>>
>>>> ___
>>>> 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
>>>
>>>
>>
>>
>> --
>> Alex Monk
>> VisualEditor/Editing team
>> https://wikimediafoundation.org/wiki/User:Krenair_(WMF)
>>
>> ___
>> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [Engineering] [Talk] How To Stop Sucking And Be Awesome Instead

[Max Binder]

Interesting video. I can appreciate Boyd's Law of Iteration.

On Wed, Apr 6, 2016 at 2:56 AM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> I really enjoyed this talk from Jeff Atwood, it contains a lot of wisdom
> and I thought I'd share it around here
>
> https://www.youtube.com/watch?v=L7EGIt3-WUQ
>
>
>
> ___
> Engineering mailing list
> engineer...@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/engineering
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Curiosity, cognitive reward, and breaking bad habits

[Max Binder]

http://www.ted.com/talks/judson_brewer_a_simple_way_to_break_a_bad_habit/transcript?language=en

An interesting look at curiosity in mindfulness. The following phrase also
stuck out to me, since we often talk about curiosity as a foundation for
establishing and sustaining good process:

What if instead of fighting our brains, or trying to force ourselves to pay
> attention, we instead tapped into this natural, reward-based learning
> process ... but added a twist? What if instead we just got really curious
> about what was happening in our momentary experience?
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator

[Max Binder]

The milestone columning feature, while something I can see providing value,
doesn't do much for my POs so far. However, there is some interest in
tagging tasks by feature category, as opposed to parenting under
sticky-epics, or using a column for each feature. Creating separate tags
(projects) for apps-specific tasks can make Phab messy overall if there are
a lot of them, but Milestones might solve this problem by essentially
existing as project-specific "tags."

On Wed, Mar 2, 2016 at 1:12 PM, Kevin Smith  wrote:

> Based on a quick hallway conversation with Joel, I came away feeling like
> sub-projects probably won't be useful to Discovery. I do still hope to
> experiment with them at some point, though.
>
> On the other hand, hearing that milestone tasks appear in as a column in
> the parent task's board is quite intriguing. I'll have to check with our
> POs to see if that would be useful.
>
> We are contemplating restructuring the Discovery projects and boards, so
> this is nice timing.
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Wed, Mar 2, 2016 at 12:48 AM, Quim Gil  wrote:
>
>> Hi,
>>
>> On Tue, Mar 1, 2016 at 12:08 AM, Joel Aufrecht 
>> wrote:
>>>
>>> I'm trying to work out, on behalf of VE, exactly how we would want to
>>> use the new sub-project and milestone functionality.
>>>
>>
>> Community Liaisons and Developer Relations have a much simpler process,
>> but I still wonder whether we could improve it by using subprojects.
>>
>> We have team projects to tag any tasks related to our teams, i.e.
>> https://phabricator.wikimedia.org/project/view/27/
>>
>> Then, we organize what we call monthly sprints but is actually not a
>> "Sprint project" but a tag that we add to tasks that we plan to work on a
>> certain month, without a commitment to finish them, no story points, no
>> burndown. See for instance
>> https://phabricator.wikimedia.org/project/view/1649/
>>
>> In theory, these monthly sprints could be subprojects of our team
>> project, right? If I understood the subprojects feature correctly, this
>> would mean that
>>
>> * Tasks in a sprint (subproject) would not appear in the main project
>> (team) workboard, which would be useful to see the tasks that haven't been
>> scheduled yet.
>> * Tasks in one subproject (i.e. #Liaisons-March-2016) could still be
>> added to other subprojects as well (April, May, etc).
>>
>> Do you think this approach makes sense?
>>
>> --
>> 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
>>
>>
>
> ___
> 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] Use cases for work tracking, sub-projects, etc in Phabricator

[Max Binder]

>
>
>>- Parenting is too cumbersome because it's not bidirectional.
>>
>> What exactly do you mean here?  I can think of:
>

Basically what you laid out. As tasks are created, there are far more
instances of "this is a child of X" than there are "X should be broken down
into Y." It's too hard to add a task to a parent. I suppose that can be a
process issue, where one is thinking up new things and fitting them into
existing parents/epics, and the other is breaking down an existing epic,
but in my experience the teams are more likely to come up with new ideas
and see how they fit. Frankly, that feels a little more "planning" rather
than "plan" anyway.

 What would make tagging (categorizing) less lossy?  The main thing coming
> to mind it to easily see untagged things, in order to create a feedback
> loop where you can instantly see what's still untagged and tag it.  How
> would that work?


I think the new board UI helps with this, by showing project tags on cards,
but if there are a lot of cards it's still not easy. The primary motivation
for getting a product owner to tag is the disarray they will feel if
something is not tagged. Additionally, if you want a parent to have a tag,
but not the child (such as with the "Milestone" project), you have to
manually fix that, and I've observed that most people forget.

Phlogiston has mitigated this, some, by showing that if you don't follow
process then you won't get your reports.



On Tue, Mar 1, 2016 at 11:43 AM, Joel Aufrecht <jaufre...@wikimedia.org>
wrote:

> On Tue, Mar 1, 2016 at 10:09 AM, Max Binder <mbin...@wikimedia.org> wrote:
>
>> I think the appeal of Subprojects is that they offer a new alternative to
>> the clunky UI that Phab offers for tagging/parenting/columning. What I'd
>> love to see is what "clunk" is relieved and, inevitably, what clunk is
>> added. Ultimately, my main issue is that all the ways we've identified, for
>> tracking tasks in Phab, are lossy. All the options for organizing work
>> after the fact, but are not terribly approachable (and thus not terribly
>> sustainable).
>>
>>- Parenting is too cumbersome because it's not bidirectional.
>>
>> What exactly do you mean here?  I can think of:
>
>- From a child, it should be possible to choose the parent.
>   - Currently, this relationship can only be constructed by opening
>   the parent, entering the child's name in a search function, and 
> selecting
>   it from a list.
>   - It would be an improvement simply to be able to type in child IDs
>   somewhere on the parent (since that's easier than the name search thing 
> if
>   you have the ID handy), but actually better would be to open the child,
>   click "Add Blocks", and pick titles (or IDs)
>- Data model and UI that differentiates between child/parent terms and
>blocked by/blocks.
>   - Enforcement of acyclic directed trees for parent-child
>- While looking at a task, see the parent or parents (in the detail,
>or on the card, or in a tooltip for the card).
>
>
>>- Tagging is lossy because it's too easy to forget to do it, and
>>sometimes the wrong default tags are applied by default (such as when
>>creating a subtask).
>>
>> What would make tagging (categorizing) less lossy?  The main thing coming
> to mind it to easily see untagged things, in order to create a feedback
> loop where you can instantly see what's still untagged and tag it.  How
> would that work?
>
>>
>>- Columns are workable but they cause a loss of priority of tasks
>>across columns.
>>
>>
>
>> I guess my question/hope for Subprojects is, "Is it easy to use?"
>>
> It isn't right now, because moving a task from Project to Subproject is no
> easier than changing it from Project A to Project B: in both cases you have
> to edit the task, choose to change projects, enter a partial name for the
> new (sub)project, and select it.  There's no way while looking at a project
> board to see the subproject tasks, or even to know what the subprojects are
> or that there are any -- you have to click the "Subprojects" option in the
> left menu.  So the only benefit in the UI right now for Subprojects is that
> you can filter a search by a project and get back subproject's tasks.
> Which is a use case I haven't seen any teams need yet, actually.
>
> Milestones have more UI functionality: When you create a Milestone, it by
> default is presented as a column in its parent project's workboard.  so you
> can assign tasks to Milestones within a project via drag-and-drop, and you
> can see all tasks in all Mil

Re: [teampractices] Use cases for work tracking, sub-projects, etc in Phabricator

[Max Binder]

I think the appeal of Subprojects is that they offer a new alternative to
the clunky UI that Phab offers for tagging/parenting/columning. What I'd
love to see is what "clunk" is relieved and, inevitably, what clunk is
added. Ultimately, my main issue is that all the ways we've identified, for
tracking tasks in Phab, are lossy. All the options for organizing work
after the fact, but are not terribly approachable (and thus not terribly
sustainable).

   - Parenting is too cumbersome because it's not bidirectional.
   - Tagging is lossy because it's too easy to forget to do it, and
   sometimes the wrong default tags are applied by default (such as when
   creating a subtask).
   - Columns are workable but they cause a loss of priority of tasks across
   columns.

I guess my question/hope for Subprojects is, "Is it easy to use?"

On Mon, Feb 29, 2016 at 3:08 PM, Joel Aufrecht 
wrote:

> Hi,
>
> I'm trying to work out, on behalf of VE, exactly how we would want to use
> the new sub-project and milestone functionality.  Without going into a full
> requirements analysis, I wanted to try to enumerate key use cases and think
> through how they are currently met with Phabricator UI (without
> sub-projects), how we could use sub-projects, and what data model or UI
> changes might be necessary to improve on current processes.  The list below
> starts with VE, and I would be excited to see how other teams are doing
> these things (or what other use cases are important):
>
> *Triage*
>
> *As a Product Owner, I want to categorize and prioritize incoming tasks so
> that they can be worked on by the right people at the right time.*
> VE does this with a weekly triage meeting in which the Product Owner views
> all new tasks in the last week, in order of submission (or reversed), and
> triages one at a time.  Specifically, the PO looks at tasks in the default
> column of the VisualEditor project, edits the Priority field, possibly adds
> a comment, and drags the task to a different column.  In VE, the columns
> represent different
> [initiatives/ultra-milestones/goals/tranches/categories] (for example,
> "Rich Media" or "Language Support").
>
> *Overview (grooming)*
>
> *As a Product Owner with new priorities, I want to alter the backlog for
> my project to reflect new priorities.*
> VE does this via the PO adding and renaming columns and moving tasks
> between columns on the work board.  (All VE work is on a single workboard,
> which means it's all in one project.)  We have also experimented with using
> the "Blocked By" relationship to identify a tree of related tasks, but this
> is not visible in Phabricator workboards (nor can ancestor Blocked-By be
> seen or sorted or filtered on) and can only be seen in Phlogiston reports.
>
>
> *As a Product Owner with knowledge of work in my project, I want to review
> the backlog for my project so that I can see if the backlog is current and
> correct compared to reality.*
> In VE, this has two parts: First, are tasks in right categories?  This
> normally happens in triage, but the Product Owner occasionally notices
> something out of place (a task in the wrong column) while examining the
> board view for other purposes.  Second, are categories right in relation to
> one another?  This happens when the PO looks at the board, but more often
> when the PO looks at the Phlogiston report that shows not only columns but
> also task family (blocked by)-based categorizations.
>
> VE sometimes does overall work planning (in the style of Scrum card
> mapping, where tasks from different areas/columns are all sliced into
> different releases/rows) from the board.  I've already heard that some
> teams have approximated Scrum card mapping by using "dummy tasks" in
> columns, so that tasks above or below that task in a column can be
> perceived to be in a theoretical "row" that may be consistent across
> columns.
>
> The main activity in VE that isn't supported adequately in Phabricator is
> mixing blocked-by relationships and columns.  For example, VE may have 50
> tasks in the "Language" column, and five of those tasks may all be set to
> block a "Release Korean support".  Those six tasks comprise "sub-category"
> within Language, where Language is a broad, long-term grouping and "Release
> Korean support" is a subset with a fixed scope.  There is no way directly
> in Phabricator to see, in one view, which tasks share the same blocking
> relationship.  One way to support this in Phabrictor would be to add a
> display field in the task and/or task card showing the ancestor "blocks"
> task(s).  Currently we can see this in aggregate, but not per-task, in
> Phlogiston reports.  The sub-project construct supports the same underlying
> data relationship, but in a different, reversed way: in Phabricator, you
> can filter on a project and you will see all tasks belonging to
> sub-projects.
>
> *Decide what to work on next*
> *As someone doing work in a project, I want to use 

Re: [teampractices] NYTimes article on Google's team psychology

[Max Binder]

Whoops, I guess my email hadn't refreshed, just noticed that this was
already sent out. :)

On Fri, Feb 26, 2016 at 11:30 AM, Max Binder <mbin...@wikimedia.org> wrote:

> Interesting read that has some parallels to the Team Practices Group's
> work:
>
>
> http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html?smid=fb-nytimes=cur&_r=1=
> <http://mobile.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html?smid=fb-nytimes=cur&_r=0=>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Setting norms for points field in Phabricator

[Max Binder]

>
> What should we do about making points consistent across teams?


To clarify, do you mean teams using the same points to mean the same thing?
Currently, I suspect teams use points to mean different things (Team A says
5 points is "a day's work" while Team B says 5 points is "two day's work"
while Team C says 5 points is not time but complexity, etc).

On Thu, Feb 18, 2016 at 11:05 AM, Joel Aufrecht 
wrote:

> The points field is now global to all tasks, raising some interesting
> questions:
>
> 1) What do engineers/product owners (staff or otherwise) working on tasks
> do when community members set or change points?
>
> 2) What should we do about making points consistent across teams?
>
> My initial thoughts/proposal, which we could run past teams we are working
> with and engaged community members:
>
> 1) we should have a written policy along the lines that points is intended
> to be used by people doing the engineering work on tasks, and that
> therefore only those people (staff on teams working on tasks; community
> members contributing code/testing/other engineering work) should edit
> points.
>
> 2) We should explictly document that points cannot be compared across
> teams, that there is no single standard definition or meaning for points,
> and that they cannot be used in isolation to forecast.  In an analogy, I
> see points as a bit like database ID fields; even if they are exposed, you
> can't use them for certain things you may be tempted to use them for,
> because they are warranteed for that use; instead, you should use the
> appropriate derivation for your purpose.
>
> Thoughts?
>
>
>
> *--Joel Aufrecht*
> Team Practices Group
> 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

[teampractices] Converting etherpad notes to wiki markup

[Max Binder]

Anyone have a process or tool for this besides manually editing the text in
an etherpad?

I've encountered this hiccup with a few teams now. Most folks I've talked
to about it would like an easy way to transfer text from etherpads to wikis
quickly, without having to worry about writing the etherpad text in wiki
markup.

I also stumbled across this extension:
https://wiki.mozilla.org/Help:Import_From_Etherpad
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [TOOL REQUEST] A way to "raise your hand" as a remotee

[Max Binder]

I tested this on a willing Team Practices Group, and got a lot of good
feedback. I populated the github issues page with a slew of user stories. :)

On Wed, Jan 13, 2016 at 7:31 PM, Sam Smith <samsm...@wikimedia.org> wrote:

> I would say is that I found myself wanting to immediately respond to a
> question and I wasn't sure of the protocol. However, I suspect that this
> was heavily influenced by the fact that I was in the meeting room – I'm
> usually a face on the big green – and I could see the stack of people
> waiting to talk.
>
> It's been great trying out the tool and I'm looking forward to using it
> again.
>
> -Sam
>
> On Wed, Jan 13, 2016 at 6:12 PM, Joaquin Oltra Hernandez <
> jhernan...@wikimedia.org> wrote:
>
>> Default volume should be 5% now, which works fine in meeting rooms, you
>> can barely hear it.
>>
>> We found very useful to keep the stack window on the big screen resized
>> side by side with the big hangouts window to give visibility to the stack.
>>
>> Even the members of the room used it to wait for a turn, it was pretty
>> useful!
>> On Jan 13, 2016 17:14, "Max Binder" <mbin...@wikimedia.org> wrote:
>>
>>> Yea, I think the best use of sound would be something that the
>>> facilitator can hear, but not necessarily everyone. And maybe simply a
>>> nicer sound. :)
>>>
>>> I'll populate the github page!
>>>
>>> On Mon, Jan 11, 2016 at 3:15 PM, Joaquin Oltra Hernandez <
>>> jhernan...@wikimedia.org> wrote:
>>>
>>>> Adam, we talked about this and it seems like showing some kind of stats
>>>> with how many times the attendants have been in the room would help seeing
>>>> who has participated more and who less. Would that be reasonable?
>>>>
>>>> We've tried it out today in a long meeting and it was definitely
>>>> helpful (i monitored the queue, and it helped people queue for talking
>>>> without disrupting the current conversation).
>>>>
>>>> We also found that the sounds are pretty disruptive, so we've added a
>>>> mute button so that we can show it on the meeting screen and in remotes
>>>> that are talking without bothering everyone. I want to get around to
>>>> lowering the volume of the sounds, or disabling them by default. They don't
>>>> seem as useful as we anticipated.
>>>>
>>>> If you find issues or want to request changes, go to
>>>> https://github.com/joakin/stack/issues
>>>>
>>>> Thanks!
>>>>
>>>>> On Jan 11 2016, at 12:41 pm, Kristen Lans <kl...@wikimedia.org>
>>>>> wrote:
>>>>> Very cool Joaquin! I can't wait to try it.
>>>>>
>>>>> FYI, here's a link to a short description of the facilitation
>>>>> technique of "stacking" from the group I learned it from, Community at
>>>>> Work: http://tinyurl.com/hv5ufmd
>>>>>
>>>>> KL
>>>>>
>>>>> On Mon, Jan 11, 2016 at 11:55 AM, Max Binder <mbin...@wikimedia.org>
>>>>> wrote:
>>>>>
>>>>> Thanks, Joaquin!
>>>>>
>>>>> I can't wait to test it in a real meeting. Maybe I'll use TPG as
>>>>> guinea pigs...
>>>>>
>>>>>
>>>>> On Fri, Jan 8, 2016 at 2:56 PM, Joaquin Oltra Hernandez <
>>>>> jhernan...@wikimedia.org> wrote:
>>>>>
>>>>> Hi!
>>>>>
>>>>> I've worked on this during the hackathon, and after chatting with Max
>>>>> it has the required functionality to work:
>>>>>
>>>>> http://stack.wmflabs.org
>>>>>
>>>>> Features:
>>>>> * create named rooms (shareable URL)
>>>>> * add yourself to the queue (remembers name)
>>>>> * one person can add multiple people
>>>>> * can pop from the stack (needs human agreement on who will be the
>>>>> popper)
>>>>> * plays sound when somebody is added to queue
>>>>> * after 5 minutes of stale queue plays warning sound
>>>>>
>>>>> It's kind of real-time (1s interval polling to server) and it may
>>>>> crash at some point, but it gets the job done for now. It's also not 
>>>>> really
>>>>> secured so a mean user can probably easily crash the server, I'm assuming
>>>>> good faith for now.
>>>>>
>

Re: [teampractices] [TOOL REQUEST] A way to "raise your hand" as a remotee

[Max Binder]

Yea, I think the best use of sound would be something that the facilitator
can hear, but not necessarily everyone. And maybe simply a nicer sound. :)

I'll populate the github page!

On Mon, Jan 11, 2016 at 3:15 PM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Adam, we talked about this and it seems like showing some kind of stats
> with how many times the attendants have been in the room would help seeing
> who has participated more and who less. Would that be reasonable?
>
> We've tried it out today in a long meeting and it was definitely helpful
> (i monitored the queue, and it helped people queue for talking without
> disrupting the current conversation).
>
> We also found that the sounds are pretty disruptive, so we've added a mute
> button so that we can show it on the meeting screen and in remotes that are
> talking without bothering everyone. I want to get around to lowering the
> volume of the sounds, or disabling them by default. They don't seem as
> useful as we anticipated.
>
> If you find issues or want to request changes, go to
> https://github.com/joakin/stack/issues
>
> Thanks!
>
>> On Jan 11 2016, at 12:41 pm, Kristen Lans <kl...@wikimedia.org> wrote:
>> Very cool Joaquin! I can't wait to try it.
>>
>> FYI, here's a link to a short description of the facilitation technique
>> of "stacking" from the group I learned it from, Community at Work:
>> http://tinyurl.com/hv5ufmd
>>
>> KL
>>
>> On Mon, Jan 11, 2016 at 11:55 AM, Max Binder <mbin...@wikimedia.org>
>> wrote:
>>
>> Thanks, Joaquin!
>>
>> I can't wait to test it in a real meeting. Maybe I'll use TPG as guinea
>> pigs...
>>
>>
>> On Fri, Jan 8, 2016 at 2:56 PM, Joaquin Oltra Hernandez <
>> jhernan...@wikimedia.org> wrote:
>>
>> Hi!
>>
>> I've worked on this during the hackathon, and after chatting with Max it
>> has the required functionality to work:
>>
>> http://stack.wmflabs.org
>>
>> Features:
>> * create named rooms (shareable URL)
>> * add yourself to the queue (remembers name)
>> * one person can add multiple people
>> * can pop from the stack (needs human agreement on who will be the popper)
>> * plays sound when somebody is added to queue
>> * after 5 minutes of stale queue plays warning sound
>>
>> It's kind of real-time (1s interval polling to server) and it may crash
>> at some point, but it gets the job done for now. It's also not really
>> secured so a mean user can probably easily crash the server, I'm assuming
>> good faith for now.
>>
>> Open to comments, hope this helps!
>> On Sep 22, 2015 08:53, "Dan Garry" <dga...@wikimedia.org> wrote:
>>
>> On 22 September 2015 at 08:40, Kevin Smith <ksm...@wikimedia.org> wrote:
>>
>> I had thought about that in the past, but seeing it in this thread really
>> resonated with me. For meetings with a mix of SF and remote folks, I am
>> starting to think that it would be better for all the SF folks to scatter
>> and use individual computers to join the hangout.
>>
>>
>> This is harder than it seems. It can be quite disruptive to those around
>> you to sit at your desk being noisy participating in a hangout, and that
>> rules out a large part of the office. I've done this before myself from the
>> fifth floor collab space, where there are no permanent desks and some
>> semi-private areas, but you cannot guarantee the availability of those
>> spaces. When I was remote I often wondered why more people didn't do this,
>> but when I moved to the office, I started to appreciate the difficulties
>> with it.
>>
>> Dan
>>
>> --
>> Dan Garry
>> Lead Product Manager, 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
>>
>>
>>
>> ___
>> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [TOOL REQUEST] A way to "raise your hand" as a remotee

[Max Binder]

Thanks, Joaquin!

I can't wait to test it in a real meeting. Maybe I'll use TPG as guinea
pigs...


On Fri, Jan 8, 2016 at 2:56 PM, Joaquin Oltra Hernandez <
jhernan...@wikimedia.org> wrote:

> Hi!
>
> I've worked on this during the hackathon, and after chatting with Max it
> has the required functionality to work:
>
> http://stack.wmflabs.org
>
> Features:
> * create named rooms (shareable URL)
> * add yourself to the queue (remembers name)
> * one person can add multiple people
> * can pop from the stack (needs human agreement on who will be the popper)
> * plays sound when somebody is added to queue
> * after 5 minutes of stale queue plays warning sound
>
> It's kind of real-time (1s interval polling to server) and it may crash at
> some point, but it gets the job done for now. It's also not really secured
> so a mean user can probably easily crash the server, I'm assuming good
> faith for now.
>
> Open to comments, hope this helps!
> On Sep 22, 2015 08:53, "Dan Garry"  wrote:
>
> On 22 September 2015 at 08:40, Kevin Smith  wrote:
>>
>> I had thought about that in the past, but seeing it in this thread really
>> resonated with me. For meetings with a mix of SF and remote folks, I am
>> starting to think that it would be better for all the SF folks to scatter
>> and use individual computers to join the hangout.
>>
>
> This is harder than it seems. It can be quite disruptive to those around
> you to sit at your desk being noisy participating in a hangout, and that
> rules out a large part of the office. I've done this before myself from the
> fifth floor collab space, where there are no permanent desks and some
> semi-private areas, but you cannot guarantee the availability of those
> spaces. When I was remote I often wondered why more people didn't do this,
> but when I moved to the office, I started to appreciate the difficulties
> with it.
>
> Dan
>
> --
> Dan Garry
> Lead Product Manager, 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [Discussion] Term for always prepping for the next thing

[Max Binder]

I think it is good to frame time as a budget, because it is a finite
resource. Then the mantra becomes "I need to spend less" rather than "I
need more resources."

Hofstadter's Law (a favorite) relates better to our previous point on
measuring capacity. Estimating task size and complexity is a key part of
measuring capacity. Our bullet points earlier in the thread talk about
gaining forecasting accuracy over time, and subsequently adjusting batch
size with each iteration, to get a better understanding of how long it
takes to do something in one loop. Then re-prioritize accordingly, with the
umbrella understanding that finishing (or totally abandoning) work is
usually a higher priority than starting and stopping.

Jim Benson wrote an excellent book [1] on biases that talks about
differentiating "prediction" from "estimation." Prediction is the act of
aiming with the hope you are right, where estimation is is the act of
aiming with the understanding that you are wrong. The former points you
towards a status quo and disappointment when it is not met, where the
latter prepares you for inevitable change. It's a subtle difference that
can really help to focus on when trying to inspect and adapt properly.

[1]
https://www.mediawiki.org/wiki/Team_Practices_Group/Recommended_Reading#Agile_.28general.29

On Wed, Sep 30, 2015 at 12:14 PM, S Page  wrote:

> On Wed, Sep 9, 2015 at 10:32 AM, Kevin Smith  wrote:
>
>>  I'm imagining someone whose "todo" queue is growing linearly while their
>> "done" pile eternally remains empty. It seems odd that new higher-priority
>> work would be coming in so fast that not only can the old work not get done
>> first, but the new work can't either.
>>
>
> The problem for me comes from ruthless prioritization vs. dealing with new
> small inbox issues in the moment. I'm sure I read some advice to do the
> latter instead of the overhead of managing an enormous growing pile of
> postponed work. Especially with documentation, tagging yet another mail
> thread "ought to document this nugget some day" vs. spending
> just-a-little-bit more time getting it done here and now. The problems are
> a) If there are too many small things you can get done in the moment, then
> those moments take over your day.
> b) Hoftstadter's Law [1].
>
> I guess the answer is to budget your time better. Thanks for any advice,
> though I don't expect any because answering this is not in your quarterly
> goals or current sprint :-).
>
> [1] "It always takes longer than you expect, even when you take into
> account Hofstadter's Law." https://en.wikipedia.org/wiki/Hofstadter's_law
>
> --
> =S Page  WMF Tech writer
>
> ___
> 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

[teampractices] [TOOL REQUEST] A way to "raise your hand" as a remotee

[Max Binder]

*TL;DR: Looking for a browser-based tool, in the vein of hatjitsu
, that queues people for a facilitator
running a meeting.*

In a few meetings lately, we've struggled a bit to see the raised hands of
remotees. This might be because the facilitator is presenting their screen
(and thereby can't see hands), or it might be because the facilitator in
physically at the meeting and there are only one or two remotees, or it
might be another reason. It sounds like something easy to fix simply by
"paying better attention," but you might be surprised how easily remotees
get excluded unintentionally.

Some videoconferencing software has a "raise your hand" feature that
Hangouts lacks. I've found an unofficial Hangouts plugin
 that does this, but
it would be burdensome to implement. There are also other standalone tools
 that I've not tested as of
yet (MAMP is giving me a hard time with PHP).

I presented the issue to OIT, who suggested the method used in Monthly
Metrics, of etherpad+IRC(+James Forrester). While good for Q, I don't
think it works as well for a group of people in a smaller meeting who are
trying to toss the ball back and forth. It also requires people to manually
withdraw their comments or questions if they have been addressed (or fall
to the facilitator to determine if a comment or question is already
addressed). A bit like Phabricator, it works, but it doesn't...flow.

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

Re: [teampractices] [Discussion] Term for always prepping for the next thing

[Max Binder]

Thanks all. I distilled the best practices for "sensation X" to:

   - Set priorities, execute in order, interrupt only if necessary
   - Stop starting, and start finishing
   - Forecast capacity, and use forecasting accuracy as a barometer for
   iteration length/batch size
   - Create MVPs, and shorten iterations as much as possible to ship *and*
   get feedback

Practices par for the course in these parts, but I appreciated the
discussion. Thanks all!

On Wed, Sep 9, 2015 at 10:32 AM, Kevin Smith <ksm...@wikimedia.org> wrote:

> Hopefully this depiction is an exaggeration of what is really happening,
> because right now I'm imagining someone whose "todo" queue is growing
> linearly while their "done" pile eternally remains empty. It seems odd that
> new higher-priority work would be coming in so fast that not only can the
> old work not get done first, but the new work can't either.
>
> Whoever is prioritizing work needs to at least be able to distinguish
> between "something is on fire" and everything else. Only a "something is on
> fire" issue should interrupt work in progress. If those come up a lot, then
> it starts to sound like they need to hire someone else to put out fires,
> AND they probably need to look into who is starting all those fires in the
> first place (and stop them).
>
> After that, I would push for the todo list to be fully prioritized. New
> stuff would only enter at the top if it was truly more urgent and important
> than everything else already in the list. Presumably many/most new tasks
> would actually drop somewhere farther down in the queue, which would result
> in the imminent work becoming more stable and predictable.
>
> As a side note, task size could be significantly contributing to this
> problem. If tasks are days or weeks long, that greatly increases the odds
> of an emergency popping up before the current work is completed. I would
> look for opportunities to reduce the batch size to help work flow through
> the pipeline more smoothly.
>
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Mon, Sep 7, 2015 at 9:10 PM, Rob Lanphier <ro...@wikimedia.org> wrote:
>
>> On Mon, Sep 7, 2015 at 1:27 PM, Max Binder <mbin...@wikimedia.org> wrote:
>> > Everything is set at an equally high priority, with each upcoming task
>> > usurping the priority of the current task. There are no low priority
>> moments
>> > because stress of the upcoming tasks is the motivator to do the work. I
>> also
>> > do believe that context-switching is not limited to the traditional
>> phrase
>> > "multitasking," in that you can still do one thing at a time, but if you
>> > don't carve out capacity for preparing to do work then you can't execute
>> > when it is time to.
>>
>> Ah, I call that "being stuck in swap" (see the "Thrashing" article on
>> Wikipedia <https://en.wikipedia.org/wiki/Thrashing_(computer_science)>).
>> In software and in life, it's tempting to try to do too much, where "too
>> much" may well be "too much planning".  The software side of this problem
>> is very well studied, and there are capacity management solutions.  I'm not
>> familiar with an equivalent term to "stuck in swap" that applies to
>> planning, so I've used that metaphor liberally in the past.
>>
>> Perhaps that's still the "multitasking" metaphor that you're trying to
>> avoid, but I think that trying to plan the upcoming task at the same time
>> as executing the current task *is* a form of multitasking.
>>
>> Rob
>>
>>
>> ___
>> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] [Discussion] Term for always prepping for the next thing

[Max Binder]

Thanks, Rob. It sounds to me like this particular case is a lack of good
prioritization, and tasks that are different enough from one another to
feel like context-switching even when doing one thing at at time.

Everything is set at an equally high priority, with each upcoming task
usurping the priority of the current task. There are no low priority
moments because stress of the upcoming tasks is the motivator to do the
work. I also do believe that context-switching is not limited to the
traditional phrase "multitasking," in that you can still do one thing at a
time, but if you don't carve out capacity for preparing to do work then you
can't execute when it is time to.

In this case, I would say priorities need to be set, and time needs to be
made between tasks/meetings in order to get into the right mindset,
particularly if the tasks are quite different from an execution standpoint.

Were there a term for this...

On Sat, Sep 5, 2015 at 12:16 PM, Rob Lanphier <ro...@wikimedia.org> wrote:

> On Fri, Sep 4, 2015 at 1:27 PM, Max Binder <mbin...@wikimedia.org> wrote:
>
>> The future tasks matter, but so do the current tasks, and yet in order to
>> execute the next task, a sacrifice is made to current productivity.
>>
>
> I think the term you may be looking for is "analysis paralysis
> <https://en.wikipedia.org/wiki/Analysis_paralysis>".  It's not a perfect
> fit, but it seems reasonably close to what you're describing.  It's good to
> have a limited number of people in any particular organization focused on
> planning out "the next thing", but it takes a lot of skill on *everyone's* 
> part
> to ensure that the presence of that focus doesn't lead to organizational
> analysis paralysis.
>
> Rob
>
> ___
> 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] [Discussion] Term for always prepping for the next thing

[Max Binder]

Clarification:

When I get into "busy mode" I always focus and give priority to the future
> task. It's about getting through the whole day as opposed to focusing on
> the task at hand. So not exactly context switching, and not exactly tunnel
> vision--something in between both.
>
> It's the feeling of constantly saying "I have five minutes to do this and
> as soon is this is over, I'll have seven minutes to do this next thing, and
> I can begin prepping for that by doing x instead of y."
>
> I'm blind to what's going on because I have to focus on what is going to
> happen.
>
> It stresses me out instead of making me feel like I'm accomplishing
> anything.
>

I paraphrased it as "you focus less on the current task because the next
task is always distracting you."

I looked up "short termism" and I think it is kind of like the opposite of
that. Where "short termism" is essentially sacrificing long term for short
term gain (tech debt), this is sacrificing short term "presentness" by
context-switching on future tasks (not current ones).

Relatedly, speedy meeetings FTW.

"The thick of thin things" is also related, focusing on prioritizing, but
I'm not sure it's quite what this is.



On Fri, Sep 4, 2015 at 9:33 AM, Kevin Smith <ksm...@wikimedia.org> wrote:

> It doesn't sound the same as Endless Deathmarch, but I don't feel like I
> really understand the question yet. Can you elaborate on "always prepping
> for the next thing" aka "future blindness"?
>
>
>
> Kevin Smith
> Agile Coach, Wikimedia Foundation
>
>
> On Thu, Sep 3, 2015 at 4:43 PM, Max Binder <mbin...@wikimedia.org> wrote:
>
>> A question came to me from a friend, and I thought I'd pose it here for
>> discussion:
>>
>> Question for a scrum master: I know you call "multi-tasking" the far more
>>> accurate "context-switching," but do you have a real term for what I can
>>> only call "future blindness"? It isn't exactly tunnel vision that I've been
>>> having because I do think broadly (just not of the present) and my focus
>>> shifts all the time. But this always prepping for the next thing is driving
>>> me into ground. I need to call it something so that I can identify it,
>>> label it, and master it.
>>>
>>
>> Anyone know of any existing term to research? Kevin's kanban "Endless
>> Deathmarch" maybe?
>>
>> ___
>> 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
>
>
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

Re: [teampractices] Interesting article on over-communication

[Max Binder]

I think this is an interesting article in the context of folks who feel
thinking about process is a waste of time. Thinking about process is good,
and just getting shit done is also good. The nuance involved in striking
a balance is important to not lose sight of one or the other. I like that
this article approaches that nuance directly.

On Wed, Aug 5, 2015 at 4:44 PM, Grace Gellerman ggeller...@wikimedia.org
wrote:

 I thought that there were plenty of good ideas in this article from the
 Asana founders, so sharing here in the event that you might think so, too:


 https://blog.asana.com/2015/07/workstyle-communication-internal-memo-from-our-founders/

 ___
 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] [TPG/URGENT-ISH] Thoughts on Gerrit Cleanup Day

[Max Binder]

CCing Andre in case he is not subscribed :)

On Tue, Aug 4, 2015 at 12:08 PM, Kevin Smith ksm...@wikimedia.org wrote:

 Great notes. I don't see any red flags.

 I agree with Kristen's Friday concerns (while appreciating the concept of
 a fun day). And I agree that the wording will be very important, along
 with buy-in from managers.



 Kevin Smith
 Agile Coach
 Wikimedia Foundation



 *Imagine a world in which every single human being can freely share in the
 sum of all knowledge. That's our commitment. Help us make it a reality.*

 On Tue, Aug 4, 2015 at 11:50 AM, Kristen Lans kl...@wikimedia.org wrote:

 Overall seems fine to me, especially given that this is an experiment. As
 with all experiments, I wonder: how will you know you are successful? I see
 things like All open changesets submitted by *new* volunteers (as opposed
 to new changesets alone) in the last three months should have at least one
 review.. Probably be good to be really clear and explicit about what
 success looks like for this event in order to evaluate whether or not it
 will be an ongoing thing.

 One more feedback: depending on what time this starts, Friday can be
 tricky as SF AM on Friday is the start of the weekend for many
 international peeps.

 On Tue, Aug 4, 2015 at 2:08 PM, Max Binder mbin...@wikimedia.org wrote:

 *The Gellerman TL;DR:* Please check out this etherpad
 https://etherpad.wikimedia.org/p/GerritCleanupOrg and voice any
 thoughts or concerns by reply to this email thread, so I can relay that to
 the Phab epic https://phabricator.wikimedia.org/T88531 and AKlapper.
 Fairly time-sensitive, as AKlapper wants to start emailing the tentative
 plan this week, no later than Friday.

 Hello TPGers,

 Andre and I finally got together and had an engaging discussion this
 morning regarding organizing a Gerrit Cleanup Day (see epic:
 https://phabricator.wikimedia.org/T88531).

 This etherpad is the meeting notes:
 https://etherpad.wikimedia.org/p/GerritCleanupOrg

 As the TPG liaison to to this task, but not necessarily the steward, I
 would love if TPG could provide feedback to our 1:1. I channeled my inner
 Joel when trying to break down the goals of the day and defining done,
 and my inner Kristen with superior note-taking. :)

 Andre is hoping to start the scheduling process no later than Friday,
 and would like to draft emails to get line manager and community buy-in
 sometime early this week. Your thoughts and process-guru-ness are
 appreciated!

 Max

 ___
 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



 ___
 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] Make a tag for quarterly goals?

[Max Binder]

Hey Dan,

This has been an ongoing and as yet unresolved point of discussion with
some teams. There are concerns about goals-as-epics, from a long-term
process perspective, as well as overwhelming Phab with proprietary tags (a
problem that Bugzilla apparently suffered). Andre, Joel A, Kevin S,
Kristen, and I all chatted at some point about this on
#wikimedia-teampractices. While I can't say we found ultimate resolution,
we did decide that the simplest thing to do would be to use the Epic
project Tag, and apply it to goals-as-epics tasks.

Another thing to consider is Phab's Goal category. Joel and the VE team
are apparently going to experiment with that.

I wish I could better explain where we landed, but I am still wrapping my
head around it. Maybe one of the others could illuminate the issues more
clearly than I?

Max

On Wed, Jul 1, 2015 at 9:49 AM, Dan Garry dga...@wikimedia.org wrote:

 I'm creating epics to track the Discovery Department Q1 2015-16 goals
 https://www.mediawiki.org/wiki/Wikimedia_Engineering/2015-16_Q1_Goals#Discovery,
 and thought it might be useful to track organisation-wide progress towards
 achieving their quarterly goals by having such epics have tagging them as
 Q1 2015-16 goals.

 The epic tag already exists, but I would consider quarterly goals to be a
 strict subset of epics: all quarterly goals are epics, but not all epics
 are quarterly goals.

 Thoughts?

 Dan

 --
 Dan Garry
 Product Manager, 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

[teampractices] More helpful/interesting Agile and Scrum links

[Max Binder]

Our Director of Engineering is the in-house Agile guru, and sent us these
very helpful links via Collabnet. They are particularly helpful for those
new to Agile concepts.

Here is the 6 part scrum series:

Intro, Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, and
Retrospective.



[image: Introduction to Scrum]
http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm

Introduction to Scrum, Part 1.

http://scrumtrainingseries.com/Intro_to_Scrum/Intro_to_Scrum.htm





[image: Backlog Refinement Meeting (Backlog Grooming)]
http://scrumtrainingseries.com/BacklogRefinementMeeting/BacklogRefinementMeeting.htm

Backlog Refinement Meeting, Part 2.

http://scrumtrainingseries.com/BacklogRefinementMeeting/BacklogRefinementMeeting.htm





[image: Sprint Planning Meeting]
http://scrumtrainingseries.com/SprintPlanningMeeting/SprintPlanningMeeting.htm

Sprint Planning Meeting, Part 3.

http://scrumtrainingseries.com/SprintPlanningMeeting/SprintPlanningMeeting.htm





[image: Daily Scrum Meeting]
http://scrumtrainingseries.com/DailyScrumMeeting/DailyScrumMeeting.htm

Daily Scrum Meeting, Part 4.

http://scrumtrainingseries.com/DailyScrumMeeting/DailyScrumMeeting.htm





[image: Sprint Review Meeting]
http://scrumtrainingseries.com/SprintReviewMeeting/SprintReviewMeeting.htm

Sprint Review Meeting, Part 5.

http://scrumtrainingseries.com/SprintReviewMeeting/SprintReviewMeeting.htm





[image: Sprint Retrospective Meeting]
http://scrumtrainingseries.com/SprintRetrospectiveMeeting/SprintRetrospectiveMeeting.htm

Sprint Retrospective Meeting, Part 6.

http://scrumtrainingseries.com/SprintRetrospectiveMeeting/SprintRetrospectiveMeeting.htm
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices

[teampractices] Macro-measurement whitepaper, a video on what motivates people, and tight feedback loops

[Max Binder]

Sorry for the endless subject line! I thought it might be nicer than a
bunch of separate emails.

Here are a couple of the links that Collabnet recommends, via the videos
I sent in another email. I thought these were particularly worth
highlighting.

Macro-measurement:
http://scrumreferencecard.com/MacroMeasurementWhitepaper.pdf

One of my college's psych professors, Dan Pink, talking about motivation:
https://www.youtube.com/watch?v=u6XAPnuFjJc

Also, not sure if this has been sent around before, but I think it is worth
a look for those interested in examples of tight feedback loops. From
Nordstrom's Innovation Lab, where they make an iPad app in one week:
https://www.youtube.com/watch?v=szr0ezLyQHY

Have a great, Agile-y day. :)
___
teampractices mailing list
teampractices@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/teampractices