Wikimedia Apps/Team/Platform Split Proposal

Overview
The apps team has grown significantly over the past few months. Because of this, meetings and coordination are taking longer and are more difficult. To solve these issues, this proposal suggests that the current team be split into one iOS team and one Android team, with both teams sharing PM, design, and scrum master resources.

Problem statement
In particular, team members have raised the following concerns:


 * Meetings often focus on only one platform's engineers at a time
 * Cross platform concerns bog down too many discussions
 * Platform-specific work (e.g. technical, non-functional requirements) isn't discussed due to focus on getting a single estimate for a feature across platforms
 * Platforms end up estimating on story requirements that won't end up being immediately worked on, leaving the requirements vulnerable to change which would obviate the previous estimation
 * Estimation scores vary a significant amount across platforms

Proposed solution
Given that all the prior concerns are motifs on a "platform" theme, we propose that the team be split along platform lines. This will allow each team to:


 * Prioritize features and maintenance work in a way that makes sense for the end users of the respective platforms
 * Allocate resources towards feature/maintenance work on a sprint by sprint basis
 * Facilitate platform maintenance and improvements
 * Does not increase the amount of meeting time for the PMs, Designers, scrum master, or QA
 * Spend less time in meetings
 * Fully participate in each attended meeting (i.e. limit idle time while discussing different platforms in the same meeting)

Implementation
What follows are concrete steps for how to implement the spilt and how our process will be affected.

Scheduling
In general, we will maintain the current meeting schedule, but bisect it along platform lines. Some meetings will be modified slightly:
 * Stand-ups should be done on a daily basis, but shortened to 10 minutes total (i.e. 5 minutes per platform)
 * Story prioritization can still be cross platform, but only involve PM and tech leads
 * Since stand-ups will be shortened, bug triage should have its own meeting (per platform). We suggest doing it weekly in preparation for story prioritization.

Inter-team communication

 * Engineers working on the same feature will synchronize on an as-needed basis
 * Tech Leads will sync together and with the PM as needed
 * Design will sync internally to maintain brand image across platforms

Project management

 * Quarterly goals will be developed separately by each platform team, in collaboration with product, design, etc.
 * The current, cross-platform design board will be divided into two platform-specific boards
 * Each platform will have its own planning group (e.g. Trello board, Phabricator project, etc.)

Desired outcomes
In addition to addressing the aforementioned concerns, we hope to:


 * Streamline planning and estimation
 * Improve collaboration between engineers and product during planning & prioritization
 * Improve project management efficiency
 * Increase clarity around our goals for the quarter and from sprint to sprint
 * Improve trust in our ability to self-organize and execute on a plan to deliver user value at a competitive pace
 * Establish and maintain a sustainable planning and working rhythm

Weaknesses and unknowns
While we think splitting along platform lines is a promising idea, there are some things we need to consider:


 * Syncing feature work across platforms
 * How this split will affect the idea that the mobile apps are 1 product
 * As compared to smaller teams, must either focus only on one user group (increasing depth of product backlog, requiring more overhead from product and design) or focus on two different user groups (losing single user-centred focus)
 * Increased overhead for product in communicating the same product ideas to both platform teams, then coordinating discussions that critique those ideas

Metrics
We will test this solution for a period of two sprints. Afterwards we will use the following criteria to measure success and failure:

What success looks like

 * Sprint velocity increase from pre-split sprint velocity
 * More frequent app store updates (ideally at least once per month)
 * More frequent beta builds (ideally at least once per week)

What failure looks like

 * Sprint velocity decrease from pre-split sprint velocity
 * Team member burnout (as reported in sprint retrospectives)
 * Team member uncertainty about responsibilities (as reported in sprint retrospectives)