This is the QDR template all of our Development Managers use to report on progress of teams every 3 months. Check out the below post for more details: -
https://medium.com/ingeniouslysimple/how-we-report-on-teams-at-redgate-5d66c5fdf4c4
2. Team(s) Overview
The XXX Teams
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
To build Ingeniously Simple products our customers love and recommend
to their colleagues
4. Team– OKR1 (Q3 review)
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 (Q3 review)
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
8. Successes
• Team launched new 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 failure rate 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 Successions Plans 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• Demonstrate how 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
13. 2019 Q4: OKRsObjectives 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
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
• Demonstrate how 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
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.
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
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
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
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?
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".
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
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
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
This slide is where we revisit the areas we identified in the previous QDR as areas of improvement and the status of these areas
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.
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