Wikimedia Apps/Team/Platform Split Proposal

Overview
The apps team has has grown large enough to where project management has become more difficult. This proposal suggests that the current team be split into one iOS team and one Android team.

Problem Statement
Various team members have raised concerns about the following:


 * 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

Proposal
Given that all the prior concerns are motifs on a "platform" theme, we propose that the team be split along platform lines.

Advantages of platform-oriented structure

 * Allows platforms to prioritize features and maintenance work in a way that makes sense for the end users of the respective platforms
 * Allows each team to be flexible in how they allocate resources towards feature/mainatanance work on a sprint by sprint basis
 * Allows engineers to work closely with the other engineers who are working in the same code base
 * Encourages UX experimentation with platform specific conventions and technologies
 * Does not increase the amount of meeting time for the PMs, Designers, scrum master, or QA
 * Reduces the amount of meeting time for engineers
 * Reduces the amount of "dead time" for engineers in meetings (i.e when discussing platform specific issues)

Desired outcomes
In addition to addressing the aforementioned concerns, we hope to:
 * Reduce total time spent in meetings while improving focus
 * Streamline planning and estimation
 * Facilitate collaboration between engineers and product during planning & prioritization
 * Improve project management process 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

 * It may be more difficult to sync feature work across platforms.
 * How well will platform engineers working on features sync with each other?
 * Should the apps be treated as one product or two?
 * When do we do bug triage? Should this be a new meeting?

Team Composition

 * Create 2 teams along platform lines:
 * iOS
 * Android
 * Teams will share a PM, designer, QA, and scrum master resources

Schedule

 * Maintain current meeting schedule, but bisect them along platform lines
 * Reschedule Standups as daily 10 minute meetings and then bisect
 * PM will meet with both Tech Leads in a single meeting for story prioritization

Inter Team Communication

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

Project management

 * Quarterly goals will be collaboratively developed by each platform team
 * iOS and Android design boards will be divided into 2 separate boards
 * iOS and Android backlog and sprints will be seperated into seperate Phabricator projects

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)