From Bi-Annual to Fortnightly Releases in 4 months

25-minute Talk

How do you know where to start, when organisational and technological challenges surround you? How to overcome the team's fear they could not maintain quality when accelerating the release cadence?

Virtual Pass session

Timetable

11:45 a.m. – 12:30 p.m. Thursday 16th

Room

Room F2 - Track 2: Talks

Audience

Anyone involved in driving change as well as Tech Leads, Architects, Engineering Managers and CTOs

Key-Learnings

  • Apply the Improvement Kata to introduce change at scale.
  • Analyse the organisation's current situation using a Value Stream Mapping workshop.
  • Identify the bottlenecks requiring first attention using the Theory of Constraints.
  • Apply Fear Conversation to expose and mitigate fear.
  • Understand when an organisation reaches a state of Continuous Delivery.

Overcoming fear when going from bi-annual to fortnightly releases in under 4 months for 15 teams and their single monolith

Domain experts wanted to have bi-weekly releases to obtain faster feedback on new functionality. However, the organisation could only release every 6 months because of a waterfall approach, 15 teams and a single shared monolith. The bi-annual release effort was skyrocketing. A 3-week code freeze for user acceptance testing was supposed to ensure quality. Yet, after each release, a series of urgent hotfixes had to be applied in production. How do you know where to start, when technological and organisational challenges surround you? Because of the monolith, we could not start with one team. We had to apply changes to all 15 teams at once.

During this session, I’ll cover how we used the Improvement Kata, Value Stream Mapping, and the Theory Of Constraints to choose which changes to apply first and kickstart the organisational changes we needed to improve quality and drive down lead times. Four months later, the organisation released every two weeks like clockwork resulting in faster feedback.

However, it took me another six months to realise it was not the plan that helped the organisation. The teams worried they could not maintain quality while accelerating the release cadence. They were afraid. Rather than avoiding those fears, we used Fear Conversations (from the book Agile Conversations) to surface them. They allowed us to uncover, locate and understand the stakeholders’ fears. To then mitigate these fears and navigate the difficult conversations we had to have in order to define incremental improvements. If you thought adopting Continuous Delivery is easy, think again! It’s not just technology, it’s about humans and their fears.

Related Sessions