Practices Change - Moving to Delivering Continuously
Delivering continuously - easier said than done. As I joined my team delivering Windows Desktop products two years ago with the aspiration of implementing continuous delivery, I was told it cannot be done. It started from the fact that making a single release was five-day effort, and continued with “no user would allow us to deliver frequently”.
Two years later, making a release takes us two hours and the way we work together looks very different. With the principle of fixing maintenance issues in the latest release has resulted in improved flow forward and savings of effort in supporting small number of releases.
This talk goes through our lessons learned on the journey of shortening release cycles to a continuous daily flow.
We’ve experienced three essentially different sets of practices, with the core difference coming from release frequency. The good place is when we deliver continuously. The soulsucking place is when we deliver on two week cadence. And the insane asylum is when we deliver just once at the end of the project.
Think of it like this: a pool is not just a bigger bathtub. The things you can do in a pool are different to those you can do in a bathtub. While both are containers of water, they serve different purposes. It is the same with release frequency. While it is all still releases, the continuous ones enable different practices.
Outline/Structure of the Case Study
I have not built the talk in detail yet. Not sure what you want with this box.
- How release cycle length changes team practices
- Changing releases one release at a time
Prerequisites for Attendees
I believe all good talks, even advanced ones, are built to assume people come with different backgrounds.