FY20-Q2 OKR Development: Increase productivity => 85%

We are looking to increase our monthly throughput from ~1800 MRs to ~2160. This represents an increase of roughly 20%.

Overall increase ~1800 to ~2160 MRs. => 85%, 2097 MRs in July (2097 - 1791)/360 = 85%
Dev increase ~420 to ~525 MRs. => 86%, 511 MRs in May
CI/CD: Increase productivity. Raise throughput by 20% from Q1 benchmark. 16% => peak to peak improvement was from 178 to 184 vs. goal of 213, (6/35) = 16%.
Ops: Increase throughput. Raise throughput by 20% from Q1 benchmark. 100% => 190 MRs in July which easily beat the goal of 150 peak to peak
Secure: Increase Throughput. Raise throughput by 20% from Q1 benchmark. 100% => 158 MRs in July which beat the goal of 152 peak to peak.
Enablement: Increase productivity 100% => 156 MRs in July which beat 138 peak to peak. new team added Memory.

Benchmark of 1800 was chosen as highest month of previous quarter (FYQ1-April)

Month results: May - 1610, June - 1885, July - 2097

Based on July's performance (2097 - 1791)/360 = 85%.

Note: Section MRs may not add up to total scoring in part because highest month during the quarter can vary section to section.

Retrospective

We continued to see improvement in performance of teams with headcount growth
Team members have been able to ramp fast by giving clearly defined issues to get started on

We Lagged on Average MRs per Engineer for most of the quarter (8.69 vs. 9.13 previous quarter)
Team splits caused some loss in productivity
There was miscommunication about whether our KPIs is raw throughput, or throughput divided by headcount

There is belief that we can increase productivity by focusing on limiting build failures.
We should consider identifying the interaction/dependency between frontend and backend on issues early on in the planning to help address the interdependency between the two and ensure neither causes delays on the other where possible.
Focus on throughput divided by headcount going forward

Edited Nov 24, 2022 by Cynthia "Arty" Ng