Talk:Wikimedia Apps/Team/Platform Split Proposal

Discussion of desired outcomes
I find a lot of these desired outcomes to be very vague, and I actually disagree that the platform split proposal even causes some of these benefits. I'd also note that a lot of these benefits are for us as a team, and given that the tradeoff is that we lose our focus on a single-user group and have overheads there as compared to a feature split, I'm sceptical of this proposal. --Dan Garry, Wikimedia Foundation (talk) 20:57, 24 February 2015 (UTC)


 * Dan are you concerned with the platform team split as proposed here or in general? I don't feel like the problems you are raising (e.g. "we need to maintain focus on a single user group") are identified in the problem statement here, and I wonder if it would be useful for you to add them so that we can better evaluate the impact that this model would have on those problems. I also wonder if it would be useful at this point to draft up a feature split proposal so that we can better compare how each model would respectively solve the problems we have identified. KLans (WMF) (talk) 23:24, 24 February 2015 (UTC)

To be honest, I wasn't entirely happy with that section either. The main "desired outcome" of the proposal is to solve the issues highlighted in the problem statement (which were paraphrased from the meeting we had on Monday). The others came out of things we also thought would be improved as a result of this split—byproducts, as it were. Admittedly, some of them might have leaked in from other process-related issues that could use a separate discussion, but aren't directly related to the team split. That being said, I'll respond to your comments below, and you can reply here on whether or not we ditch that section. BGerstle (WMF) (talk)


 * I agree that the desired outcomes should map to the problems that have been identified. I'm going to start a new section to discuss :-) KLans (WMF) (talk) 22:25, 24 February 2015 (UTC)

Streamline planning and estimation
This is a benefit of splitting, irrespective of whether it's a feature vs platform split. Additionally, since the tech leads of both teams will be required to be up-to-date the advancements from the other team, whether the split is around feature or platform is irrelevant. --Dan Garry, Wikimedia Foundation (talk) 20:57, 24 February 2015 (UTC)

If it's a benefit of splitting in general, why can't it be listed as a benefit of splitting into platform teams? BGerstle (WMF) (talk)

Improve collaboration between engineers and product during planning & prioritization
This is pretty vague. How? --Dan Garry, Wikimedia Foundation (talk) 20:57, 24 February 2015 (UTC)

Looking at this now, it's actually redundant compared to the "streamlining" outcome, I think we should remove it. BGerstle (WMF) (talk)

Improve project management efficiency
How? We currently operate separate sprint boards for both teams, so what project management overhead would this reduce, and who would it reduce it for? --Dan Garry, Wikimedia Foundation (talk) 20:57, 24 February 2015 (UTC)

One of the main issues we're trying to address is spending less time in meetings. If we can spend less time in meetings as a team and get the same amount of work done—or more—than we've improved efficiency. As described in the scheduling section, we imagined that the split would entail leaving the majority of our meeting skeleton intact, with some meetings being shortened (standup) or involving fewer people (i.e. tech leads only for cross-platform discussions). As a result, everyone should be spending less time in meetings, although PM & scrum masters having the same amount of time in meetings.

Increase clarity around our goals for the quarter and from sprint to sprint
This has nothing to do with the platform vs feature team split proposal. If teams are split, then detailed goals will be laid out for those teams and they'll be clear for each individual team. In fact, I think the platform split will decrease clarity around goals, because the teams will be trying to serve multiple users at the same time (e.g. readers and editors) so there will be a lack of clarity around how those two user groups are weighed against each other. --Dan Garry, Wikimedia Foundation (talk) 20:57, 24 February 2015 (UTC)

I believe Kristen added this point originally. I'm guessing it has something to do with having backlogs & sprints that are more custom-tailored to each platforms' quarterly goals as opposed to having two platforms attempt to achieve the same goals while also addressing platform-related issues. BGerstle (WMF) (talk)

Improve trust in our ability to self-organize and execute on a plan to deliver user value at a competitive pace
Is this perceived to be a problem now? I'd appreciate some details. --Dan Garry, Wikimedia Foundation (talk) 20:57, 24 February 2015 (UTC)

I forget everyone who played a role in crafting this one, but I added the last bit about executing at a competitive pace. Not strictly saying it's a problem now, but that the platform split could help us gain a sense of awareness for how we're doing on iOS by strengthening platform focus. BGerstle (WMF) (talk)

Establish and maintain a sustainable planning and working rhythm
This is too vague for me to know what this means. Can some explanation be added? --Dan Garry, Wikimedia Foundation (talk) 20:57, 24 February 2015 (UTC)

Should have added "for each platform." In other words, tune our planning and velocity to match that platform's available resources. BGerstle (WMF) (talk)

Rethinking desired outcomes
Some problems we're trying to solve:

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
 * associated outcome: Meeting time is focused on topics relevant to attendees.
 * associated outcome:
 * associated outcome: Platform work is discussed, evaluated, and prioritized alongside user-facing work.
 * associated outcome: Estimates can be made closer to the time of implementation when there are more "knowns", resulting in better accuracy and reducing the waste of having to reestimate a stale feature.
 * associated outcome: Each teams' estimates are more accurate and comprehensive (e.g. include the full cost of getting the feature released on a given platform).