Smoothing the Continuous Delivery Path: The Release Team

In this series of posts, I’m looking at various approaches I’ve found helpful in smoothing the path towards a Continuous Delivery culture.

The first post looked at Production focussed stand-ups; in this one, I’ll focus on the Release Team.

The Release Team

As we noted before, successful Continuous Delivery requires Production to be at the forefront of people’s minds. The fact is, this can be particularly challenging when combining all of the following:

• A monolithic application
• Weekly releases to Production
• Code changes from many product teams
• A regular intake of new engineers that are graduates and/or new to Continuous Delivery

On my last client engagement, we addressed this by forming a dedicated cross-product, cross-functional release team, and made it responsible for the smooth passage of each week’s production release.

The key elements of the Release Team’s success were that:

• We made the team integral to the release process. This meant having a dedicated communications channel (Slack/Hangout/Skype group) for the team, including each person involved in getting the release deployed.
• We built the team using the same people that built the release. In other words the release team was a virtual team – drawn from every product team that made code commits (and thus added risk) into the release.
• We made the team truly cross-functional. The release team wasn’t just made up of Testers or Developers or Ops, but a blend of roles from across the product teams. e.g. one team might provide a Product Owner and a Developer, while another team might provide a Tester and their Scrum master. The Support and Ops teams also provided one or two members.
• We monitored production before, during and after the release. This is where most of our learning took place, and it deserves a blog post of its own (I’ll be following up soon). In short though, each production system has a collection of vital signs to indicate its activity and health, and keeping a close eye on them at all stages is crucial.

While the primary aim of the release team is to ensure a smooth release into production (or roll back as quickly as possible), there is a side benefit: as participants get more and more releases under their belt, they build up more detailed knowledge of Production’s vital signs, what causes them, and how they fluctuate due to changes in activity and the introduction of the release itself. This knowledge then flows into people’s day jobs, as they consider more deeply how their changes might impact the next Production release.

Further steps along the Continuous Delivery path

In this article I’ve shared how establishing a virtual, cross-functional, release team can smooth the path towards better Continuous Delivery practice. Next time, I’ll look at how and why you can monitor your production system’s own unique vital signs.

Lyndsay Prewer is a Delivery Lead at Equal Experts. You can also see him speaking on the topic at Agile on the Beach this September.