Growth/Team/Norms

This page is intended to document the Growth Team's norms and ceremonies. Team ceremonies for Growth is defined as a series of acts and processes performed regularly with the intention of creating an environment that promotes iterative improvement, innovation and productivity.

On this team, process is not intended to become performative, rather it is intended to provide the needed structure to:


 * Improve Iteratively; Learn and Adjust
 * Experiment
 * Fail Fast
 * Reflect
 * Collaborate
 * Share Knowledge, Wins & Lessons
 * With Each Other
 * Our Communities
 * The Foundation
 * Set and Meet Goals
 * Adding Value/Priorities > Scope
 * Wikimedia Foundation Annual Plan
 * Short and Long Term

Team ceremonies can be altered if it is collectively determined after trial they are not effective as is. Plans and goals are set as a baseline and something to strive towards. Plans and goals if not met should not result in condemnation or negative tones. Not meeting plans and goals should be viewed as an opportunity to learn what needs to be adjusted, rather it is process, priorities, scope or expectations.

Standup & Team Discussions
Traditionally, Scrum-style standups are at the start of the workday, and are meant to


 * 1) Serve as the first line of defense against wasting time. Specifically, this is the tightest feedback loop a team has as a group.
 * 2) Motivate the team through shared commitment.

This is generally accomplished through 3 classic questions:


 * What did you work on yesterday?
 * What will you work on today?
 * What is blocking you?

The Growth team, like many teams at WMF, uses a modified version of this approach, due mostly to the fact that the team is widely distributed across the world (and thus each person is on a different schedule). Synchronous time has a different meaning (e.g. the start of one day may be the end of another, even if there is overlap), and is precious (i.e. should only be used when necessary). The team modifies their standup as follows:


 * Synchronous (video) standups occur every Wednesday. The team may also standup attached to another meeting.
 * Typically, sync standups are 15 minutes and cover blockers.
 * Standups are generally an opportunity to share progress on work, raise tasks that could potentially impact others, or to escalate blockers that impede team productivity.
 * Topics that need to be explored in depth are held until discussion times on Mondays or Tuesdays, or ad-hoc, as needed.

Often, the team will cope with wide geographical distribution by assigning "homework," to mitigate the need for synchronous meetings. This will often take the form of a pre-recorded video or slide deck, which members of the team will watch ahead of a meeting to discuss it. The team agreed (at their retro on 2020-12-14) that the minimum time to get homework ahead of such a meeting is 2 days, not including the day the video was sent and the day the video will be discussed. The team refers to this as the "2-day Sandwich Norm."
 * Asynchronous standups occur via Slack.
 * Mode of communication
 * Async updates should be added in a form of a new message (not a thread) to the private #growth-standup Slack channel
 * Content
 * Team members are expected to answer the following questions:
 * What did you work on since the last standup update?
 * What are your goals for today (can be high-level if you are planning a lot of smaller tasks for today)?
 * Any blockers? (Make sure to tag the person who can help you to get unblocked)
 * Cadence of updates
 * Daily (Monday-Friday) for Engineers, QA Engineer, and Designer
 * Weekly for CRS, Engineering Manager, Product Manager, Design Researcher, Data Scientist
 * Timing of an update
 * For daily updates, at the beginning of each working day
 * Team members should set up their individual (using the tool of their choice) daily reminders at the beginning of their working day to not forget about posting the standup update
 * If you want to use Slack, you can type a prompt in like /remind me to post my standup update every weekday at 9 AM
 * For weekly updates, by EOD of the first working day in a given week

Board Triage
Phab board triage occurs asynchronously. It is done by engineers as part of the daily chores process.

Planning Meetings
Planning Meetings are weekly meetings attended by the team on Mondays. During the planning meeting, the team identifies and prioritizes tasks that are to be completed for the next 1-2 weeks. Tasks prioritized for the upcoming month are to be represented on the Current Sprint board.

Retrospective Meetings
Retrospective Meetings (retros) are bi-weekly meetings attended by the team every other Monday. During Retrospectives, the team revisits action items from the last retrospective and reflects on the past two weeks progress by collectively answering the following:


 * Did we meet our acceptance criteria?
 * What have we accomplished?
 * What worked?
 * What could we improve next time?
 * What was confusing?

Action items will be captured during the meeting and due dates and action owners will be assigned.

Google Calendar
New members of the team will be added to the Growth team calendar. If a team member will be out of the office for four or more hours during a working day, they are to share it on the team calendar at the earliest indicator that they may be out. This practice will help the team manage expectations when estimating what work can get accomplished during planning. Team ceremonies will also be represented on the Google Calendar.

Gerrit
The Growth team uses Gerrit, a code collaboration tool, for peer code review.

Phabricator
Phabricator is the organization’s task/issue tracking tool that houses the Growth team’s user stories, tasks, progress and prioritization of work. Tickets at the top of the Ready for Development column in the Current Sprint Milestone are considered the highest priority and next up in the queue to work on.

Translations
Our software contains hundreds of text strings. We rely on volunteers and Product Ambassadors to translate these texts into various languages, and want to reduce the burden of translation as much as possible when adding new texts. In order to do so, we will:


 * 1) Create a "finalize messages and qqq.json" task for an epic. For a given epic of work, there should be a task to finalize messages. In this task, we will make a patch to finalize the copy for en.json and the qqq.json.
 * 2) Allow 7 days for translation. Once the text strings are finalized in step 3, we should allow for at least 7 days before enabling the feature for wide use. That allows ambassadors and volunteers time to translate the text. Examples:
 * 3) If the messages are finalized on Tuesday, after the branch cut, then the feature using these messages should not be enabled for broad use until the following Thursday, at the earliest.
 * 4) If the messages are finalized on a Friday, the messages should not be enabled for broad use until 13 days later, on Thursday (group2 deployment) at the earliest. That's because the translators would only have Saturday/Sunday/Monday to get translations done in time for the next week's train.

Updating an existing message

 * Once your change is merged, consider that the old string will remain in place in production until it is newly translated. Make sure the overall meaning and intent of the string does not change.
 * Give translators time to make their updates, by merging the patch on a Tuesday, for example, so there are 6 days until the next branch cut.