Release cadence is a critical factor in successful software development. Business agility, agile development and going faster is not about typing faster, it’s about doing less to get the changes you want into production, while improving stability and safety.
We looked at our production release cadence metrics to find where it was slowest, to see if we could rapidly change the delivery culture in a sustainable way. I joined a team whose individual members were producing one production release every three weeks.
The goal was to improve the number of releases and we agreed to review the release cadence at agreed points in time after I joined the team.
We succeeded; after two months a team whose individual members had been producing one production release every three weeks was now producing one every day – nearly 15x more than at the start of the process.
Before telling you how we did that, I want to share a few more thoughts about the importance of release cadence.
Release cadence influences the pace at which we realise value from innovations and the rate at which we get feedback from real users.
It also affects how we engage with the people who help make our products great. It helps us build stronger relationships with our product owners, end-users and domain experts through more frequent interactions, and it helps our less technically minded colleagues to empathise with the challenges we face in our technology stacks. It drives stability in our production environments through smaller, more understandable and testable changes.
The release cadence metric we used was based on how many production releases the team would do per year if it consisted of 10 people, even though teams are typically between three and eight people. This normalisation to a theoretical team of 10 lets us compare release cadence across teams of different sizes.
In the team we looked at, release cadence was 170 production releases per 10 people per year, equivalent to each team member delivering one production release approximately every three weeks.
Setting clear objectives from the start was important to getting us all working towards a common goal and having a shared understanding of what we were doing, and why we were doing it. We agreed to review the release cadence one week after I joined the team, and then one and two months later.
Joining a team with the intention of releasing something to production is always very illuminating because you learn things that people would not ordinarily tell you about. As an outsider, I was able to spot the bottlenecks in the end-to-end process through an iterative approach that included working with the team on new requirements, from information-gathering to delivery, into production and sign-off.
As a result, we have reduced the number of incidents by approximately 40 per cent, as we track changes and configurations through environments, rather than only being added to production, and as the team has adapted their thinking to smaller, more iterative changes.
Lastly, we have surfaced valuable metrics about what change is really required to run this system. For something you are trying to demise, this is hugely valuable as it highlights areas where its successor needs to be significantly better. Not through gut-feel thoughts from end-users, but with real numbers that make prioritising functional improvements easier.
At the end of the first week the team had doubled their release cadence to 340 production releases per 10 people per year, or one release every 1.5 weeks per person.
At the end of the first month the team’s release cadence was 1,070, or just over two releases per person per week.
At the final two-month review point the team had achieved a cadence of 2,506, which roughly means that every person is doing one release to production every business day, a near 15-fold improvement.
The results show that a team working within the right environment only requires a short but reasonably intensive period to shift their mindset. By providing the right support and minor directional corrections we can change the delivery culture.