WMF product development process/Proposal

=Concepts= We can consider Foundation development work within several, complementary models:

Input, Output, Outcome
With planning and oversight Input can be controlled fairly directly. Outputs can be prioritized and forecast. Outcomes, the changes to the world as a result of the Outputs, but also affected by factors beyond our control, can only be affected indirectly. This model is somewhat fractal in its application: it can give some understanding of a multi-year process, and also of one-hour task. '''We define success by Outcomes, but Outcomes are only indirectly caused by Inputs and Outputs. '''

People, Process, Priority
In this model, People (and money and time and other resources) are the primary input to the process, and Product is the primary output to Product. Prioritization affects all of these. All of these activities are interdependent and overlapping, so this is more of a high-level conceptual model that doesn't necessarily translate to specific daily activities. Changing all areas of WMF's product development process may be a self-defeating approach, so we may want to pick one area to focus on. However, we can't fully isolate any area from the others.

Fixed Teams vs Variable Teams
In the fixed-team model on the left, each team has a fixed composition, and work is parceled out to different teams. In the ad-hoc team model on the right, teams are tied directly to projects, so as a project expands, the team expands. A benefit of fixed teams is that, since teams develop trust and common language and understanding over time, stable long-term teams may be more productive than volatile teams. However, they may be slower to adapt to changing product needs.

In Engineering, WMF uses fixed teams in "verticals", each with their own area of focus. So a team may take on several projects in series or parallel, and most of these projects cannot be moved between teams. Many other, "horizontal" teams in the Foundation support Product work, for example Design Research, Communications, and Community Liaisons; this happens both by horizontal people being embedded in Engineering teams, and by horizontal teams doing project work for multiple verticals.

The process of assigning a person to a project in a variable-team model has the equivalent, in a fixed-team model, of getting a team to accept a new project.

One List


Teams can have many different sources for work, such as high-level goals, product requirements, functional specifications, emails, community feedback, in-person requests, and Scrum story backlogs. A team with multiple contradictory lists cannot prioritize effectively, and may waste extra time on context switching. Consolidating to one stack-ranked list forces tradeoffs to be explicit, which will disappoint some stakeholders.

Most Engineering teams maintain a backlog of tasks in Phabricator. However, this may not capture all of the requests from diverse sources that a team is considering, anticipating, or surprised by.

Since a team, or even a single person, can do more than one thing at once, a team can work on more than one thing on a list at once, but it is still useful to maintain a stack-ranked list to help the team stick to lower, more efficient levels of work-in-progress.

Maintenance vs New Feature
The Foundation can categorize work by maintaining existing products and services for the movement versus creating new products and services. See Team_Practices_Group/Measuring_Types_of_Work. Each Engineering team devotes a varying proportion of its effort to maintenance versus new functionality.

The landscape of possible work
The Maintenance vs New Feature dichotomy is complicated by the fact that it's not always obvious what will and will not succeed. The Foundation can categorize projects as: The graphic below very roughly illustrates this concept; in particular, imagine that the landscape is mostly invisible so that new projects don't initially know if they are in a hill or a valley.
 * capitalizing on existing success. For example, adopting a proven technology to reduce downtime.  Investing $1million to reduce an annual bill from $2m to $1.5m.
 * exploring new possibilities. For example, researching and experimenting with three different new technologies to see which might reduce downtime.
 * Expanding on a new feature to see if it's as effective at is seems like it should be.

Timeboxing vs feature boxing
Timeboxing is a prioritization technique in which a project is given a fixed amount of time. Whatever is complete by the end of the time period is released if it meets minimum release criteria. A decision is then made whether to proceed for another fixed time period, and if so, with what priorities.

Feature boxing is the opposite, in which a project is continued until all necessary features are complete; thus, the time to complete a project can only be predicted, not specified.

It is not generally possible to guarantee both a feature set and a time, even if resources are unconstrained. This is like guaranteeing an outcome; we can make a prediction that supplying a certain input is very likely to produce an output leading to the desired outcome, and we can become arbitrarily certain (60%, 99%, 99.9%) by selecting inputs that forecast to a high level of confidence, but the cost increases dramatically for higher certainty.

Product Lifecycle


Software development work comprises fairly consistent and distinct phases, each with a different character: Initiation, Development, Release, and Maintenance. Closing is also often considered a standard phase.

Each of these phases has specific typical work and involves different people with different skills and experience in different proportions.The number of people that can contribute efficiently to a product varies consistently through the phases. For example, only a few people can productively work on a product in initial phases, doing work such as product definition, demand research, prototyping, and exploratory design research. The mix of engineering teams, non-engineering teams, and Movement participation also varies by phase. If a new product or service is released and succeeds, this will likely permanently increase the staffing needs of the Foundation.This model remains useful even as product sizes change dramatically.

Definition
A milestone can be used to organize work. A typical software milestone has Success Criteria, which are the conditions under which the milestone is achieved. Each success criterion indicates who (person and team) are responsible for judging it.

As a nexus of functionality, priority, and people
The people who decide the definition of a milestone (the success criteria and their judges) may be different from the people who judge the success criteria. The people who complete the work to achieve a milestone may differ from each of the other sets of people.

Bootstrapping with Milestones


A Milestone can be used to bootstrap into a process that otherwise seems circular or contradictory. Example 1: Initiate milestone that proves next 2-4 milestones. Example 2: Pull a medium-sized project bundle off the shelf and see resource assignments for next 5 months.



Bundles
Milestones can be re-used for work of similar scope. They can be sequenced and grouped.

compatibility with common processes
Milestones are used in most common software development processes. Each waterfall project is defined completely by a set of fairly standard milestones (such as Requirements Complete, Design Complete, Code Complete, Testing Complete, Alpha Released, Beta Released, Final Released). In Scrum, milestones are used in the product backlog, one level higher than Scrum backlogs, to group and prioritize stories. Milestones can be stretched somewhat to define maintenance work, e.g., "Milestone: The servers stayed up with 99.9% uptime in Q3."

Libraries of Milestones
A library of reusable milestones would use some metadata to identify and group milestones and match them to new needs. =SPDPP Process=

Unsorted
=Challenges with WMF Engineering=

Prioritization
Teams set their own backlogs, filtered by product people. The range of inputs spans bottom-up (community tickets) to top-down (quarterly goals). Adding work to a backlog is the de facto way of assigning WMF resources to a task, so that’s a bottom-up, semi-organic process. For most teams, that goes through a Product Manager or team lead, synthesizing many inputs from many levels of hierarchy.

A team accepting work into the backlog is the bottom-up equivalence of WMF assigning the people on the team to tackle the work. But teams petition for permanent and temporary people, which is a top-down process. Neither process is perceived as consistent, accessible, or transparent.

Teams are juggling new work and maintenance.

Work assignment doesn’t align very well with resources

=Proposed Solution=