Core Platform Team/Development Practices/10% time

From mediawiki.org
Jump to navigation Jump to search

Purpose[edit]

The Core Platform Team will intentionally set aside 10% of our work time to actively work on novel ideas that are not necessarily directly related to our on going core projects. Our intention is to create space for both innovation and exploration of ideas that can lead to the next evolution in tools, services and concept for our space as well as self-enclosed but important work that isn't captured by our core projects. Equally, the time can be used for exploring professional growth objectives.

The 10% time is available to all members of the team - not just Engineers but everyone. Engineering Managers will be responsible for supporting the time for their Engineers and for all others the time should be supported by their direct managers.

Not all ideas or efforts are expected to lead to new tools or services but those that reach a level of viability should be considered when planning future work for the group as potential new directions to ensure there is a pathway from ideas to implementation.

A key goal of this practice is to provide space to try out solutions that may or may not be viable at all and to allow time for research or experiments.

For the initial trials of 10% time, we've defined two types of idea; Quick and Open Ended. Quick ideas are small, self-enclosed pieces of work that team members would not otherwise have to time to work on. Open Ended projects are oriented toward more exploring new solutions.

Principles[edit]

  • 10% time is available to all members of the Core Platform Team
  • Direct Managers and Engineering Managers are responsible for ensuring that the time is taken into account during sprint and project planning to protect this time and prevent it from being de(re)prioritised or co-opted
  • Core Platform Team members who want to take part in 10% time should follow a process of:
  1. Develop an abstract proposal in the case of longer term projects or identify a list of self enclosed tasks
  2. Invite input from colleagues within and across teams
  3. Where appropriate they can work together on pair projects or individually
  4. Present a monthly demo presentation on progress to share back and seek further review
  • During yearly planning, where appropriate, the Core Platform Team should consider 10% ideas that have reached a level of maturity in terms of whether they can become viable full time projects for the next FY

Size[edit]

The 10% project is not limited to large, long range ideas it is equally valid to use the time for small, once-off or targeted working intended to improve our existing applications, tools and infrastructure.

Quick projects should be short, self-enclosed pieces of work that can be encapsulated in individual task or list of tasks.

Longer project should be described via a proposal and seek review from colleagues.

Cadence[edit]

10% time is roughly 4 hours per week or 2 days per month. The project would likely benefit from planning but, at least initially, may likely involve random exploration and research.

How the time is divided up, in relation to sprints, should be discussed with an Engineering Manager to ensure they can adequately protect and provide space for the work but in the first iterations of the approach is not dictated.

If you are using 10% time, blocking off time on your calendar is the most effective way to ingrain the time and to help protect it.

Potential Pitfalls[edit]

Context Switching[edit]

It can take significant time to context switch from core work to 10% ideas, in some cases the switching load may eat into a significant portion of the allotted time. It may be better in our first trials of 10% time to focus on smaller projects that are less research heavy but we won't proscribe that.

Dependencies[edit]

Generally, it is better to avoid or reduce reliance on other teams who may only be available infrequently. Larger scale projects that involve other teams can often kill 10% projects where priorities do not align across teams. If projects become or are likely to be blocked externally the Engineering Manger should be responsible for negotiating support from other teams early on. In the long term, we can work to encourage cross team 10% projects.

Guide[edit]

Quick

  • Propose a list of self enclosed items to be worked on
    • If possible link to set of Phabricator Tasks
  • Tag Team Members you would like to review your idea

Open Ended

  • Proposal Structure:
    • ~300 word abstract
    • List of Goals/Outcomes
    • Include diagrams as appropriate or link to RfC
  • Tag Team Members you would like to review your idea

Current Projects[edit]

Archived Projects[edit]