= Session=
* Track: People and Processes
* Topic: Best practices & useful methods for remote teams - volunteers and staff alike
=Description=
The intention for this session is to create a space to share openly best practices and methods for remote teams. It will focus less on the specifics and constraints of any particular org or group setup and instead discuss what experiences and outcomes we're trying to improve in an idealised setting. Building from this into how tools, approaches and methodologies could be employed to support our work and collaborations as well as the experience of the team and the individual.
The session will focus on collaborative work in remote teams touching on areas such as team setup, communication strategies, workflows, planning, resource estimation and delivery.
Will Doran will provide a brief intro to the history of process on the Core Platform Team, what the team is currently trying as well as its successes and failures.
Neslihan and Vivek will provide an overview of how the Commons Android App project coordinates their team.
=Questions to answer and discuss=
**Question:** Who are the primary collaborators within remote teams?
**Question:** What are the goals that teams are optimising for?
**Question:** What elements should be taken into account when deciding on communication processes with a team? How should communication be adapted for a team?
----
=Notes document(s)=
https://etherpad.wikimedia.org/p/WMTC19-T234658
=Notes and Facilitation guidance=
https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation
----
=Session Leader(s)=
* @josephine_l
* Neslihan
* Vivek
* @WDoranWMF
=Session Scribes=
* Nick
=Session Facilitator=
* Aubrey
=Session Style / Format=
* Two very short presentation from the Commons Android Team and the Core Platform Team followed by breakout groups and discussion
* The participants will be asked to split into 3 groups each taking 1 question.
* Within each group each member will quietly reflect on the question for 1 minute
* Next members will pair up and discuss between themselves for 2 minutes
* Finally the group as whole will discuss and try to converge on a reduced set of answers
* Each group will share back their thoughts and outcomes
* There will be space for questions and further points based on the share back
* Define next steps for moving forward
----
**Session Leaders** please:Post-event summary:
* ...
Post-event action items:
* ...
----
Wikimedia Technical Conference
Atlanta, GA USA
November 12 - 15, 2019
Session Name / Topic
Best practices and useful methods for remote teams - volunteers and staff alike
Session Leader: Will; Facilitator: Aubrey; Scribe: Nick
https://phabricator.wikimedia.org/T234658
Session Attendees
Piotr, Sam, Joaquin, Niharika , Elena, Addshore, Kaldari, Cormac, TheDJ, Aubrey, Rachel, Greg
Notes:
* Who are the collaborators within a remote team?
* What goals are the team optimizing for?
* What things should be taken into account when deciding on communication processes? How should communication be adapted for teams?
* How are we accomplishing our work and better supporting others?
* Essentially: A lot of work improving our: Roadmap, Pipeline, Planning, and Process
* Roadmap:
* Derived from Annual Planning
* updated monthly,
* ...
* Roadmap screenshot - uses [roadmonk?] software
* CPT Pipeline
* Divided into reactive, planned, support, ???
* Once we have an engineering task, goes to deployment.
* what was confusing was how to deal with work as it comes in.
* Built a big CPT pipeline - split between reactive and planned [visualization of pipeline shown]
* Initiative planning, Development planning,
* Process uses agile concepts of initiatives, epics and user stories.
* Two cross functional feature teams : Green and purple
[] Add more details to this task description. * lead by PM
[] Coordinate any pre-event discussions (here on Phab, IRC, email, hangout, etc). * Daily standups
[] Outline the plan for discussing this topic at the event. *
[] Optionally, * Clinic duty team
* Reaction to requests that come to our team for code review, or codebases we've become responsible for
* Purpose to deal with UBN (unbreak now) issues. include what this session will //not// try to solve.Inbox on phab,
[] Update this task with summaries of any pre-event discussions. * Process: tag a task with #core-platform-team -- triaged daily
* Working towards providing SLAs around support
* Working on metrics and impact
* Challenges
* Finding the right cadence for standups across timezones
* setting up right level of user stories
* support tools
* communication styles
* ??? task types
* Commons Android App team process
* Overall
* Small team, so different needs and habits.
* We avoid over engineering, use minimal set of tools
* Small but relatively strict set of procedures
* Meetings are difficult, part-time and different timezones -> lots of async communication
* Planning
* Annual goals (based on grant tasks)
* Tracking pending tasks
* Facilitators
* github wiki for documentation for newcomers
* github bots - test checker, deleting unused branches, closing solved issues.
* tagging issues as beginner-friendly, bugs, help-wanted
* travis CI for automated builds and alpha releases of every commit to master
* Communication
* Switched to Zulip from Hangouts
* using templates for pull requests to create and review faster
* Cautions
* keeping collaborators (members with review and merge priv) narrow
* Don't merge your own PR
* wait for all automated tests to pass before merging any PRs
* Human Relationships
* Remember to add motivating words on reviews, lots of "good job" when appropriate
* encourage first time contributors
* try to get interns when we have available mentors
* Question:
* what do you mean by "goals teams are optimizing towards?"
[] Include ways for people not attending to be involved in discussions before the event and afterwards * Could be throughput, collaboration, code-review, support from team-members, ... At the level of the team itself. What are the different elements/directions the team is pushing towards.
* e.g. our team is optimizing towards knowledge sharing. Individual knowledge experts, with no free time to share that knowledge. I.e. de-siloing.
----[individuals write down.]
* Who are the collaborators within a remote team?
* people you work with all the time
* designers, PMs, QA, etc
* other stakeholders
* active - external consultants
* between - volunteers, readers, admins, external FOSS orgs,
* between - reviewers translators contributors
* passive - onetime users, helicopter people
* What goals are the team optimizing for?
* throughput
* pae [?]
* efficiency
* time to development
* optimized time
* risk management
* fear of not breaking things slows us down
* good team morale
* minimize frustration, from not being efficient
* effective collaboration
* What things should be taken into account when deciding on communication processes? How should communication be adapted for teams?
* differences
* every one is different
* different primary languages
* define words differently
* different experience - newcomers, junior/intermediate, experts -- especially a problem with jargon / acronyms / inside jokes / historical references
* cultural differences - things sound good/bad to different people
* audience - informal/formal, and channels (phabricator, slack, etc)
* Set expectations
* hold folks with influence to them
* each team has different history of communication, some good some bad.
* some have different rules of communication - e.g. asking everyone to acknowledge having received a message, perhaps with an emoji-reaction (gchat or slack), so that an announcement/comment isn't met with pure silence or a single comment.
* searchability of previous discussion is important -- good for newcomers, and good for consulting what you discussed a long time ago.
* timezones
* synchronicity
* sync (but only 2 hours window of real overlap between western-US/EU timezones)
* async (and have to wait hours for a response)
* also tooling - too many communication channels (or platforms) overwhelm, but insufficient/inadequate channels (or platforms) make communication frustrating
Post-event summary: * Action Items
* .. * Rotate meeting times
* our team became more remote than before, so decided to rotate the meeting times, so early in the morning one week and late the next, makes life happier for
* Bonding / Get to know team members / check-in questions
* building bonds between people - deciding when to 'bother' people with human interests (books, hobbies, life, etc). Every Monday we ask a question on [platform], and answer over the week -- not work related but it helps build bonds between teammates.
* Virtual coffee
* We organize coffee sessions between remote people, or volunteer to be in the pool of people. Just hangout and have a chat.
* Have to be careful it doesn't turn into a work discussion
* timezones:
* Weird that we don't organize teams by timezone.
* Document procedures -- gitlab's team's docs are collaboratively written, give clear instructions on where/how/when to contact people
* uber has something similar
* Have clear "start/end" times for events.
* Because "all day events" can last for 50 hours for people in far off timezones.
Post-event action items: * Next steps:
* ... * collate these ideas in phab, organize them onwiki, improve our best practices universally!
---------------------------
General instructions
This sheet is for scribes and participants to capture the general discussion of sessions.
1. Note-taker should go for a more ‘pure transcription’ mode of documentation
2. Don’t try to distill a summary of the core details unless you're confident in your speed.
1. All note-takers should try to work in pairs and pass the lead-role back-and-forth when each speaker changes.. Help to fill in the gaps the other note taker might miss.
2. When you are the active note-taker in a pair, please write "???" when you missed something in the notes document.
2. If a session only has one note taker present, feel free to tag a session participant to help take notes and fill in the gaps.
1. In your notes, please try to highlight the important points (that are usually unspoken):
2. INFO
2. ACTION
2. QUESTION
1. It’s also good to remind session leaders, facilitators and participants to call out these important points, to aid in note taking.
1. Sessions might have activities that will result in drawings, diagrams, clustered post it notes, etc
2. Please tag a session participant to capture these items with a photo and add them to the Phabricator ticket.
1. Some sessions might have breakout groups which means that there will be simultaneous discussions.
2. Session leaders should direct each group to appoint a scribe to take notes (in this document).
1. At the end of each day, notes and action items will need to be added into the related Phabricator ticket (workboard: https://phabricator.wikimedia.org/project/board/4276/ ) for each session
2. This can be done by any and all conference attendees.
1. Additional information about note taking and session facilitation: https://www.mediawiki.org/wiki/Wikimedia_Technical_Conference/2019/NotesandFacilitation