Measuring and improving ways of working on digital teams
Healthy teams, happy people and mature agile ways of working are good leading indicators of organisational success. Getting these things right is key to unlocking long term sustainable delivery of value. In this blog post, I summarise some of the approaches I have used to measure and improve ways of working.
Team health checks (Spotify style)
Spotify’s health check model is a structured retrospective which helps teams and management spot problems and identify where to focus improvement efforts. Teams are asked a set of questions, and each team member answers with a green, amber or red card to indicate their response.
This health check model is great because it encourages the team to have focussed conversations about how they can improve, and provides quantitative data which can be used to spot patterns and trends. I like to:
- repeat every 2-3 months
- encourage teams to facilitate for each other, so that the usual facilitator can participate
- openly record the results, so trends between teams and over time can be spotted
- collaboratively create a set of questions that relate to the context of your organisation rather than reusing the Spotify ones
When managing a programme, every two or three months I like to use a tool like Survey Monkey or Google Forms to run a brief anonymous survey. As with healthchecks, this provides useful quantitative data indicating whether things are getting better or worse over time. It also provides brutally honest and open feedback that managers might otherwise not hear. I like to:
- repeat every 2-3 months
- not include too many questions. Five is plenty. Less is more.
- use a score system like yes/no or strongly agree/agree/neutral/disagree/strongly disagree.
- repeat some key questions so you can see trends over time. A good one to repeat is “ Would you recommend working here to a friend?”.
- have an optional freeform comment box at the end where people can tell you what they think.
- keep results anonymous, but proactively encourage everyone to respond.
- review the results and comments with the management team. Agree actions in response.
- take the time to present the results back to the teams. Communicate the response and actions.
Ways of working prompts
In my first delivery manager role, my then line manager Ros Vaughan suggested I review the health of my team using David Lowe’s health check template. I recorded my answers to each question and reviewed the results with Ros in our 121s. This activity was useful because it helped me see what good looks like and where improvements might need to be made. It also gave structure to our 121s. As an individual looking to identify ways for your team to improve, give this template a try. As a programme or community of practice, consider creating your own ways of working prompts for use with teams. It can be a great tool which encourages people to ask the right questions of themselves and each other.
Delivery metrics give us an idea of how frequently and effectively teams are delivering value. This information can be used to drive process improvements and inform planning activities. Some good metrics to monitor are cycle time, lead time, cumulative flow and cost of delay. Be careful with delivery metrics – measuring some things can cause dysfunctions (as discussed in this post on crappy agile). Be particularly careful with velocity.
There are some good tools out there that can automate the collection and display of delivery metrics. If using Trello, try out Corrello. It provides all of the above metrics and more in an easy to use interface. Jira does most of the above out of the box. Alternatively, if you’re tool agnostic, check out Emily Webber’s Kanban Spreadsheet.
Delivery folk should regularly use these metrics as a basis for conversation with the team during retrospectives and planning. And senior delivery folk should use these metrics as a basis for conversations in regular 121s.
Technical delivery metrics
Technical delivery metrics help us understand the maturity of development practices, identify areas that need improvement and measure improvements over time. The 2018 State of DevOps Report suggests some indicators of technical maturity which include:
- deployment frequency and time to deploy
- % of automated vs manual work in configuration management, testing, deployments and change approvals
- time to restore service
- change failure rate
- time spent on new work vs unplanned & rework vs support vs fixing defects identified by end users vs remediating security issues
Encourage developers to decide amongst themselves which metrics indicate healthy development practices, and take the time to configure a dashboard which gives everyone on the team access to this type of information. As with the delivery metrics, technical folk should review these metrics regularly, look for areas that need improvement and celebrate successes.
Leave a ReplyWant to join the discussion?
Feel free to contribute!