Download to read offline
Uploaded byIngeniously Simple @ Redgate
Quarterly Development Review - The Template
The document details the Q3 2019 quarterly product development review for the xxx programme, highlighting team changes and OKRs aimed at increasing user engagement with the product. Key objectives include improving product deployment success rates, with identified successes and challenges, as well as ongoing improvement actions across teams. The review emphasizes the need for continuous learning and adaptation in team practices and metrics monitoring.
More Related Content
Similar to Quarterly Development Review - The Template
Quarterly Development Review - The Template
- 1. XXX Programme– 2019Q3 Quarterly Product Development Review A.Person
- 2. Team(s) Overview The XXXTeams Changes in last period: - • Developer A moved to programme X • Developer B has joined team u.p, expect a month to get up to speed • Designer C is on sabbatical for next 6 weeks Team U.P The Autobots Team Orca
- 3. Teams Purpose Our Purpose Tobuild Ingeniously Simple products our customers love and recommend to their colleagues
- 4. Team– OKR1 (Q3review) Objectives We aim to increase the number of people using XXX product in a production environment # Key Results Confidence Progress Actual Minimum OKR1 KR1 KR1: The number of users using the product as part of a production pipeline increases by: - • Baseline – 0 • Minimum – 1 • Gold standard – 3 100% 100% 10 1 OKR1 KR2 KR2: The number of users who have successfully created a deployment increases: - • Baseline – 2 • Minimum – 15 • Gold standard – 40 100% 100% 81 15
- 5. Team– OKR2 (Q3review) Objectives Example here # Key Results Confidence Progress Actual Minimum OKR2 KR1 70% 70% X X OKR2 KR2 100% 100% 1 1 OKR2 KR3 100% 100% 1 1
- 6. Accelerate Metrics –Product 1 Measure RAG Dep Freq L/T
- 7. Accelerate Metrics –Product 2 Measure RAG Dep Freq L/T
- 8. Successes • Team launchednew product to market • Release went on 12th September and take up was XX • Retrospective identified following areas for improvement in release process • Xxxx • Xxxx • Working practices continue to evolve • Mob programming by default • XP practices being embedded • Experiment on trunk based development started
- 9. Challenges • Change failurerate above 5% for one week • Due to outage on widget 2 • Team recovered service by Thursday • Experiment on pairing groups stopped • Feedback from latest retro was that experiment was slowing team • xxxxxxxxxxx
- 10. PDP/ Succession/ Stars PDP SuccessionsPlans Stars Team X All team members 1 senior engineer, 1 tech lead Person A Team Y All team members 1 product manager Person B Legend Green: Team strength; area of excellence. Amber: Some good practice in this area, but room for improvement Red: Team weakness; team have problems/lack of awareness/ deprioritized area * = improvement focus Overall Health Team Health Agile/ Lean Values Where the score is identified as amber or red, improvement activity is taking place this quarter to improve the rating Adaptable Qualityisbuiltin Transparent FocusonBusiness Value Focusonuser WorkingSoftware Continuousdelivered Collaborate Wasteiseliminated Retainlearning PLG Team U.P - Q1 2019 Team U.P - Q2 2019 Team U.P - Q3 2019 The Autobots - Q1 2019 The Autobots - Q2 2019 The Autobots - Q3 2019 Team X Q2 2019 Team X Q3 2019 Team X Q4 2019 Team Y Q2 2019 Team Y Q3 2019 Team Y Q4 2019
- 11. Improvement Actions• Demonstratehow teams are improving accelerate metrics • Get metrics up and working for team A – DONE • Demonstrate reduction in MTTR and CFR for both teams – NOT DONE • Demonstrate continuous improvement activity across all 3 teams • Mob programming as default - DONE • New mob programming spaces created - DONE
- 12.
- 13. 2019 Q4: OKRsObjectivesWe aim to increase the number of people using XXX product in a production environment # Key Results Confidence Progress Actual Minimum OKR1 KR1 KR1: The number of users using the product as part of a production pipeline increases by: - • Baseline – 0 • Minimum – 1 • Gold standard – 3 0% 0% X X OKR1 KR2 KR2: The number of users who have successfully created a deployment increases: - • Baseline – 2 • Minimum – 15 • Gold standard – 40 0% 0% X x
- 14. Improvement Actions • Demonstratehow teams are improving accelerate metrics • Address CFR and MTTR across two teams and their products • Ensure all teams are regularly reviewing metrics and understand why they are where they are • Launch V1 solution in mid October
- 15.
Editor's Notes
- #3 This slide is all about introducing the teams within the programme and listing any significant changes to the people including moves, resignations, new joiners etc.
- #4 The team purpose is taken from the teams OKRs and is normally the ‘North Star’ i.e. the why we are here piece. It should be clear and understood by everyone in the team. We include it here as a reminder to our stakeholders of the teams/programmes purpose
- #5 The next stage is to revisit our OKRs for each team for the last quarter, we do our reporting in retrospect, looking back on what's been achieved before looking forward to what is planned next. We also include a helpful RAG of how close the team was to meeting the OKR or make clear that the OKR still has time to run to be completed
- #6 We’re also transparent on where plans have changed for the team, in this case sharing that the team decided to not complete an OKR in the last quarter because it was no longer the right area of focus for them – autonomy in action
- #7 We report on just 4 metrics for our teams, the 4 key metrics from the Accelerate book. These are in place for every team across each of their products. We also add a helpful RAG to let stakeholders know whether we (And the team) are happy with where the metrics are for the last quarter. The key point of these metrics is not to compare team to team but for the team in question to know why the metrics are where they are right now i.e. if change failure rate is at 20%, why was this? What happened? What did we do to recover service? What did we learn?
- #8 These four metrics help leaders and teams focus on measuring and improving what matters in terms of software delivery performance. The thorough State of DevOps reports have focused on data-driven and statistical analysis of high-performing organizations. The result of this multi-year research, published in the book "Accelerate", demonstrates a direct link between organizational performance and software delivery performance. The researchers have determined that only four key metrics differentiate between low, medium and high performers: delivery lead time, deployment frequency, mean time to restore (MTTR) and change fail percentage. But what do those metrics mean in the context of Redgate? Delivery lead timeTime between code being committed, and that code being made available to customers in an installer.Deployment frequencyHow frequently we make new installers available to customers.Mean time to restore (MTTR)The mean average time between releasing a "failure" to customers and issuing a release that doesn't include that failure.Change fail percentageThe percentage of releases made to customers that result in a new "failure".
- #9 In this slide we list the key successes of the team for the last quarter, this isn’t meant to be war and peace but a high level summary that we can talk about for each team
- #10 In this section we discuss the challenges the team faced in the last quarter, again it’s a summary, transparency is important including things we tried that didn’t turn out as expected
- #11 This section is a really important area for us to report on and covers the teams health – measured against the 9 lean principles using a simple RAG – key is above We do this in consultation with our team leaders for each team, asking them to rate their teams on how they deal with change, quality deliverables etc. Its not an exact science, but then we don’t pretend it should be, instead it’s a useful indication for the team lead and us as to where we can best focus our efforts with teams. We also dig into personal development plans and whether they are in place, succession plans (For people in the team expressing an interest in their next role) and the stars who have shined in the last quarter
- #12 This slide is where we revisit the areas we identified in the previous QDR as areas of improvement and the status of these areas
- #14 In this section we share what the teams OKRs are for the coming quarter. We review OKRs at least quarterly or whenever the team either decides the current OKRs have been met or are no longer the right thing to work on. This means that sometimes our OKRs can be very short lived or can extend across multiple quarters.
- #15 In this section we share what the areas for improvement are for the coming quarter – these will then be reported on in the next QDR session